Для одной из наших систем у нас есть конфиденциальные данные клиента и мы храним данные каждого клиента в отдельной базе данных. У нас есть около 10-15 клиентов для этой системы.
Однако мы разрабатываем новую систему, которая будет иметь 50-100 клиентов, а может и больше. Я думаю, что в этом случае может быть невозможно иметь одну базу данных для каждого клиента (для хранения конфиденциальных записей и истории аудита). Однако я не знаю, является ли это совершенно нормальным или нет, или есть ли другой способ поддержания безопасности.
Есть мысли по этому поводу?
database-design
sql-server-2012
NibblyPig
источник
источник
Ответы:
Управление 100 или 500 базами данных на самом деле ничем не отличается от управления 5 или 10 - вам просто нужно использовать автоматизацию и иметь план масштабируемости (и не планировать использовать функции высокой стоимости на базу данных, такие как зеркалирование во всех клиенты).
На моей предыдущей работе мы использовали эту архитектуру, и я никогда бы не подумал о том, чтобы объединить двух клиентов в одну базу данных, хотя некоторые проблемы могут быть «сложными».
Большим преимуществом являются независимые модели восстановления (
aмогут быть простыми,bмогут быть полными и т. Д.), Возможность восстановления на определенный момент времени (или полного удаления) клиента без нарушения работы других, возможность плавного перемещения ресурсоемкого клиента в свое собственное хранилище или на совершенно другой сервер с минимальной прозрачностью (вы обновляете файл конфигурации или таблицу, которая сообщает приложению, где найти этого клиента).Я отвечаю на некоторые из возражений и / или как подойти к решению проблем в следующих постах:
Обработка растущего числа арендаторов в архитектуре мультитенантной базы данных
Многопользовательская база данных с использованием SQL Server 2008?
Автоматизация резервного копирования большого количества базы данных
Несмотря на все это, я не думаю, что кто-либо из нас может сказать вам, в какой момент управление становится непрактичным для вас - просто знайте, что с любыми конкретными проблемами, с которыми вы сталкиваетесь, вы можете задавать вопросы об этих проблемах индивидуально.
источник
Я рекомендую вам прочитать статью « Многопользовательская архитектура данных» , в которой рассматриваются возможные варианты, а также плюсы и минусы. Подводя итог, он дает три варианта:
Сейчас вы находитесь на стадии отдельных БД, которая предлагает лучшее разделение (изоляция между арендаторами), но является наиболее сложной в управлении. По мере того, как вы становитесь сотнями арендаторов, вы понимаете, что логистика администрирования сотен баз данных далеко не тривиальна. Подумайте о резервном копировании (расположение резервных копий файлов, заданий, расписаний и т. Д.) Подумайте, как вы будете контролировать и управлять распределением файлов, использованием дискового пространства и ростом базы данных на сотнях БД. Подумайте, каков будет ваш сценарий высокой доступности / аварийного восстановления в ближайшем будущем с 1000 арендаторами? 1000 зеркальных БД, 1000 сеансов доставки журналов? Подумайте, что если через 6 месяцев ваша команда разработчиков придет к вам и скажет: «Я знаю, как дать эту замечательную функцию нашему продукту, мы будем использовать репликацию транзакций!», Что вы скажете? «Конечно, позвольте мне создать 500 издателей,"! Не исключено, что вы можете управлять сотнями БД, но если вы планируете это сделать, вам лучше отточить свои навыки работы с PowerShell и прекратить использовать инструменты управления пользовательским интерфейсом прямо сейчас .
Кроме того, необходимо учитывать, что несколько (сотни) БД оказывают измеримое влияние на производительность и стоимость:
Отдельные БД обладают некоторыми преимуществами, хотя из-за изоляции, основным преимуществом является независимое резервное копирование / восстановление.
Такой сценарий, как ваш, идеально подходит для баз данных SQL Azure . Нет администрирования дискового пространства, нет необходимости предоставлять HA / DR, расти до сотен / тысяч БД и т. Д.
источник
На моей предыдущей работе мы размещали не одну базу данных на каждого клиента - в большинстве случаев это было нечто большее! Когда я уходил, в одном кластере MariaDB работало более 4500 баз данных, в другом (иронически меньшем) кластере - почти 7000, а в каждом хостинге находилось 4 «осколка» (совершенно отдельных независимых веб-сервера и сервера баз данных, даже в совершенно отдельном центре обработки данных). 200-500 баз данных на одном сервере MySQL. И эта компания по-прежнему растет на хорошем уровне.
Короче говоря, успех этой компании доказывает, что такая архитектура действительно осуществима. (Предостережение. Вопреки очевидным преимуществам изолированности благодаря использованию отдельных баз данных, доступ ко всем данным осуществлялся через три тесно связанных приложения, которые использовали один и тот же пользователь базы данных / проход! Я подозреваю, что производительность могла бы очень немного снизиться, если бы каждый клиент был отдельный пользователь / пароль - но только немного.)
Из моего опыта тесного сотрудничества с системными администраторами (технически я был программистом в компании, но на самом деле я был лучшим администратором базы данных, и у них был единственный человек, который знал, как настроить брандмауэр!), Связанный с производительностью проблемы сводились к одновременному доступу, сложности / времени запросов, производительности индекса и т. д. - иными словами, все обычные подозрения и количество баз данных на сервере не играли заметной роли, и этот вывод подтвердил высокооплачиваемый специалист Консультанты мы консультировались регулярно.
Суть в том, что вы должны сосредоточить внимание на своем приложении, на своей инфраструктуре, а не на количестве баз данных, которые у вас есть. Всех этих других факторов будет более чем достаточно, чтобы вы были заняты решением проблем производительности и узких мест.
источник