[Postgres-xl-general] [Postgres-xl-developers] General query
msharp at translattice.com
Wed Sep 3 07:03:03 PDT 2014
On Mon, Sep 1, 2014 at 7:22 AM, Saurabh Gupta A <
saurabh.a.gupta at ericsson.com> wrote:
> For a product of Ericsson, I am looking for a database which provides
> following performance/properties:
> *Linearly Scalable* – Scales as we add more servers
At the moment, it is not overly convenient to add nodes. You could
pre-distribute on more nodes than servers, and later move them off. This
is an area for future improvement.
*Reliability* – No single point of failure
Each component can have a standby. Failover is not automatic within
Postgres-XL, however. You can use something like Corosync/Pacemaker to
> *Consistency* – Durable and consistent writes
Yes, this is an important feature of PostgreSQL, no compromising on ACID
> *Data Affinity* – Possibly most writes to local node
Coordinators and Datanodes are separated out, with the application data
being written to Datanodes. Coordinators and Datanodes could be co-located
on the same server, however. If you know something about how your data is
distributed (by customer id, for example), you could have your app connect
to a server where you would have high data affinity.
> Self *Managing – Easy to add and remove nodes in cluster*
Postgres-XL is not self managing.
> - Batched Operations to the Database
Bulk loads are possible.
> - No RDBMS support required
Postgres-XL is an RDBMS at its core.
> - Generally stored as Key-Value pair
You can use Postgres-XL as a key-value store if you want, and even have the
value as a JSON type. More improvements in this area will come as we merge
in PostgreSQL 9.4 in the future.
> - Mostly transient data. Lifetime from few minutes to few hours (In some
> cases data needs to be stored for 30 days).
Regular caching applies. You could create subtables partitioned by date, to
make these easier to drop or move off.
> - Can store data in the range from few GBs to 10 TBs (Across multiple
> - Evenly distributed reads and writes.
> *High throughput requirements*
> - 50000 – 60000 operations/sec/blade in non-batched mode
> - 80000 – 100000 operations/sec/blade in batched mode
I am not sure you will be able to achieve that per blade, but across
multiple servers, yes.
TransLattice - http://www.translattice.com
TransLattice Elastic Database (TED)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgres-xl-general