Стратегия «одна база с клиентским разделителем» против «каждому по базе»

Question

[Дмитрий Кинаш]

Кто-то сталкивался с задачей создать многопользовательское решение с многочисленными пользовательскими данными? Что бы не 2-3 таблицы, как в интернет-магазинах, а от 10 и значительно выше.

Первое что приходит в голову — это добавить дополнительное индексируемое поле во все таблицы с айдишником пользователя. Но некоторые из потенциальных клиентов хотят, что бы СУБД с их конфедициальными данными находилось на их площадках, а на нашем сервере происходила исключительно обработка. В связи с этим появилась мысль, а не попробовать ли сразу разносить разных клиентов по разным базам? Я немного попереваривал в голове эту мысль и сформировал следующие преимущества и недостатки.

Плюсы второго решения:
1) Легкость в администрировании: легко выдаются тестовые аккаунты и так же легко удаляются; можно обеспечить договорной уровень бекапирования данных (с выдачей клиенту или локальным хранением) и восстановить по требованию архив за любую отметку времени. Все это делается в разы труднее, если хранить все данные в одном хранилище.
2) Возможность создания и управления базами, которые расположены на различных серверах (в том числе и на клиентском).

Минусы второго решения:
1) Сложность поддержки и доработки общей системы — вместо одной базы придется дорабатывать целую ферму баз
2) В случае локального размещения данных у клиентов нужно с ними еще договариваться про их обновление
3) При работе будущей системы вместо одного (или пачки, в случае балансировки) коннекшена к базе, через который можно получать данные различных клиентов, нужно будет поддерживать для каждого пользовательского подключения отдельное соединение.

При сравнении двух подходов явно видно противостояние легкости разработки против легкости поддержки.

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

P.S. В качестве СУБД выбрана PostgreSQL, так как под нее заточена часть функционала, но интересует мнение и по другим реляционным БД.

P.S.S. Пересекающиеся данные между различными компаниями отсутствуют. Нет необходимости делать консолидацию. Вся общая справочная информация находится в ином сервисе.

Answer 1

[Илья Севостьянов]

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

2) Отдаем сию виртуалочку клиенту, он ее у себя запускает и наш софт конектится к ней как к сетевой БД.
Одминов в свою очередь просим по возможности нас на нее пустить по ssh
(Здесь поджидает проблема если у клиента говеная локалка или админь — упырь, в последнем случае все очень плохо
вот таких мы пускаем к себе на виртуалочки предусмотрительно развернутые на хостинге поближе к клиенту)

PROFIT!!! — убиваем несколько проблем:
1) Клиент не причастен к конфигурации не то чтобы БД, но и системы с необходимой экосистемой
2) Развертывание — проще простого.
3) Разбор полетов можно производить на Time Stamp виртуалки в реальном окружении. (Так как не всегда БД является источником проблем)
4) Миграция тоже очень проста, мы потихонечку уговариваем клиентов таки перебираться «в облака» (у кого нет проблем с интернетом)

Comments

[Дмитрий Кинаш]

Идея с виртуалкой очень изящна. Спасибо за дельную мысль.

Answer 2

[Анатолий]

Еще один вариант есть: одна база — каждому по таблице. Выглядеть будет не красиво, но уберет по как минимум одному минусу из обоих фронтов.
В пределах одной базы таблицами манипулировать просто.
В случае локального размещения данных у клиентов, в любом случае придется договариваться про их обновление.

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

Comments

[Дмитрий Кинаш]

Поэтому я и уточнил в самом начале своего вопроса, что каждому пользователю для хранения его личных данных нужно порядка 10 таблиц. Можно создавать таблицы под каждого клиента, но тогда 100 пользователей = 1000 таблиц… Только что проверил — в рамках базы нет ограничений на количество таблиц, так что стоит рассмотреть и этот вариант. Спасибо за идею.

[Анатолий]

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

[Дмитрий Кинаш]

Знакомо, я около 4 лет назад делал систему для торговца запчастями. Его справочники тоже превышали табличные лимиты и приходилось делать на подтаблицы даже в рамках одного вендора, а потом использовать union при подборе. А если ближе к теме, то я уже склоняюсь к архитектуре «каждому клиенту — свое подмножество таблиц». Если за сегодня-завтра никто не отпишется, то отмечу ваше предложение как решение.

Answer 3

[Ruslan_Y]

Еще вариант, перекликающийся с первым ответом, оставить одну базу, но разнести таблицы клиентов по разным схемам. Избегается столпотворение таблиц в одной схеме, при этом довольно легко все обновлять и давать доступ каждому клиенту только к его данным. Админится только 1 БД, что тоже, в данном случае, облегчает жизнь.

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

Answer 4

[Илья Севостьянов]

Очень много других факторов которые так же влияют на принятие подобного рода решений,
например потянет ли ваше железо кучу пользователей, таким образом чтобы им было комфортно работать, стабильный ли у Вас / у них коннект.
А если их число удвоить например (я про пользователей)
У нас была отчасти похожая задача, в итоге у клиента свой БД — но мы ее постоянно реплицируем к себе, кстати так и обновляем свою обновленную версию разворачивая назад. Естественно на это время работа с базой на стороне клиента заблокирована архитектурно приложением до завершения.
Да и что касается обновления то рано или поздно вам все равно необходимо будет автоматизировать процесс.

Перед нами стояли проблемы и железа и коннекта и его скорости, не знаю как у Вас.

PS: Личный совет, если уж и будете БД у клиентов держать, то не подпускайте их IT-долбоящеров к обновлению или конфигурированию.

Comments

[Дмитрий Кинаш]

Идея с обновлением в процессе репликации для клиентских баз понятна. Спасибо.
По поводу «IT-долбоящеров» — сразу видно, что у Вас они много крови попили :)