Есть ли ограничение на количество баз данных, которые вы можете разместить на одном SQL-сервере?

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

Вопросов

• Существуют ли какие-либо практические ограничения на количество микроданных, которые вы можете / должны иметь на одном SQL Server?
• Может ли это повлиять на производительность сервера?
• Лучше иметь 10000 баз данных по 100 МБ каждая или одну базу данных по 1 ТБ?

Дополнительная информация

Когда я говорю «микро-базы данных», я не имею в виду «микро»; Я просто имею в виду, что мы нацелены на тысячи клиентов, поэтому каждая отдельная база данных будет составлять лишь одну тысячную или менее от общего объема хранилища данных. На самом деле, каждая база данных будет стоить около 100 МБ, в зависимости от того, сколько она использует.

Основная причина использования 10 000 баз данных - это масштабируемость. Дело в том, что V1 системы имеет одну базу данных, и у нас были некоторые неудобные моменты, когда БД напрягалась под нагрузкой.

Это напрягало процессор, память, ввод / вывод - все вышеперечисленное. Несмотря на то, что мы исправили эти проблемы, они заставили нас осознать, что в какой-то момент, даже с самой лучшей в мире индексацией, если мы настолько успешны, насколько надеемся, мы просто не сможем поместить все наши данные в один большой хонкин. ' база данных. Таким образом, для V2 мы разделяем нагрузку на несколько серверов БД.

Я потратил последний год на разработку этого решения. Это одна лицензия на сервер, но в любом случае об этом позаботились, поскольку мы используем виртуальные машины в Azure. Причина, по которой вопрос возникает сейчас, заключается в том, что раньше мы предлагали только крупным учреждениям и сами создавали их. Наш следующий бизнес-заказ - это модель самообслуживания, при которой любой, у кого есть браузер, может зарегистрироваться и создать собственную базу данных. Их базы данных будут намного меньше и гораздо более многочисленными, чем крупные учреждения.

Мы пробовали Azure SQL Database Elastic Pools . Производительность была очень разочаровывающей, поэтому мы переключились на обычные виртуальные машины.

Я работал на серверах SQL с 8-10 тысячами баз данных в одном экземпляре. Это не красиво.

Перезапуск сервера может занять до часа и более. Подумайте о процессе восстановления 10000 баз данных.

Вы не можете использовать SQL Server Management Studio для надежного поиска базы данных в обозревателе объектов.

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

Вы начинаете делать такие вещи, как именование баз данных с номерами, например M01022, и T9945. Попытка убедиться, что вы работаете в правильной базе данных, например, M001022вместо этого M01022, может быть безумной.

Выделение памяти для такого количества баз данных может быть мучительным; SQL Server в конечном итоге выполняет много операций ввода-вывода, что может значительно снизить производительность. Рассмотрим систему, которая регистрирует данные об использовании углерода в 4 таблицах для 10 000 компаний. Если вы делаете это в одной базе данных, вам нужно всего 4 таблицы; если вы сделаете это в 10 000 баз данных, вдруг вам потребуется 40 000 таблиц в памяти. Затраты на работу с таким количеством таблиц в памяти значительны. Любой разработанный вами запрос, который будет выполняться по этим таблицам, потребует не менее 10 000 планов в кэше планов, если используется 10 000 баз данных.

Приведенный выше список представляет собой лишь небольшую выборку проблем, которые вам необходимо спланировать при работе в таком масштабе.

Вы, вероятно, столкнетесь с такими вещами, как служба SQL Server, которая занимает очень много времени для запуска, что может привести к ошибкам Service Controller. Вы можете самостоятельно увеличить время запуска службы, создав следующую запись реестра:

Подраздел: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
Имя: ServicesPipeTimeout
Тип: REG_DWORD
Данные: количество миллисекунд до истечения времени ожидания при запуске службы.

Например, чтобы подождать 600 секунд (10 минут) до истечения срока службы, введите 600000.

С момента написания своего ответа я понял, что речь идет об Azure. Возможно, сделать это на базе данных SQL не так проблематично; возможно, это более проблематично. Лично я, вероятно, разработал бы систему, использующую одну базу данных, возможно, разделенную вертикально на нескольких серверах, но, конечно, не одну базу данных на клиента.

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

Мой случай, почему вы должны использовать 1 базу данных для всех клиентов.

Pros

• Простое обслуживание. Наличие одной БД означает, что вам нужно выполнять задачу обслуживания только в одном месте, а не во многих. Представьте себе кошмар обработки 1000 различных баз данных для резервного копирования. Как насчет обновления статистики по 1000 БД или перестройки индексов или DBCC CHECKDB?

