Плюсы и минусы использования многих схем в PostgreSQL, а не только одной?

Для большого приложения SAAS (поддерживаемого PostgreSql 9.4) с более чем 300 000 учетными записями (и растущими), каковы преимущества и недостатки использования схемы для каждой учетной записи для разделения данных по сравнению с помещением всех данных в одну схему и использованием внешних ключей для разбить его в запросах?

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

Так какие плюсы и минусы мне не хватает?

— Harel
источник

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

— Даниэль Верите

Я перестраиваю старую систему, в которой есть такое количество учетных записей (и даже большее количество пользователей). Он использует общий подход (используя mySql) и отлично работает в плане производительности. Моя задача - поддерживать этот уровень производительности, но добавлять к нему удобство обслуживания.

— Харель

@Harel Мне любопытно, вы пробовали его со схемами 400k или переключились на другую архитектуру / технологию?

— sthzg

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

— Харель

Очевидно, вы имеете дело с одинаковыми таблицами в каждой пользовательской схеме. Рассматривали ли вы наследство для этого? Это может дать вам лучшее из обоих миров для некоторых случаев использования. Есть также некоторые ограничения . Вы можете иметь отдельную схему для каждого пользователя и при этом выполнять поиск по всем пользовательским таблицам одновременно очень удобно.

Связанные с:

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

— Эрвин Брандштеттер
источник

Я буду смотреть на наследство. Тем не менее, меня беспокоит масштаб здесь. Везде, где я читаю, люди говорят о стратегии мультитенантных схем, но ссылаются на десятки, сотни или тысячи схем. В одном месте упоминаются схемы 20К. Вопрос в том, является ли 400K схем слишком много? Это приведет к безумию файлового дескриптора и уничтожит сервер? Я толкаю это?

— Харель

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

— Харель

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

— Харель

Из этой статьи influentive.io/… Я думаю, что многосхемный режим не является хорошим способом для большого числа арендаторов. Столбец tenant_id (древний путь) подходит лучше.

— Сяохуэй Чжан