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

Question

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

Заранее благодарю

Answer 1

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

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

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

"Ничего общего", "отдельная база данных" или одна база данных на клиента

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

"Общее все", или "общая схема", или "одна база данных на планету"

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

Между "общим ничем" и "общим всем" находится "общая схема".

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

• Арендаторы совместно используют базу данных, но у каждого арендатора есть своя именованная схема.Стоимость находится между "ничем не делился" и "всем делился".;большим системам обычно требуется меньше серверов, чем "ничего общего", и больше серверов, чем "все общее".
• Гораздо лучшая изоляция, чем "делился всем".Не такая большая изоляция, как "ничем не делился".(Вы можете ПРЕДОСТАВЛЯТЬ и ОТЗЫВАТЬ разрешения на схемы.)
• Аварийное восстановление для одного клиента требует восстановления одной из многих схем.Это либо относительно легко, либо довольно сложно, в зависимости от вашей СУБД.
• Обслуживание проще, чем "ничего общего".;не так просто, как "поделиться всем".Относительно просто написать хранимую процедуру, которая будет выполняться в каждой схеме базы данных.Проще разделить общие таблицы между арендаторами, чем с "общим ничем".
• Обычно активных арендаторов на сервер больше, чем "ничем не поделившихся", что означает, что они совместно используют (деградируют) больше ресурсов.Но не так плохо, как "делился всем".

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