Зверніть увагу: я відповідаю з точки зору SQL Server, тому я згадую деякі концепції, характерні для SQL Server, але я вважаю, що всі ці поняття мають еквіваленти в інших основних платформах RDBMS з подібними перевагами та обмеженнями.
Я також, ймовірно, продовжуватиму редагувати цю відповідь, коли я думаю про інші потенційні плюси / мінуси.
Ну, це дійсно залежить від схеми, обсягу тощо. Що саме зберігає магазин? Чим вона відрізняється від зберігання даних про 50 000 котів або 50 000 продуктів або 50 000 крилатих горіхів?
Існує кілька причин (крім власного аспекту розміру), чому ви не хочете зберігати дані для 50 000 різних клієнтів в одній базі даних, якщо дійсно ці дані можуть бути повністю відокремлені клієнтом (не включаючи таблиці пошуку, такі як поштові індекси або таблиці специфічних для додатків, які можуть перейти в єдину центральну базу даних:
якщо один клієнт переростає програму, не існує простого способу вилучення лише своїх даних і переміщення їх на інший екземпляр, сервер тощо для масштабування, якщо ви не плануєте заздалегідь і розділити щось на зразок CustomerIDі не маєте 50 000 груп файлів (ви обмежені до 15 000 розділів у будь-якому випадку, або до 1000, якщо ви перебуваєте у більш старій версії SQL Server і маєте занадто багато груп файлів, може бути катастрофічним ) Також зауважте, що для розділення потрібна Enterprise Edition.
якщо виявиться, що всі ваші клієнти просто занадто великі для цього випадку, масштабування означає отримати нове обладнання та перемістити всю базу даних там (і, можливо, зробити це знову вниз).
видалення клієнта може бути однаково болючим, оскільки вам доведеться видалити кілька% рядків з дуже великих таблиць, і це буде недешево.
у вас, швидше за все, буде широкий розподіл даних про клієнтів (один клієнт із мільярдом рядків, інший клієнт - 5000). Це може призвести до таких обставин, як нюхання параметрів та згубна ефективність, пов’язана з кардинальністю та якістю плану (оскільки, ймовірно, ви будете повторно використовувати ті самі плани для тих самих запитів проти дуже різних наборів даних).
всі ваші клієнти підпорядковуються точно таким же планам угод про домовленість та хаотичність. У вас є або вся база даних у повному режимі відновлення з n-хвилинними резервними копіями журналу, або ви прості та покладаєтесь на резервні копії full + diff. Якщо вам доведеться повернутись через помилку клієнта або потрібно відновити базу даних до певного часу, це впливає на кожного клієнта.
є можливість помилок у пошуку даних - помилки, у яких, наприклад, пункти можуть призвести до того, що один клієнт бачить дані іншого клієнта або всі дані інших клієнтів.
можуть виникнути юридичні наслідки (деякі компанії вимагатимуть суворих вимог щодо того, щоб ви не розміщували їх дані в тій самій базі даних, що і будь-яка інша компанія, і особливо їхні конкуренти).
якщо безпека даних будь-якого клієнта важлива, то досягти цього набагато простіше, використовуючи розділення бази даних, ніж розділення всередині таблиці.
Деякі переваги щодо наявності кожного клієнта в окремій базі даних (або принаймні наявності декількох баз даних, кожна для групи клієнтів):
- за розміром це займе приблизно однакового розміру на диску.
- масштабування простіше, оскільки ви можете просто перемістити базу даних (або багато) на інший сервер.
- видалення клієнта та всіх його даних приблизно дорівнює
DROP DATABASE.
- ви використовуєте більше пам’яті для планів (або у вас менше планів у кеші на кожного клієнта), але принаймні ці плани стосуються даних у відповідних базах даних і менш схильні до проблем зі нюхом статистики / параметрів.
- Ви можете легко мати різні угоди про домовленості та домовленості, розміщуючи деякі бази даних повністю, а інші - просто. Також повернення або відновлення до певного часу впливає лише на цього замовника.
- Ви можете легко розміщувати різні бази даних (скажімо, клієнти з високим пріоритетом) на більш швидких введеннях / виводух. Ви можете зробити це в одній базі даних з групами файлів, але це набагато складніше в управлінні (принаймні IMHO).
Деякі недоліки:
- окрім розміру, ви, мабуть, не захочете мати 50 000 баз даних на одному екземплярі SQL Server, тому це, ймовірно, означатиме масштабування на декількох серверах.
- час запуску збільшується, тому що для запуску кожної бази даних є деякі притаманні накладні витрати.
- додаток має бути трохи розумнішим - замість того, щоб просто зазначати CustomerID на пункті де, він повинен динамічно підключатися до бази даних CustomerID. З правильним середнім рівнем це не важко, але це зміна.
- так, у вас є багато копій одних і тих же таблиць і процедур, але код і схема однакові в базах даних, просто дані відрізняються. Тож розгортання змін коду / схеми тепер є лише циклом замість одного виконання.
- технічне обслуговування дещо відрізняється, коли ви керуєте 50 000 базами даних - знову ж загальний розмір приблизно такий же, але процес повинен змінитися - ви не можете просто дефрагментувати / перевстановити / створити резервну копію всіх 50 000 баз даних відразу. Сказавши, що на своїй попередній роботі я керував екземплярами з 500-1000 однакових баз даних, і різниця між керуванням 3 однаковими базами даних та 750 однаковими базами даних - це просто час, який потрібно.