Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants.
От | Avinash Kumar |
---|---|
Тема | Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants. |
Дата | |
Msg-id | CAN0TujfLZ22xm0u99B+jsB31R55fQ5OJ2PKgcmr0TZHUPwoTUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants. (Rory Campbell-Lange <rory@campbell-lange.net>) |
Ответы |
Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants.
Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants. |
Список | pgsql-performance |
Hi,
On Thu, May 7, 2020 at 6:08 PM Rory Campbell-Lange <rory@campbell-lange.net> wrote:
On 07/05/20, Avinash Kumar (avinash.vallarapu@gmail.com) wrote:
> >> Our application serves multiple tenants. Each tenant has the schema
> >> with a few hundreds of tables and few functions.
> >> We have 2000 clients so we have to create 2000 schemas in a single
> >> database.
> > That is one option but I wouldn't say you must. If you cannot get
> > individual tables to be multi-tenant you are probably better off having one
> > database per client on a shared cluster - at least given the size of the
> > schema and number of clients.
> >
> I am working on a similar problem.
> 1 database per each client may be a killer when you have a connection
> pooler that creates a pool for a unique combination of (user,database).
One of our clusters has well over 500 databases fronted by pg_bouncer.
We get excellent connection "flattening" using pg_bouncer with
per-database connection spikes dealt with through a reserve pool.
What if you see at least 4 connections being established by each client during peak ? And if you serve 4 or 2 connections per each DB, then you are creating 1000 or more reserved connections with 500 DBs in a cluster.
The nice thing about separate databases is that it is easy to scale
horizontally.
Agreed. But, how about autovacuum ? Workers shift from DB to DB and 500 clusters means you may have to have a lot of manual vacuuming in place as well.
Rory
Regards,
Avinash Vallarapu
Avinash Vallarapu
+1-902-221-5976
В списке pgsql-performance по дате отправления: