В какой момент одна база данных на клиента становится неосуществимой?

31

Для одной из наших систем у нас есть конфиденциальные данные клиента и мы храним данные каждого клиента в отдельной базе данных. У нас есть около 10-15 клиентов для этой системы.

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

Есть мысли по этому поводу?

database-design sql-server-2012

— NibblyPig
источник

Я не знаю плюсов и недостатков наличия нескольких баз данных на сервере (у меня никогда не было с этим проблем), но концепция многих схем technet.microsoft.com/en-us/library/dd207005.aspx в одной базе данных предлагает изоляция и безопасность. Таким образом, вы можете попробовать эту архитектуру.

— Александрос

2

Разделение схемы @Alexandros предлагает немного, но не позволяет использовать отдельные модели восстановления, выполнять резервное копирование по разным графикам, восстанавливать одного клиента в определенный момент времени, легко удалять одного клиента, легко перемещать одного клиента и т. Д.

— Аарон Бертран

4

Я видел системы с 3000+ баз данных (по 1 на клиента) на одном сервере. Я бы не стал сильно беспокоиться - просто следите за тем, чтобы вы тщательно планировали ресурсы и следили за тем, как увеличивается число клиентов.

— Макс Вернон

Вы можете прочитать это, в частности, отметьте даты и комментарии ops: stackoverflow.com/questions/5596755/…

— NotMe

48

Управление 100 или 500 базами данных на самом деле ничем не отличается от управления 5 или 10 - вам просто нужно использовать автоматизацию и иметь план масштабируемости (и не планировать использовать функции высокой стоимости на базу данных, такие как зеркалирование во всех клиенты).

На моей предыдущей работе мы использовали эту архитектуру, и я никогда бы не подумал о том, чтобы объединить двух клиентов в одну базу данных, хотя некоторые проблемы могут быть «сложными».

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

Я отвечаю на некоторые из возражений и / или как подойти к решению проблем в следующих постах:

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

— Аарон Бертран
источник

6

Вам также понадобится хорошее соглашение об именах, применяемое последовательно.

— Гринстоун Уокер

Спасибо, это отличные ссылки. Это не совсем проблема управления (на данный момент), я был просто обеспокоен тем, что все может остановиться. Но, похоже, я не должен беспокоиться об этом и просто убедиться, что смогу справиться со всем этим. Так что спасибо!

— NibblyPig

@ Аарон, у меня похожий сценарий в OMS, где у меня есть несколько семинаров, которые обрабатывают заказ, и они независимы. Семинар выбирается по адресу заказа (Заказчика). Таким образом, клиент может иметь заказы в нескольких рабочих местах. Так что это сложно, когда нужно загрузить историю заказов клиентов, так как нужно идти на каждый сервер базы данных.

— Навраттан Ядав

15

Я рекомендую вам прочитать статью « Многопользовательская архитектура данных» , в которой рассматриваются возможные варианты, а также плюсы и минусы. Подводя итог, он дает три варианта:

отдельные БД
отдельные схемы
общая схема

Сейчас вы находитесь на стадии отдельных БД, которая предлагает лучшее разделение (изоляция между арендаторами), но является наиболее сложной в управлении. По мере того, как вы становитесь сотнями арендаторов, вы понимаете, что логистика администрирования сотен баз данных далеко не тривиальна. Подумайте о резервном копировании (расположение резервных копий файлов, заданий, расписаний и т. Д.) Подумайте, как вы будете контролировать и управлять распределением файлов, использованием дискового пространства и ростом базы данных на сотнях БД. Подумайте, каков будет ваш сценарий высокой доступности / аварийного восстановления в ближайшем будущем с 1000 арендаторами? 1000 зеркальных БД, 1000 сеансов доставки журналов? Подумайте, что если через 6 месяцев ваша команда разработчиков придет к вам и скажет: «Я знаю, как дать эту замечательную функцию нашему продукту, мы будем использовать репликацию транзакций!», Что вы скажете? «Конечно, позвольте мне создать 500 издателей,"! Не исключено, что вы можете управлять сотнями БД, но если вы планируете это сделать, вам лучше отточить свои навыки работы с PowerShell и прекратить использовать инструменты управления пользовательским интерфейсом прямо сейчас .

Кроме того, необходимо учитывать, что несколько (сотни) БД оказывают измеримое влияние на производительность и стоимость:

физическое место на диске будет менее эффективно используется (каждая база данных должна иметь некоторую свободную комнату, вы будете иметь , что свободную комнату , умноженной на ряде БД)
Невозможно создать выделенный диск журнала для интенсивных задач записи, вам придется переместить все эти LDF-файлы в одно (или более) хранилище SSD.
Запись в журнал будет менее эффективной при частых фиксациях, поскольку они распространяются на множество отдельных записей блоков журнала по сравнению с агрегированием в одну (вы получите недостаточно используемые блоки журналов). Посмотрите, что такое LSN: регистрационный порядковый номер, чтобы понять, о чем я говорю.

Отдельные БД обладают некоторыми преимуществами, хотя из-за изоляции, основным преимуществом является независимое резервное копирование / восстановление.

Такой сценарий, как ваш, идеально подходит для баз данных SQL Azure . Нет администрирования дискового пространства, нет необходимости предоставлять HA / DR, расти до сотен / тысяч БД и т. Д.

— Ремус Русану
источник

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

— NibblyPig

И как только ваша автоматизация будет достаточно хорошо развита для поддержки отдельных баз данных для каждого клиента, это не гигантский скачок, чтобы выделить отдельные виртуальные машины для каждого клиента. Это, в конце концов, то, что делают «облачные» хостинговые компании. Согласитесь, что это, возможно, хороший вариант использования SQL Azure

— Гэвин Кэмпбелл

2

На моей предыдущей работе мы размещали не одну базу данных на каждого клиента - в большинстве случаев это было нечто большее! Когда я уходил, в одном кластере MariaDB работало более 4500 баз данных, в другом (иронически меньшем) кластере - почти 7000, а в каждом хостинге находилось 4 «осколка» (совершенно отдельных независимых веб-сервера и сервера баз данных, даже в совершенно отдельном центре обработки данных). 200-500 баз данных на одном сервере MySQL. И эта компания по-прежнему растет на хорошем уровне.

Короче говоря, успех этой компании доказывает, что такая архитектура действительно осуществима. (Предостережение. Вопреки очевидным преимуществам изолированности благодаря использованию отдельных баз данных, доступ ко всем данным осуществлялся через три тесно связанных приложения, которые использовали один и тот же пользователь базы данных / проход! Я подозреваю, что производительность могла бы очень немного снизиться, если бы каждый клиент был отдельный пользователь / пароль - но только немного.)

Из моего опыта тесного сотрудничества с системными администраторами (технически я был программистом в компании, но на самом деле я был лучшим администратором базы данных, и у них был единственный человек, который знал, как настроить брандмауэр!), Связанный с производительностью проблемы сводились к одновременному доступу, сложности / времени запросов, производительности индекса и т. д. - иными словами, все обычные подозрения и количество баз данных на сервере не играли заметной роли, и этот вывод подтвердил высокооплачиваемый специалист Консультанты мы консультировались регулярно.

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

— Kromey
источник