Чи є обмеження в кількості баз даних, які можна розмістити на одному SQL-сервері?

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

Запитання

• Чи є якісь практичні обмеження щодо кількості мікробаз, які ви можете / повинні мати на одному SQL сервері?
• Чи може це вплинути на продуктивність сервера?
• Чи краще мати 10 000 баз даних по 100 МБ у кожній або одну базу даних по 1 ТБ?

Додаткова інформація

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

Основна причина використання 10 000 баз даних полягає в масштабованості. Факт полягає в тому, що V1 системи має одну базу даних, і у нас були деякі незручні моменти, коли БД напружувалася під навантаженням.

Це напружувало процесор, пам'ять, введення / виведення - все вищезазначене. Незважаючи на те, що ми вирішили ці проблеми, вони дали нам зрозуміти, що в якийсь момент, навіть при найкращому індексуванні в світі, якщо ми настільки ж успішні, як ми сподіваємось, ми просто не можемо скласти всі наші дані в один великий гонкін 'база даних. Отже, для V2 ми посилюємо, тому ми можемо розділити навантаження між декількома серверами БД.

Я провів останній рік, розробляючи це осколкове рішення. Це одна ліцензія на один сервер, але все одно, про це ми подбаємо, оскільки ми використовуємо VM на Azure. Причина, що зараз виникає питання, полягає в тому, що раніше ми пропонували лише великим установам і створювали кожну самостійно. Наступне наше замовлення - це модель самообслуговування, де кожен, хто має браузер, може зареєструватися та створити власну базу даних. Їх бази даних будуть набагато меншими та значно чисельнішими, ніж великі установи.

Ми спробували еластичні пули бази даних Azure SQL . Продуктивність була дуже невтішною, тому ми перейшли до звичайних VM.

Я працював над SQL серверами з 8 до 10 тис. Баз даних в одному екземплярі. Це не дуже.

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

Ви не можете використовувати студію управління SQL Server для надійного пошуку бази даних у Провіднику об’єктів.

Резервні копії - це кошмар, оскільки для того, щоб зробити резервні копії, потрібно мати ефективне рішення щодо відновлення після аварій. Сподіваємось, ваша команда чудово розраховує все .

Ви починаєте робити такі речі, як іменування баз даних з числами, як-от M01022і T9945. Намагання переконатися, що ви працюєте в правильній базі даних, наприклад, M001022замість цього M01022, може звести з розуму.

Виділення пам'яті для багатьох баз даних може викликати біль; SQL Server в кінцевому підсумку робить багато вводу-виводу, що може бути реальним зниженням продуктивності. Розглянемо систему, яка записує деталі використання вуглецю в 4 таблицях для 10 000 компаній. Якщо ви робите це в одній базі даних, вам знадобляться лише 4 таблиці; якщо ви робите це в 10 000 баз даних, раптом вам потрібно 40 000 таблиць в пам'яті. Витрати на обробку такої кількості таблиць у пам’яті суттєві. Будь-який запит, який ви розробляєте, буде відповідати цим таблицям, потребуватиме щонайменше 10 000 планів у кеші планів, якщо використовується 10 000 баз даних.

Наведений вище список - це лише невеликий вибірки проблем, які потрібно планувати при роботі в такому масштабі.

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

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

Наприклад, щоб зачекати 600 секунд (10 хвилин) до вичерпання часу обслуговування, наберіть 600000.

З часу написання своєї відповіді я зрозумів, що це питання - це про Azure. Можливо, зробити це на базі даних SQL не так вже й проблематично; можливо, це більш проблематично. Особисто я, мабуть, створив систему, використовуючи єдину базу даних, можливо, розподілену вертикально на декількох серверах, але, звичайно, не одну базу даних на кожного клієнта.

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

Мій випадок, чому ви повинні використовувати 1 Базу даних для всіх клієнтів.

Плюси

