Re: One huge db vs many small dbs

Поиск
Список
Период
Сортировка
От Nicholson, Brad (Toronto, ON, CA)
Тема Re: One huge db vs many small dbs
Дата
Msg-id EC55DC235432104F8255702A8D7344D941C0C5CB@G4W3211.americas.hpqcorp.net
обсуждение исходный текст
Ответ на One huge db vs many small dbs  (Max <maxabbr@yahoo.com.br>)
Ответы Re: One huge db vs many small dbs  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-performance
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org [mailto:pgsql-
> performance-owner@postgresql.org] On Behalf Of Max
> Sent: Thursday, December 05, 2013 5:42 AM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] One huge db vs many small dbs
>
> Hello,
>
>
> We are starting a new project to deploy a solution in cloud with the possibility
> to be used for 2.000+ clients. Each of this clients will use several tables to
> store their information (our model has about 500+ tables but there's less
> than 100 core table with heavy use). Also the projected ammout of
> information per client could be from small (few hundreds tuples/MB) to
> huge (few millions tuples/GB).
>
>
> One of the many questions we have is about performance of the db if we
> work with only one (using a ClientID to separete de clients info) or thousands
> of separate dbs. The management of the dbs is not a huge concert as we
> have an automated tool.

If you are planning on using persisted connections, the large number of DB approach is going to have a significant
disadvantage. You cannot pool connections between databases.  So if you have 2000 databases, you are going to need a
minimumof 2000 connections to service those database (assuming you want to keep at least one active connection open per
clientat a time). 

Brad.



В списке pgsql-performance по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Explain analyze time overhead
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: One huge db vs many small dbs