Каков наилучший способ распространения postgresql

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

Ответ 1

Существует четыре уровня, на которых вы можете разделить своих клиентов:

  • Запустите отдельный кластер PostgreSQL для каждого клиента. Это обеспечивает максимальное разделение; каждый клиент находится на отдельном порту с собственным набором системных таблиц, журналом транзакций и т.д.

  • Поместите каждого клиента в отдельную базу данных в том же кластере. Таким образом, каждый из них имеет отдельный логин, но на одном и том же номере порта, и они совместно используют глобальные таблицы, такие как pg_database.

  • Предоставьте каждому клиенту отдельную схему в той же базе данных. Это не требует отдельных идентификаторов пользователей, если они только подключаются через ваше программное обеспечение, потому что вы можете просто установить путь search_path. Конечно, вы можете использовать отдельные идентификаторы пользователей, если хотите.

  • Сделайте customer_id частью первичного ключа для каждой таблицы и не забудьте ограничить это в своем программном обеспечении. Вероятно, это будет лучше, чем дублирование таблиц для каждого из сотен пользователей, но вы должны быть очень осторожны, чтобы всегда отвечать на ваши запросы по customer_id.

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

Без подробностей трудно понять, какая конфигурация будет лучше для вашей ситуации, за исключением того, что если вы хотите разрешить пользователям прямой доступ к базе данных, не просматривая программное обеспечение, вам нужно подумать о том, что видно в системных таблиц с каждой опцией. Посмотрите на pg_database, pg_user и pg_class с точки зрения пользователя, чтобы увидеть, что отображается.

Ответ 2

Я не хочу потерять целостность первичных, начальных ключей и проверок.

Точка систем, таких как Cassandra, когда ваш набор данных или рабочая нагрузка не подходят на одной машине, вы должны отказаться от этих вещей, даже если вы останетесь на postgresql. (Я подробно рассказал в разговоре, который я настоятельно рекомендую: http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2010-what-every-developer-should-know-about-database-scalability-21-3280648).

Итак, Cassandra - это ответ на вопрос: "Если мы знаем, что нам придется отказаться от внешних ключей и присоединяться, что мы можем построить, переосмыслив, как мы проектируем нашу базу данных?"

Если вы никогда не доберетесь до этого, Кассандра будет излишней. (Но вы все равно должны следить за этим разговором.:)