Re: PG Sharding

Поиск
Список
Период
Сортировка
От Matej
Тема Re: PG Sharding
Дата
Msg-id CAJB+8mb4ku1besVRr6K5qs9g4CUxKzDJ9_5QpTGDshqQUcZovg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG Sharding  (Dan Wierenga <dwierenga@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Westermann
Дата:
Сообщение: Re: Master-Slave error: the database system is starting up
Следующее
От: Vikas Sharma
Дата:
Сообщение: FATAL: failed to create a backend connection