2012-05-01 5 views
10

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

ответ

10

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

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

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

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

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

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

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

7

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

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

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

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

+0

Люблю разговор! +1 – Abdo

+0

вышеупомянутая ссылка не приводит к разговору. Не могли бы вы разместить соответствующую ссылку. – SahuKahn

+0

@SahuKahn попробуйте те два: * видео: http://pyvideo.org/video/313/pycon-2010--what-every-developer-should-know-abou * слайды: http: //www.slideshare ,net/jbellis/what-every-development-should-know-about-database-scalability-pycon-2010 –

Смежные вопросы