Множество схем и огромных таблиц

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

Заранее спасибо

Ответ 1

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

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

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

"Без общего доступа", "отдельная база данных" или одна база данных для каждого арендатора

Самый дорогой клиент. (Большое количество клиентов подразумевает большое количество серверов.)
Высочайшая степень изоляции данных.
Аварийное восстановление для одного арендатора является простым и понятным.
Техническое обслуживание теоретически сложнее, потому что изменения должны выполняться в каждой базе данных. Но ваши dbms могут легко поддерживать запуск хранимых процедур в каждой базе данных. (Например, SQL Server имеет незарегистрированную системную хранимую процедуру, например sp_msforeachdb. Возможно, вы можете написать свой собственный.) "Ничего общего" тоже наиболее легко настраивается, но это также вызывает проблемы с обслуживанием.
Наименьшее количество строк в таблице. Скорость запроса близка к оптимальной.

"Все разделяемое" или "общая схема" или "одна база данных на планете"

Наименее дорогостоящий арендатор.
Самая низкая степень изоляции данных. Каждая таблица имеет столбец, который идентифицирует, к какому арендатору принадлежит строка. Поскольку ряды арендаторов смешиваются в каждой таблице, это относительно просто, чтобы случайно представить другие данные арендатора.
Аварийное восстановление для одного арендатора относительно сложно; вам необходимо восстановить отдельные строки во многих таблицах. С другой стороны, однопользовательская катастрофа относительно необычна. Большинство бедствий, вероятно, затронут всех арендаторов.
Структурное обслуживание проще, учитывая, что все арендаторы используют таблицы. Это увеличивает нагрузку на связь, хотя, поскольку вы должны общаться и координировать каждое изменение с каждым арендатором. Это легко настраивается.
Максимальное количество строк в таблице. Быстрый запрос сложнее, но зависит от количества арендаторов и количества строк. Вы можете легко опрокинуться на территорию VLDB.

Между "shared nothing" и "shared all" находится "общая схема".

"Общая схема"

Арендаторы совместно используют базу данных, но у каждого арендатора есть собственная именованная схема. Стоимость падает между "общим ничем" и "разделяет все"; большие системы обычно нуждаются в меньшем количестве серверов, чем "ничего общего" , больше серверов, чем "общее".
Гораздо лучше изолировать, чем "разделять все". Не так много изоляции, как "ничего общего" . (Вы можете использовать разрешения GRANT и REVOKE для схем.)
Аварийное восстановление для одного арендатора требует восстановления одной из многих схем. Это либо относительно легко, либо довольно сложно, в зависимости от ваших dbms.
Обслуживание проще, чем "ничего общего" ; не так просто, как "разделять все". Относительно просто написать хранимую процедуру, которая будет выполняться в каждой схеме в базе данных. Легче распространять общие таблицы среди арендаторов, чем с "общим ничем".
Обычно более активные арендаторы на сервер, чем "shared nothing", что означает, что они делят (деградируют) больше ресурсов. Но не так плохо, как "поделился всем".

У Microsoft есть хорошая статья о многопользовательской архитектуре с более подробной информацией. (Ссылка на одну страницу многостраничного документа.)