Я хочу посмотреть, какой метод является более эффективным с точки зрения запросов к базе данных.
В многопользовательской базе данных запросы являются лишь частью проблемы. Другими частями проблемы являются стоимость, изоляция и защита данных, обслуживание и аварийное восстановление. Это важно; Вы не можете учитывать только эффективность запросов в многопользовательской базе данных.
Мультитенантные решения варьируются от одной базы данных на каждого арендатора (ничего общего) до одной строки на каждого арендатора (все совместно).
«Ничего общего», «отдельная база данных» или одна база данных на каждого арендатора
- Самый дорогой для каждого клиента. (Большое количество клиентов подразумевает большое количество серверов.)
- Высшая степень изоляции данных.
- Аварийное восстановление для одного арендатора просто и понятно.
- Техническое обслуживание теоретически сложнее, потому что изменения необходимо выполнять в каждой базе данных. Но ваши базы данных могут легко поддерживать запуск хранимых процедур в каждой базе данных. (SQL Server имеет недокументированную системную хранимую процедуру, например sp_msforeachdb. Вы, вероятно, можете написать свою собственную.) «Простое совместное использование» также проще всего настраивать, но это также вызывает больше проблем при обслуживании.
- Наименьшее количество строк в таблице. Скорость запросов близка к оптимальной.
«Shared everything» или «общая схема» или «одна база данных на планету»
- Наименее дорогой на одного арендатора.
- Самая низкая степень изоляции данных. В каждой таблице есть столбец, в котором указывается, к какому арендатору относится строка. Поскольку строки арендаторов смешаны в каждой таблице, случайное раскрытие данных других арендаторов относительно просто.
- Аварийное восстановление для одного арендатора является относительно сложным; Вы должны восстановить отдельные строки во многих таблицах. С другой стороны, катастрофа для одного арендатора является относительно необычной. Большинство бедствий, вероятно, затронет всех жильцов.
- Структурное обслуживание проще, учитывая, что все арендаторы разделяют таблицы. Это увеличивает коммуникационную нагрузку, потому что вы должны общаться и координировать каждое изменение с каждым арендатором. Это не легко настроить.
- Наибольшее количество строк в таблице. Быстрые запросы сложнее, но это зависит от того, сколько арендаторов и сколько строк. Вы можете легко опрокинуться на территорию VLDB.
Между «общим ничем» и «всем общим» находится «общая схема».
«Общая схема»
- Арендаторы совместно используют базу данных, но у каждого арендатора есть своя именованная схема. Стоимость падает между «делится ничем» и «делится всем»; для больших систем обычно требуется меньше серверов, чем для «общего доступа», больше серверов, чем для «общего доступа».
- Гораздо лучшая изоляция, чем "поделился всем". Не так много изоляции, как «ничего не поделился». (Вы можете предоставлять и отзывать разрешения для схем.)
- Аварийное восстановление для одного арендатора требует восстановления одной из многих схем. Это либо относительно легко, либо довольно сложно, в зависимости от вашей базы данных.
- Обслуживание проще, чем «ничего не поделился»; не так просто, как «поделился всем». Относительно просто написать хранимую процедуру, которая будет выполняться в каждой схеме в базе данных. Распределение общих таблиц между арендаторами проще, чем с помощью функции «Ничего не поделено».
- Обычно больше активных арендаторов на сервер, чем «ничего не делятся», что означает, что они совместно используют (ухудшают) больше ресурсов. Но не так плохо, как «поделился всем».
Microsoft имеет хорошую статью о мультитенантной архитектуре с более подробной информацией. (Ссылка на одну страницу многостраничного документа.)