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

Question

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

Answer 1

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

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

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

Источник:

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

Коммуникационная архитектура LinkedIn

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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