Re: One huge db vs many small dbs

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: One huge db vs many small dbs
Дата
Msg-id 52A0A27D.1050104@joeconway.com
обсуждение исходный текст
Ответ на One huge db vs many small dbs  (Max <maxabbr@yahoo.com.br>)
Список pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/05/2013 02:42 AM, Max wrote:
> 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 I understand correctly: 500 tables x 2000 = 1 million tables

Even if not heavily used, in my experience 1 million tables in a
single database will cause problems for you:
1) on Postgres versions < 9.3, pg_dump takes *long* time (think days)
2) psql tab complete really slow
3) probably others I'm not thinking of right now...

There are advantages to not needing to manage so many databases, but I
would test it carefully before committing.

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSoKJ9AAoJEDfy90M199hlSlgP/10lk4HZ3lga1RMMtzAlzYul
92NIS1MIDQLb/Uo6DPsbchh9aAU1MZjuC0fuTwOAAjfXMgyKO9AbEgbkf1PlLn1R
LrG/pOdzBEJp67fIqWckBwMKzE8RjetQnyDykkW893xgRE4woyMtPdk1ywPT1iFK
IX9HgzTEhnHH4FSkFcxRtqWmgJX5eigKEXfC8wLE8//8VJye0Ej0wS04PXPkkKvM
DBOJ8ba9A853nl4F4l26jmoJ6iiMJqsxHYJsJMX45tFDsyuvf4E4r9y9CHbXlEw0
1o/DTLHqKK2uDniz3pVnCuqHxtPr0IoD7imkh5gGgi40VKBzpCzfNg9NQMw02OL2
wpvJJeWynKwny/3BTN0ZW5mLb1iP1PLZRsr1ivwbVRUARfYoShWRB1fMruuXSvV4
A7hO4tGDCrvB/R2BxS0/ssLvO9vxX+sHTleAP4Uoz2kv5MBuJRRZsFlb8ejOB3gg
iWb4QJOh93NVJgW6M2y496d8Zoz2Vq2o8QUOOzh49QmQjQE3tyXgsO4VmrpUxwHg
zK0d+Qlkua9U433+dNQBs2i4mf1K58LJ0uQde2ibULk6Tgq+uJePmWfzKPhkwamV
1d3Iu7UgE5JigzmdWJy4GdJiVGLsTdOtGFHJhMEIFYZ/pHF8WoAtlx6D1SkaCNDr
IiR6V5n+xDuuPkQcDBp0
=FGZi
-----END PGP SIGNATURE-----


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Parallel Select query performance and shared buffers
Следующее
От: Metin Doslu
Дата:
Сообщение: Re: Parallel Select query performance and shared buffers