Postgresql: лучше ли использовать несколько баз данных с 1 схемой каждая или 1 базу данных с несколькими схемами?

после комментарий на один из моих вопросов, я думаю, лучше ли использовать 1 базу данных со схемами X или наоборот.

моя ситуация: я разрабатываю веб-приложение, где, когда люди регистрируются, я создаю (фактически) базу данных (нет, это не социальная сеть: каждый должен иметь доступ к своим собственным данным и никогда не видеть данные другого пользователя).

Так я использовал для предыдущей версии моего приложения (которое все еще работает на mysql): через api plesk, для каждой регистрации, я делаю:

  1. создать пользователя базы данных с ограниченными правами;
  2. создайте базу данных, к которой может получить доступ только предыдущий созданный пользователь и суперпользователь (для обслуживания)
  3. заполнить БД

теперь мне нужно будет сделать то же самое с postgresql (проект становится зрелым и mysql.. не выполняйте все потребности)

мне нужно иметь все базы данных/схемы резервное копирование независимо: pg_dump отлично работает в обоих направлениях, то же самое для пользователей, которые могут быть настроены для доступа только к 1 схеме или 1 базе данных.

Итак, предполагая, что вы более опытные пользователи potsgres, чем я, как вы думаете, лучшее решение для моей ситуации и почему?

будут ли различия в производительности с использованием $x db вместо $ x схем? И какое решение будет лучше поддерживать в будущем (надежность)?

редактировать: я почти забыл: все мои базы данных / схемы будут всегда имеют ту же структуру!

Edit2: для Проблемы с резервными копиями (с использованием pg_dump), возможно, лучше использовать 1 дБ и многие схемы, сбрасывая все схемы сразу: восстановление будет довольно простой загрузкой основного дампа в машине dev, а затем дамп и восстановить только необходимую схему: есть 1 дополнительный шаг, но сброс всей схемы кажется быстрее, чем сбрасывать их один за другим.

p.субъект: извините, если я забыл некоторые " W " char в тексте, моя клавиатура страдает этой кнопкой ;)

обновление 2012

Ну, структура приложения и дизайн так сильно изменились за последние два года. Im все еще использует 1 db with many schemas подход, но все же, у меня есть 1 база данных для каждой версии приложения:

Db myapp_01
    _ my_customer_foo_schema
    _ my_customer_bar_schema
Db myapp_02
    _ my_customer_foo_schema
    _ my_customer_bar_schema

для резервных копий im регулярно сбрасывает каждую базу данных, а затем перемещает резервные копии на dev-сервере.

Im также использует PITR/WAL резервная копия, но, как я уже сказал, вряд ли мне придется восстанавливать базы данных сразу.. поэтому, вероятно, в этом году он будет уволен (в моей ситуации это не лучший подход).

подход 1-db-many-schema работал очень хорошо для меня с тех пор, даже если структура приложения полностью изменилась:

я почти забыл: все мои базы данных / схемы будут всегда имеют ту же структуру!

...теперь каждая схема имеет свою структуру, что изменение dinamycally реагируют на пользователей потока данных.

111
database database-design database-permissions postgresql

6 ответов

"схема" PostgreSQL примерно такая же, как "база данных"MySQL. Наличие многих баз данных на установке PostgreSQL может стать проблематичным; наличие многих схем будет работать без проблем. Таким образом, вы определенно хотите пойти с одной базой данных и несколькими схемами в этой базе данных.

84

определенно, я пойду на подход 1-db-many-schemas. Это позволяет мне сбросить всю базу данных, но восстановить только 1 очень легко, во многих отношениях:

  1. дамп БД (вся схема), загрузите дамп в новую БД, дамп только схема мне нужна, и восстановить обратно в основной БД
  2. дамп схемы отдельно, один за другим (но я думаю, что машина будет страдать больше таким образом - и я ожидаю, как 500 схем!)

