Які проблеми виникнуть у мене зі створенням бази даних на кожного клієнта?

Я пам’ятаю з подкастів stackoverflow, що Fog Creek використовує базу даних для клієнта для Fogbugz . Я припускаю, що означає, що сервери Fogbugz On Demand мають 10 тисяч тисяч баз даних.

Ми тільки починаємо розробляти веб-додаток і маємо подібну проблему вирішити (багато клієнтів з власними ізольованими даними).

Які проблеми слід очікувати при використанні бази даних на кожного клієнта? Як я можу їх вирішити?

Мої початкові думки

Переваги бази даних на одного клієнта

• Простіша база даних
• Простіші резервні копії - ви можете створювати резервні копії кожного клієнта по черзі, не впливаючи на інших клієнтів.
• Полегшує експорт даних клієнтів.
• Краща ефективність кешу - запис у одну з більш активних таблиць впливає лише на одного клієнта, який виконував запис.
• Легше масштабувати обладнання. Наприклад, коли нам потрібно перейти від 1 до 2 серверів, ми просто переміщаємо половину наших клієнтів на новий сервер.

Недоліки

• Чи може MySQL впоратися з 5000 базами даних? Хіба продуктивність смокче?
• Зміни схеми можуть бути важкими для копіювання у всіх базах даних. Ми дійсно мали б мати автоматизований план для цього, наприклад, версію схеми та сценарію, який розуміє, як перенести базу даних з однієї версії в іншу.
• Робити що-небудь спільне для всіх наших клієнтів може бути незручно або неможливо
• Подібно до вище, але будь-яка аналітика, яку ми хочемо виконати для всіх наших клієнтів, може бути неможливою. Як нам, наприклад, відстежувати використання всіх клієнтів?

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

1. З єдиною базою даних всі повинні бути в одній версії, незалежно від того. Оновити одних клієнтів, а не інших неможливо. Це може бути проблематично, якщо клієнт хоче виправити програму, яка не готова до широкого випуску.
2. З єдиною базою даних, коли ви робите оновлення, кожен клієнт не працює. Якщо щось піде не так, кожен клієнт накручується.
3. За допомогою єдиної бази даних набагато складніше придушити ресурси. Тобто, якщо один клієнт забиває базу даних, важче дати їм більше ресурсів окремо від усіх інших.
4. Набагато складніше дозволити користувачам розміщувати власні версії вашої програми. Якщо ви будуєте рішення, яке буде використовуватися великими підприємствами, це часто є нестандартним. Їх ІТ-відділ хоче повного контролю над доступом до системи.
5. Мабуть, дешевше масштабувати бази даних, а не масштабувати їх. Тобто, інвестувати в більш швидке обладнання для розміщення однієї бази даних, щоб керувати ними всіма, напевно, дорожче, ніж можливість масштабування клієнтів на менших, менш дорогих серверах баз даних. Я не можу сказати це остаточно, оскільки це дуже залежить від серверного програмного забезпечення. Якщо ви дотримуєтесь MySQL, це, мабуть, так, оскільки витрати на ліцензування незначні. Однак, якщо, наприклад, ви переходите на SQL Server, масштабування стає значно дорожчим, якщо ви не використовуєте середовище VPS і не буде витрата на збільшення масштабу та зменшення змін. Але я можу сказати, що як тільки ваша база даних стає дуже великою, управління потребує все більш високого рівня знань. Дуже великі бази даних вимагають розігруватися з декількома групами файлів і підштовхувати певні індекси до різних шпинделів, щоб отримати кращу продуктивність. Коротше кажучи, вони можуть ускладнитися дуже швидко.

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

На мій досвід, ви не повинні створювати одну базу даних на кожного клієнта. Дозвольте навести приклад:

Минулого року я працював із 70 базами даних (набагато менше 5000), кожна з тією ж схемою і все. Теоретично все пішло б як було заплановано (як ви згадуєте у розділі переваг), але насправді не так багато. У нас було багато проблем з оновленням схем, підтримкою користувачів, оновленням програмного забезпечення, ви його називаєте. Це було жахливо.

Ми використовували Firebird, і мене прийняли на роботу після відвантаження товару, але це дало мені знання ніколи не працювати з окремими базами даних.

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

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

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

Оскільки, як зазначив Гайус, mysql "бази даних" - це лише схеми, якщо все працює з одного і того ж серверного екземпляра, ви можете просто визначити ім'я таблиць, які ви намагаєтеся змінити, або отримати інформацію з:

alter schema.table ...
select ... from schema.table

...

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

...

Також пам’ятайте, що вони не використовують mySQL для обміну стеками, вони використовують SQL Server.

І я не маю уявлення про те, яка саме продуктивність буде в mysql в такому масштабі, я не думаю, що я ніколи не потрапляв за 30 "баз даних" в mysql.

У мене є клієнт Web / DB Hosting, який має 750+ клієнтських баз даних з однаковою кількістю таблиць (162) та однаковими структурами таблиць. У поєднанні, всі дані клієнта мого клієнта загалом 524 ГБ (95% InnoDB)

Уявіть, що всі ці бази даних змагаються за 13G пулу буфера innodb на дев'яти серверах БД за допомогою кругової реплікації. Масштабування за допомогою цієї конфігурації обладнання було недостатньо. Відразу ми рекомендували клієнту масштабувати.

Нещодавно ми перенесли цього клієнта на 3 сервери БД з набагато більшими кінськими силами (За будь-яку ціну, тримайтеся подалі від SSD у середовищах з високим записом, ВЖЕ! !!!). Ми оновили їх з MySQL 5.0.90 до MySQL 5.5.9. Драматичні відмінності побачили майже миттєво.

Масштабування також слід враховувати, оскільки якщо у вас сотні клієнтів, які потрапляють на однакові ресурси пам’яті та диска, масштабування зменшує їх використання лінійно (O (n)), де n базується на кількості серверів БД у багатомастерному середовищі.

Що стосується мого клієнта, моя компанія скорочує його з 9 серверів БД (Quad Code, 32 ГБ оперативної пам’яті, 824G RAID10) до більш швидких серверів БД (Dual HexaCore [правильних 12 процесорів], 192 ГБ оперативної пам’яті, 1,7 ТБ RAID10) MySQL 5.5 .9 (щоб таблиця скористалася кількома процесорами). Крім того, уявіть собі 150 Гб буферного пакету innodb у 50 розділах по 3 ГБ кожна (декілька пулів буферів InnoDB - нова функція в MySQL 5.5). Менший масштаб, але масштабний масштаб, працював на унікальну інфраструктуру мого клієнта.

МОРАЛ ІСТОРІЇ : Масштабування або зменшення масштабів не завжди є рішенням, якщо у вас погано розроблені таблиці. Що я маю на увазі, це так: Якщо на сторінках індексів є сукупність ключів для одноколінних індексів, запити ключів із розділених частин індексів призводять до сканування таблиці після сканування таблиці або, принаймні, до індексів, які ніколи не використовуються через те, що їх виключає запит MySQL Оптимізатор. Просто немає заміни правильному дизайну.

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

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

Єдиний недолік, який я можу побачити, - вам доведеться вручну оновлювати кожну базу даних під час створення нової версії. Це може бути легко автоматизовано.