• Развертывание кода. Допустим, у вас есть проблема с хранимой процедурой в коде приложения или отчетности. Вам нужно сделать быстрое изменение ... Теперь вам нужно развернуть это изменение на 1000+ БД. Нет, спасибо, я бы не хотел.

• Легкая видимость. Просто представьте, что SSMS пытается открыть 1000+ БД (вздрагивает) . Это фактически сделало бы проблему бесполезной и потребовало бы удивительное количество времени, чтобы просто открыть и обработать SSMS. Имейте в виду, что если вы сможете придумать приличное соглашение об именах.

Cons

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

• Спектакль. Можно утверждать, что ограничение одной БД на клиента означает, что SQL-серверу придется сканировать меньше данных, чтобы получить запрашиваемую информацию. Однако при правильной структуре данных и хорошей индексации (и возможном разделении) вы, скорее всего, сможете решить эту проблему как проблему, если все сделать аккуратно. Я бы порекомендовал дать каждой таблице, содержащей данные о клиентах, своего рода указание CompanyIDна снижение этих издержек.

В конечном счете, я думаю, что вам лучше всего иметь одну БД для вашего приложения и просто разбивать данные о клиентах внутри самой БД. Проблемы, которые это доставит вам, будут ничем по сравнению с кошмаром управления 1000+ базами данных.

В спецификации максимальной емкости для SQL Server указано ограничение в 32 767.

Что касается того, повлияет ли это на производительность, ответ - да, но то, как это повлияет на производительность и будет ли она существенным, будет зависеть от множества факторов.

Я бы выбрал одну базу данных, если нет веской причины разделить ее на 10 000 баз данных. Одна резервная копия или 10000 резервных копий? Одна проверка целостности или 10000? Может быть веская причина использовать 10 000 небольших БД, но вы не дали достаточно подробностей, чтобы это определить. Вопрос, который вы задали, довольно широк, и просто недостаточно информации, чтобы кто-нибудь знал, каков наилучший ответ.

То, о чем вы говорите, это многопользовательская или многоэкземплярная архитектура. Я просто поднимаю эти термины, так как вы не используете их в своем вопросе, но это то, что вы обсуждаете, называется, и если вы просто включите «многопользовательскую архитектуру» в Google, вы найдете множество ресурсов и дискуссий. об этом, целые книги были написаны на нем.

Некоторые хорошие ресурсы, касающиеся SQL Server, в частности, здесь:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

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

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

Вы говорите о «миллионах» клиентов, думаете о любом крупномасштабном облачном программном обеспечении как о сервисе, Gmail, что бы то ни было, вы вряд ли думаете, что они создают совершенно новую базу данных для каждой новой регистрации, теперь вы?

Могут быть причины, по которым вы действительно хотите облегчить это, например, если вы продаете свой продукт клиенту, который ДОЛЖЕН разместить его в своей собственной инфраструктуре. Но, как правило, SAAS полагается по умолчанию на мультитенантную архитектуру.

Один из недостатков, который я вижу в предложении с единственной базой данных, связан с откатом данных - если у вас есть база данных для каждого арендатора, вы можете восстановить данные каждого клиента независимо (и до определенного момента времени). Если они все находятся в одной базе данных, это становится намного сложнее (и гораздо более подвержено ошибкам, поскольку это, вероятно, должно быть сделано с помощью операторов INSERT / UPDATE / DELETE).

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

Мотивация для шардинга

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

Ответ на проблемы

• Перезапуск сервера занимает много времени: хорошо, но при нормальной работе мы не собираемся перезапускать какие-либо серверы. В конечном итоге система должна быть подключена к сети круглосуточно, поэтому, если у нас будет время простоя, оно должно быть запланировано в любом случае.
• Резервное копирование / аварийное восстановление: мы используем CloudBerry, который автоматизирует все. Не проблема.
• Наименование баз данных / размещение их в SSMS. Соглашение об именовании легко, только на основе имени клиента. Добавьте серийные цифры, если имена являются общими.
• Обслуживание: если каждая база данных настолько мала, насколько я представляю, не нужно перестраивать индексы вручную.
• Развертывание кода: мы используем Entity Framework, поэтому каждое изменение схемы будет автоматически распространяться на каждую базу данных с новыми выпусками. Правда, если мы обнаружим проблему с производительностью, которая может быть исправлена ​​с помощью простой подстройки индекса, не так-то просто ее устранить. С другой стороны, поскольку каждая база данных настолько мала, маловероятно, что на рабочих сегментах будут возникать проблемы с производительностью. И общая база данных остается единой БД, к которой эти проблемы не относятся.

Я буду рад получить ответ от вас в комментариях, если вы думаете, что я что-то упустил!