в противном случае, googling вокруг я видел что нет автоматической процедуры для дублирования схемы (используя ее в качестве шаблона), но многие предлагают следующий способ:

  1. создать шаблон-схемы
  2. когда нужно дублировать, переименуйте его с новым именем
  3. дамп
  4. переименовать его обратно
  5. восстановить дамп
  6. магия делается.

Я написал 2 строки в python, чтобы сделать это; я надеюсь, что они могут помочь кому-то (в-2-секунд-написанный-код, не используйте его в производство): 

import os
import sys
import pg

#Take the new schema name from the second cmd arguments (the first is the filename)
newSchema = sys.argv[1]
#Temp folder for the dumps
dumpFile = '/test/dumps/' + str(newSchema) + '.sql'
#Settings
db_name = 'db_name'
db_user = 'db_user'
db_pass = 'db_pass'
schema_as_template = 'schema_name'

#Connection
pgConnect = pg.connect(dbname= db_name, host='localhost', user= db_user, passwd= db_pass)
#Rename schema with the new name
pgConnect.query("ALTER SCHEMA " + schema_as_template + " RENAME TO " + str(newSchema))
#Dump it
command = 'export PGPASSWORD="' + db_pass + '" && pg_dump -U ' + db_user + ' -n ' + str(newSchema) + ' ' + db_name + ' > ' + dumpFile
os.system(command)
#Rename back with its default name
pgConnect.query("ALTER SCHEMA " + str(newSchema) + " RENAME TO " + schema_as_template)
#Restore the previus dump to create the new schema
restore = 'export PGPASSWORD="' + db_pass + '" && psql -U ' + db_user + ' -d ' + db_name + ' < ' + dumpFile
os.system(restore)
#Want to delete the dump file?
os.remove(dumpFile)
#Close connection
pgConnect.close()
20

Я бы сказал, пойдите с несколькими базами данных и несколькими схемами:)

схемы в postgres очень похожи на пакеты в Oracle, если вы знакомы с ними. Базы данных предназначены для различения целых наборов данных, в то время как схемы больше похожи на сущности данных.

например, вы можете иметь одну базу данных для всего приложения со схемами "UserManagement", "LongTermStorage" и так далее. "UserManagement" будет содержать таблицу "User", как также всех хранимых процедур, триггеров, последовательностей и т. д. это необходимо для управления пользователями.

базы данных-это целые программы, Схемы-это компоненты.

7

ряд схем должен быть более легким, чем ряд баз данных, хотя я не могу найти ссылку, которая подтверждает это.

но если вы действительно хотите сохранить вещи очень отдельными (вместо рефакторинга веб-приложения, чтобы столбец "costomer" был добавлен в ваши таблицы), вы все равно можете использовать отдельные базы данных: я утверждаю, что вы можете легче сделать восстановление базы данных конкретного клиента таким образом-не беспокоя других клиентов.

3

в контексте postgres я рекомендую использовать одну БД с несколькими схемами, так как вы можете (например) объединить все схемы, но не базы данных. По этой причине база данных действительно полностью изолирована от другой базы данных, в то время как схемы не изолированы от других схем в той же базе данных. Если вам по какой - то причине придется консолидировать данные по схемам в будущем, это будет легко сделать по нескольким схемам. С несколькими базами данных вам понадобится несколько db-соединения и собирать и объединять данные из каждой базы данных "вручную" по логике приложения.

последние имеют преимущества в некоторых случаях, но по большей части я думаю, что подход one-database-multiple-schemas более полезен.

2

получить вещи ясно сначала самое время вы хотели бы сделать некоторые БД только для чтения и некоторые чтения/записи так держать схему, используемую только для чтения может храниться на diff БД и чтения / записи схемы в базе данных Diff, хотя я бы предложил вам сохранить Макс 25-30 схемы в одной БД, как вы не хотите, чтобы создать нагрузку на базу данных для журналов для всех схемы

вот одна статья, если вы хотите прочитать больше

-1