PostgreSQL: лучше ли использовать несколько баз данных с одной схемой каждая или одну базу данных с несколькими схемами? - PullRequest
Новая
       30

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

126 голосов
/ 20 июля 2009

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

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

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

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

Теперь мне нужно сделать то же самое с PostgreSQL (проект становится зрелым, а MySQL ... не удовлетворяет всем требованиям).

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

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

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

Все мои базы данных / схемы будут всегда иметь одинаковую структуру!

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

ОБНОВЛЕНИЕ 2012

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

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

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

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

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

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

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

Ответы [ 6 ]

96 голосов
/ 21 июля 2009

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

21 голосов
/ 21 июля 2009

Определенно, я пойду на подход «одна дБ-много-схем». Это позволяет мне вывести всю базу данных, но восстановить ее очень легко, разными способами:

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

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

  1. Создать шаблон-схему
  2. Если необходимо дублировать, переименуйте его с новым именем
  3. Дамп
  4. Переименуй обратно
  5. Восстановить дамп
  6. Волшебство сделано.

Я написал две строки в 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]

# Temperary 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 previous 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()
8 голосов
/ 20 июля 2009

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

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

Например, у вас может быть одна база данных для всего приложения со схемами «UserManagement», «LongTermStorage» и так далее. Тогда «UserManagement» будет содержать таблицу «User», а также все хранимые процедуры, триггеры, последовательности и т. Д., Необходимые для управления пользователями.

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

3 голосов
/ 21 июля 2009

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

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

2 голосов
/ 04 августа 2016

В контексте PostgreSQL я рекомендую использовать одну базу данных с несколькими схемами, как вы можете (например, UNION ALL) для всех схем, но не для баз данных. По этой причине база данных действительно полностью изолирована от другой базы данных, в то время как схемы не изолированы от других схем в той же базе данных.

Если по какой-то причине вам придется консолидировать данные по схемам в будущем, это будет легко сделать по нескольким схемам. При наличии нескольких баз данных вам потребуется несколько db-соединений, а также сбор и объединение данных из каждой базы данных «вручную» с помощью логики приложения.

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

0 голосов
/ 14 ноября 2017

Получите ясность:

Во-первых, большую часть времени вы хотели бы сделать некоторые базы данных доступными только для чтения, а некоторые - для чтения / записи. Таким образом, сохранить схему, используемую только для чтения, можно в разных базах данных, а схему чтения / записи - в другой базе данных, хотя я бы посоветовал вам сохранить схему максимум 25-30 в одной базе данных, так как вы не хочу создавать нагрузку на базу данных для журналов для всей схемы.

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

...