• Простота обслуговування. Наявність однієї БД означає, що виконувати завдання з обслуговування потрібно лише в одному місці, а не в багатьох. Уявіть кошмар обробки 1000 різних баз даних для резервного копіювання. Як щодо оновлення статистики на 1000 БД або відновлення індексів або DBCC CHECKDB?

• Розгортання коду. Скажімо, у вас є проблема зі збереженою процедурою у вашому коді програми чи звіті. Вам потрібно зробити швидку зміну ... Тепер ви повинні розгорнути ці зміни до 1000+ БД. Ні, дякую, я б краще не став.

• Легка видимість. Просто зображте SSMS, що намагається відкрити 1000+ БД (здригається) . Це практично зробить проблему марною і забирає дивовижну кількість часу, щоб просто відкрити та надати SSMS. Майте на увазі, це якщо ви зможете придумати гідну конвенцію про іменування.

Мінуси

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

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

Зрештою, я думаю, що найкраще ставити один БД для вашої програми та просто розбивати дані клієнта всередині самої БД. Неприємності, які він вам доставить, будуть нічим в порівнянні з кошмаром управління 1000+ базами даних.

Технічні характеристики максимальної ємності для SQL Server зазначають, що обмеження становить 32 767.

Що стосується того, чи вплине це на ефективність, відповідь - так, але те, як це вплине на продуктивність та чи буде воно суттєвим, залежатиме від безлічі факторів.

Я б працював з однією базою даних, якщо немає вагомих причин розділити її на 10 000 баз даних. Одне резервне копіювання чи 10 000 резервних копій? Одна перевірка цілісності, або 10 000? Можливо, є вагома причина використовувати 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).

Дякую всім, хто відповів - дуже ціную бали, які ви дали мені задуматися. Загальне відчуття, яке я отримав, було те, що єдина база даних є кращою, але я хотів би додати деякі компенсаційні моменти на користь стриженої архітектури та вирішити деякі проблеми, про які згадували інші люди.

Мотивація заточування

Як вже згадувалося в (оновленому) запитанні, ми прагнемо до масових продажів по всьому світу з буквально мільйонами користувачів. Завдяки найкращому апаратному забезпеченню та індексації у світі один сервер БД не візьме на себе навантаження, тому ми повинні мати можливість розподіляти на декількох серверах. І як тільки вам доведеться шукати, на якому сервері ввімкнено дані даного клієнта, це не набагато більше роботи, щоб надати їм спеціалізовану базу даних, яка робить простішими з точки зору збереження даних людей чітко відокремленими.

Відповідь на занепокоєння

• Перезапуск сервера займає багато часу: Гаразд, але в нормальній роботі ми не збираємося перезапускати жодні сервери. Зрештою, система повинна бути в режимі онлайн 24/7, тому, якщо ми матимемо простої, це все одно доведеться планувати.
• Резервне копіювання / відновлення після аварій: ми використовуємо CloudBerry, який автоматизує все. Не проблема.
• Іменування баз даних / розміщення їх у SSMS: Конвенція про іменування легко, просто ґрунтуючись на імені клієнта. Додайте серійні цифри, якщо спільні імена.
• Технічне обслуговування: Якщо кожна база даних є такою ж невеликою, як я передбачаю, не повинно виникати ніякої необхідності переробляти індекси вручну.
• Код розгортання: ми використовуємо Entity Framework, тому кожна зміна схеми автоматично буде передана до кожної бази даних з новими випусками. Однак, правда, що якщо ми виявимо проблему з продуктивністю у виробництві, яку можна виправити за допомогою простого перетворення індексу, не просто так просто висунути її туди. З іншого боку, якщо кожна база даних є такою малою, навряд чи виникнуть проблеми з показниками стоппер-шоу на виробничих осколках. І загальна база даних залишається єдиною БД, до якої ці побоювання не стосуються.

Я буду радий почути від вас коментарі, якщо ви думаєте, що я чогось не пропускаю!