Проектирование базы данных SaaS - несколько баз данных? Трещина?

Question

Я видел SaaS-приложения, размещенные разными способами. Это хорошая идея для разделения функций и модулей по нескольким базам данных? Например, помещать такие вещи, как таблица «Пользователь» в одну БД и таблицы, относящиеся к функциям / приложениям, в другую БД и, возможно, другие общедоступные таблицы в другой БД?

Answer 1

Начните с одной базы данных. Разделение данных / функциональности, когда это требуется проекту.

Вот что мы можем узнать из LinkedIn:

• Одна база данных не работает
• Ссылочная целостность невозможна
• Любая потеря данных - проблема
• Кэширование хорошо, даже когда оно скромно эффективно
• Никогда не стоит недооценивать траекторию роста

Источник:

Архитектура LinkedIn

Архитектура связи LinkedIn

Answer 2

Высокая масштабируемость - хороший блог для масштабирования приложений SaaS. Как уже упоминалось, разделение таблиц между базами данных, как вы предложили, как правило, плохая идея. Но похожая концепция - это сегментирование, когда вы сохраняете одну (или похожую) схему, но разделяете данные на несколько серверов. Например, пользователи 1-5000 находятся на сервере1, а пользователи 5000-10000 на сервере2. В зависимости от запросов, которые использует ваше приложение, это может быть эффективным способом масштабирования.

Answer 3

Для приложений SaaS вы используете несколько баз данных для нескольких арендаторов, но обычно не разбиваете их по модулям.

Это самая распространенная модель, которую я видел в дизайне приложений SaaS. Ваша базовая схема реплицируется для каждого арендатора, добавляемого в приложение.

Answer 4

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

Answer 5

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

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

Answer 6

Зачем вообще использовать базу данных?

Я думаю, что это хорошая идея - использовать распределенные системы хранения, такие как Hadoop, Voldemort (project-voldemort.com, разработанный и используемый LinkedIn).

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

Answer 7

Есть множество способов сделать это, но проблемы мультитенантности идут глубже, чем просто модель данных. Я ненавижу подключать продукт, но зацените SaaSGrid моей компании, в которой я работаю, Apprenda . Мы являемся облачной операционной системой, которая позволяет вам писать SOA-приложения для одного клиента ( не стесняйтесь использовать NHibernate для доступа к данным), который автоматически внедряет мультитенантность в ваше приложение. Когда вы публикуете свое приложение, вы можете делать такие вещи, как выбор модели данных (изолированной базы данных или совместно используемой), и SaaSGrid будет развертываться соответствующим образом, и ваше приложение будет работать без каких-либо изменений кода - просто напишите код, как если бы это было для одного владельца!

Answer 8

Сохраняйте естественный дизайн (денормализуйте столько, сколько необходимо, нормализуйте как можно меньше). Разделите модель БД на ее модули и помните о принципах, ориентированных на обслуживание, сопоставляя данные со службой (которая владеет данными).

Answer 9

Задайте себе вопрос: что вы получаете, перемещая все в отдельные базы данных?

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