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

Mason Sharp 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:

>  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
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/20140903/f3214d2c/attachment.htm>


More information about the postgres-xl-general mailing list