SaaS: одна БД на клиента, или общая база данных?

Question

[KingOfNothing]

Предположим, стоит задача разработать CRM-систему и предоставлять к ней доступ в виде SaaS, что значит, что клиентов будет много, но при этом данные разных клиентов недоступны другим. Под клиентом понимается один аккаунт, например, аккаунт фирмы «Рога и копыта» для ведения учета своих клиентов.


Видно два варианта хранения данных: хранить все в общей базе данных и разделять права логикой приложения, или хранить данные в базе индивидуальной для каждого клиента? какие есть недостатки и преимущества первого и второго вариантов?


Дополнительные условия:

В качестве СУБД возьмем, для примера, MySQL, а в качестве платформы облако Amazon.

Comments

[KingOfNothing]

Зачем рассматривать вариант с разными базами данных? — для возможности редактирования клиентом набора полей в сущностях.

Answer 1

[abarmot]

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

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

Если же база одна — в скором времени какая-нибудь быстро растущая таблица станет «неуправляемой» и серьезно просадит производительность. Конечно можно разносить такие таблицы на партиции, но в нашей ситуации есть более интересное решение.

Надо держать несколько БД и в каждой несколько сотен компаний. При этом новые базы можно добавлять по мере развития.
Какое-то время вам вообще будет достаточно одной базы.

Несколько рекомендаций:

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

2. во все таблицы с клиентскими данными внести поле COMPANY_ID. Более того внести его в состав всех первичных и внешних ключей. Т… е. первичный ключ таблички ORDER будет (COMPANY_ID, ID)

3. ID инкрементировать в рамках компании, а не всей таблицы. Т.е. у каждой компании будет заказ с ID = 1,
2 и т.д.

Пример:

COMPANY (id, name) — «системная» таблица с компаниями-клиентами

ORDER( company_id, id, customer ) — «клиентская» таблица заказов
PRODUCT( company_id, id, name ) — каталог товаров компании
ORDER_ITEM( company_id, order_id, product_id) — продукты в заказе

первичные ключи:
в ORDER и PRODUCT — (company_id, id)
в ORDER_ITEM — (company_id, order_id, product_id)

внешние ключи в ORDER_ITEM:
(company_id, order_id) → ORDER( company_id, id)
(company_id, product_id) → PRODUCT( company_id, id)

Такой подход дает во-первых максимальную изолированность данных компании.
Во-вторых — возможность переселиения компания из одной БД в другую без конфликта первычных ключей.

Если будут вопросы — пишите в местную почту ;)
Удачи.

Comments

[abarmot]

… и да — Postgres вам в помощь ;)

[Kot Matpockuh]

"3. ID инкрементировать в рамках компании, а не всей таблицы. Т.е. у каждой компании будет заказ с ID = 1,
2 и т.д."

т.е. программно? или тот же mysql может такое реализовать?

[Gromilo]

Postgresql тоже так не умеет. Но и не надо (почти)

Если первичный ключ (company_id, id), то нам без разницы что в id, главное чтобы внутри одной компании не было повторений. Т.е. после переноса на другой инстанс придётся выставлять сиквенс как max(id). Неприятно, но не смертельно.

Answer 2

[darkdimius]

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

Answer 3

[ndubinkin]

Вариант с БД под каждого клиента — выглядит извращенным. А возможность организации клиентом полей в формах можно и в структуру БД изначально заложить.

Comments

[KingOfNothing]

Чем аргументируете извращенность? Можно заложить в структуру, но тогда теряем простоту и скорость! как можно выполнять очень быстрый поиск по такой структуре с разными параметрами? Возможно, приведете пример подобной структуры?

[abarmot]

а вы представьте:
— решили вы добавить новое поле… ))))
…

Answer 4

[hexen]

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

Если одна база:
+
Удобно оперировать одной базой
Удобно накатывать скрипты обновления на одну базу
Удобно администрировать одну базу

— база разрастается сильно, если много клиентов (существенный минус)
Таблицы разрастаются быстродействие снижается

Если много баз
+
база не разрастается сильно
Таблицы не разрастаются

— Не удобно оперировать несколькими базами базой
Не удобно накатывать скрипты обновления на много баз
Не удобно администрировать много баз, усложняются административные интерфейсы

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