[Postgres-xl-general] [Postgres-xl-developers] General query

Saurabh Gupta A saurabh.a.gupta at ericsson.com
Tue Sep 9 09:07:26 PDT 2014


Hi Mason/All,
Thanks for reply.

One more doubt to clarify:
I have an impression in my mind from some readings that Postgres-xl do not support virtual/cloud deployment. Can you please clarify this?






------------------------------------------------------------------------
Regards:
Saurabh Gupta
Ericsson India Global Service Private Limited, Gurgaon


From: Mason Sharp [mailto:msharp at translattice.com]
Sent: Wednesday, September 03, 2014 7:33 PM
To: Saurabh Gupta A
Cc: postgres-xl-general at lists.sourceforge.net; postgres-xl-developers at lists.sourceforge.net
Subject: Re: [Postgres-xl-developers] General query



On Mon, Sep 1, 2014 at 7:22 AM, Saurabh Gupta A <saurabh.a.gupta at ericsson.com<mailto:saurabh.a.gupta at ericsson.com>> wrote:
Hello,
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 automate this.
Consistency – Durable and consistent writes
Yes, this is an important feature of PostgreSQL, no compromising on ACID cluster-wide.


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 blades).

ok

- Evenly distributed reads and writes.

ok


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.

Regards,

--
Mason Sharp

TransLattice - http://www.translattice.com<http://www.translattice.com/>
TransLattice Elastic Database (TED)
Postgres-XL Support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/private.cgi/postgres-xl-general-postgres-xl.org/attachments/20140909/26b2cf59/attachment.htm>


More information about the postgres-xl-general mailing list