Re: [Postgres-xc-general] ERROR: Failed to get pooled connections

[Andrei M. <and...@gm...>]

Hi Vladimir,

I guess you got familiar with other solutions out there and trying to find
in XC somesing similar. But XC is different. The main goal of XC is
scalability, not HA.
But it looks like we understand "scalability" differently too.
What would a classic database owner do if he is not satisfied with the
performance of his database? He would move to better hardware! That
basically what we mean by "scalability".
However in case of classic single-server DBMS you would notice, that
hardware cost grows exponentially. With XC you may scale linearly - if you
run XC, for example, on 8 node cluster you may add 8 more and get 2 times
more TPS. That is because XC is able to intellegently split your data on
your nodes. If you have one huge table on N nodes you can write data N
times faster, since each particular row goes to one node and each node
processes 1/Nth of total requests. Read is scaling either - if you search
by key each node will search only local part of data, wich is N times
smaller then entire table, and all nodes search in parallel. More, if the
search key is the same as distribution key only one node will search, that
one where rows may be located perfect if there are multiple concurrent
searchers.
You mentioned adding nodes online. That feature is not *yet* implemented in
XC. I would not call it "scalability" though. I would call it flexibility.
That approach is not good for HA: redundancy is needed for HA, XC is not
redundant if you lost one node you lost part of data. XC will still live in
that case and it would be even able to serve some queries. But query that
needs lost node would fail. However XC supports Postgres replication, you
may configure replicas of your datanodes and switch to slave if master
fails. Currently an external solution is required to build such kind of
system. I do not think this is a problem. Nobody needs pure DBMS anyway, at
least frontend is needed. XC is a good brick to build system that perfectly
fulfill customer requirements.
And about transparency. Application sees XC as a generic DBMS and can
access it using generic SQL. Even CREATE TABLE without DISTRIBUTE BY clause
is supported. But like with any other DBMS database architect must know
DBMS internals well and use provided tools, like SQL extensions to tune up
specific database for application. XC is capable to achieve much better
then linear performance when it is optimized.


2012/10/24 Vladimir Stavrinov <vst...@gm...>

> On Wed, Oct 24, 2012 at 08:08:32PM +0900, Michael Paquier wrote:
>
> >    Sure, XC provides thanks to its architecture naturally transparency
> and scalability.
>
> What does XC provides? My two rhetorical questions above imply answers
> "NO".  Necessity to adapt application means cluster is not transparent.
> Impossibility to extend cluster online means it is not scalable.
>
> More over, this two issues are interrelated, because You should rewrite
> "CREATE TABLE" statement every time you expand (read: recreate) Your
> cluster. But this issue looks much worse if node fails containing tables
> with different distributed schemas. This is uncontrollable model.
>
> >    Load balancing can be provided between Coordinator and Datanodes
> >    depending on applications, or at Coordinator level
>
> It should not depend on application, it should be an cluster's global
> function.
>
> >    For HA, Koichi is currently working on some tools to provide that,
>
> Again: it should not be external tool, it should be internal, integral,
> essential feature.
>
> >    I am not sure you can that easily compare XC and mysql cluster,
> >    both share the same architectures, but once of the main
>
> I don't know what there is "the same", but in functionality it is
> totally different. Mysql cluster has the precise and clear clustering
> model:
>
> 1. If some nodes fail cluster continues to work as soon as there remains
> at least one healthy node in every group.
>
> 2. No "CREATE TABLE ... DISTRIBUTE BY ..." statement. You just define
> the number of replicas at configuration level. Yes, now there are only
> one option is available that make sense with two replicas, but it is
> enough.
>
> 3. Read and write scalability (i.e. LB) at the same time for all tables
> (i.e. on the cluster level).
>
> 4. You can add data node online, i.e. without restarting (not to mention
> "recreating" as for XC) cluster. Yes, only new data will go to the new
> node in this case. But You can totally redistribute it with restart.
>
> So it is full flagged cluster, that's not true for XC and it's a pity.
>
> >    differences coming to my mind is that XC is far more flexible in
> >    terms of license (BSD and not GPL), and like PostgreSQL, no company
> >    has the control of its code like mysql products which Oracle relies
>
> Yes, and this is why I am persuading all developers migrate to
> Postgresql. But it is off topic here where we are discussing
> functionality, but not an licence issues.
>
> Be tolerant to my criticism, I wouldn't say You made bad thing, I was
> amazing when first read "write-scalable, synchronous multi-master,
> transparent PostgreSQL cluster" in Your description that I completely
> and exactly copied into description of my debian package, but I was
> notably disappointed after my first test showing me that it is odd with
> reality. It would not be so bad itself, as soon as it is young project,
> but much worse that this discussion shows there are something wrong with
> Your priorities and fundamental approach.
>
> --
>
> ***************************
> ##  Vladimir Stavrinov
> ##  vst...@gm...
> ***************************
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
Andrei Martsinchyk

StormDB - http://www.stormdb.com
The Database Cloud