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

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

Вопросы

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

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

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

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

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

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

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

37 голосов | спросил Shaul Behr 29 PM00000090000004431 2017, 21:15:44

6 ответов


74

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

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

Вы не можете использовать 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, которые запускают очень много времени, что может привести к ошибкам Service Controller. Вы можете увеличить время запуска службы самостоятельно, создать следующую запись в реестре:

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

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


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

ответил Max Vernon 29 PM00000090000001331 2017, 21:53:13
17

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

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

Pros

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

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

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

Против

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

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

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

ответил Zane 29 PM000000100000004131 2017, 22:03:41
16

Требования к максимальной емкости для SQL Server заявляет, что существует ограничение в размере 32 767.

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

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

ответил Tony Hinkle 29 PM00000090000004031 2017, 21:28:40
6

О чем вы говорите, это архитектура multi-tenant vs multi-instance . Я просто поднимаю эти термины, потому что вы не используете их в своем вопросе, но это то, что вы обсуждаете, называется, и если вы просто подключите «многопользовательскую архитектуру» к 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

Я был бы с другими ответами, в том, что я бы поклонился strong по отношению к мульти-арендатору по умолчанию, если у вас нет веских причин для поддержки multi-instance.

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

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

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

ответил Ivan McA 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 01 Sep 2017 10:58:00 +0300 2017, 10:58:00
5

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

Мотивация для очертания

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

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

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

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

ответил Shaul Behr 31 AM000000110000001031 2017, 11:22:10
4

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

ответил Darshan 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 07 Sep 2017 12:34:43 +0300 2017, 12:34:43

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132