Re: PG Sharding - Mailing list pgsql-general

From Matej
Subject Re: PG Sharding
Date
Msg-id CAJB+8mb4ku1besVRr6K5qs9g4CUxKzDJ9_5QpTGDshqQUcZovg@mail.gmail.com
Whole thread Raw
In response to Re: PG Sharding  (Dan Wierenga <dwierenga@gmail.com>)
List pgsql-general
I thought that this kind of solution had high latency and bad OLTP capabilities (low trans/second)? Analytics is not a high priority. 

BR

2018-02-01 19:01 GMT+01:00 Dan Wierenga <dwierenga@gmail.com>:


On Wed, Jan 31, 2018 at 7:48 PM, Steven Lembark <lembark@wrkhors.com> wrote:
On Mon, 29 Jan 2018 15:34:18 +0100
Matej <gmatej@gmail.com> wrote:

> Hi Everyone.
>
> We are looking at a rather large fin-tech installation. But as
> scalability requirements are high we look at sharding of-course.
>
> I have looked at many sources for Postgresql sharding, but we are a
> little confused as to shared with schema or databases or both.

Suggest looking at the Xreme Data product. It is a parallel,
shared-nothing implementation of PG that should solve your
needs rather nicely.

You can see a description of their product at
https://xtremedata.com/

Happy scaling :-)


Having been a production DBA for both the DBX (XtremeData) and the Greenplum MPP database platforms, IMO Greenplum is far superior to DBX.   Issues with the GP master node being a single point of failure are solved by a secondary master node and automatic failover technology e.g. keepalived.

But, it sounds like the OP is not really looking for the kind of scale that an MPP solution provides, but rather the kind of scale that is typically solved by a service-orchestration suite.  I don't think that "a rather large fin-tech installation" with "high scalability requirements" is really enough detail to give a recommendation on orchestration software. 

-dan

pgsql-general by date:

Previous
From: Daniel Westermann
Date:
Subject: Re: Master-Slave error: the database system is starting up
Next
From: Vikas Sharma
Date:
Subject: FATAL: failed to create a backend connection