Re: PG Sharding - Mailing list pgsql-general

From Matej
Subject Re: PG Sharding
Date
Msg-id CAJB+8mbrYgghqGE-QNt-h-qMK1d+wAPFh-koG8+iUyvPELeCuA@mail.gmail.com
Whole thread Raw
In response to Re: PG Sharding  (Rakesh Kumar <rakeshkumar464@aol.com>)
Responses Re: PG Sharding  (Rakesh Kumar <rakeshkumar464@aol.com>)
List pgsql-general
We are looking for multi tenancy but at scale. That's why the sharding and partitioning. It depends how you look at the distributed part. 

BR

Matej

29. jan. 2018 17.50 je oseba "Rakesh Kumar" <rakeshkumar464@aol.com> napisala:


> On Jan 29, 2018, at 09:34 , 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.
>
>
> So far our understanding:
>
> SCHEMA.
>
> PROS:
> - seems native to PG
> - backup seems easier
> - connection pooling seems easier, as you can use same connection between shard.
>
> CONS:
> - schema changes seems litlle more complicated
> - heard of backup and maintenance problems
> - also some caching  problems.
>
> DATABASE:
>
> PROS:
> - schema changes litlle easier
> - backup and administration seems more robust
>
> CONS:
> - heard of vacuum problems
> - connection pooling is hard, as 100 shards would mean 100 pools
>
>
> So what is actually the right approach? If anyone could  shed some light on my issue.

From your description it seems your requirement is more of multi tenancy in a non distributed env, rather than distributed Sharding env.


pgsql-general by date:

Previous
From: Robert Zenz
Date:
Subject: Re: Information on savepoint requirement within transctions
Next
From: Abhra Kar
Date:
Subject: Re: CannotAcquireResourceException in Junit