Одна велика база даних проти кількох менших

У нас виникла ситуація, коли ми можемо (A) розгортати екземпляри програм в одній базі даних MySQL, використовуючи префіксацію таблиці або (B) використовувати різні бази даних MySQL для кожного екземпляра програми, наприклад,

Налаштування "A":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Кінцевим результатом є великий db з багатьма таблицями.

Налаштування "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Кінцевим результатом є багато баз даних з деякими таблицями.

Усі речі рівні (наприклад, кількість даних, кількість екземплярів додатків тощо), які плюси та мінуси щодо будь-якого підходу? Що може бути згубним для роботи та обслуговування бази даних? Додаток засновано на PHP 5, запустіть Apache 2.x, а ми використовуємо MySQL 5.x.

Велике спасибі за ваш час та думки!

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

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

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

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

Конфігурація однієї бази даних вимагала б, щоб певні таблиці (приблизно 8 з них) мали багатомільярдні рядки даних, а загальний розмір db був би понад 10 Тб. Нам вдалося мати декілька серверів із 5 Тб пам'яті RAID 10, з багатьма базами даних на кожному.

Це я б робив! Сподіваюся, це допоможе прийняти рішення ... :)

Чи є програма, для якої ви створюєте програму SaaS? Якщо так, я б запропонував розглянути третій підхід - мати один БД із загальною структурою для всіх екземплярів додатків з однією різницею - додати стовпець userid / applicationid у всі таблиці. Це значно зменшить витрати на розробку / обслуговування вашої програми. Це, на мій досвід, є одним з найкращих підходів до зберігання даних про багатьох орендарів.

Також дивіться цю чудову книгу Microsoft про архітектуру даних для багатьох орендарів

Він також підкреслює переваги / недоліки щодо згаданих вами підходів.

Налаштуванням B простіше керувати

Кожен tablenсидить у іншій папці. Це може бути дуже корисно, якщо ви не хочете перевіряти межі ОС .

Наприклад, мій роботодавець розміщує MySQL для CRM-системи автосалонів. Клієнт має 800 автосалонів. Кожна база дилерів має 160 таблиць. Це 128 000 таблиць.

• У розділі Налаштування A всі 128 000 таблиць будуть розміщені під однією базою даних.
• У розділі Налаштування B кожен набір із 160 таблиць знаходиться у підпапці під / var / lib / mysql.

З точки зору ОС та її здатності обробляти i-вузли (або таблиці FAT для Windows), що включає наявність максимальної кількості файлів у папці:

• У розділі Налаштування A ви б турбуєтесь про 128 000 файлів у одній папці. Чи може ваша ОС підтримувати такі файли в одній папці?
• У налаштуваннях B не хвилюйтеся.

Якщо вам довелося налаштувати структури таблиць за допомогою ALTER TABLEабо іншого DDL:

• У розділі Налаштування A вам слід буде скриптувати потрібний DDL за допомогою PHP (або спеціалізованих сценаріїв MySQL) проти конкретної назви таблиці та відповідних запитів, перш ніж отримати доступ до неї та внести зміни
• У розділі Налаштування B підключіться до правої бази даних, а потім щоразу отримуйте доступ до однойменної таблиці. Парадигма доступу завжди буде чистою:
  • Конкретна база даних
  • Конкретна папка під /var/lib/mysql
  • Спеціальна таблиця.

Якщо ви хочете розмістити різні бази даних на різних дисках:

• У розділі Налаштування A символьні посилання для кожної таблиці, переміщеної на окремий диск, лише посилять проблему "кількості входів у папці". Доступ до вводу / виводу диска та загального доступу до таблиці ще більше ускладнює та збільшує загальне завантаження сервера, оскільки .frmфайли неодноразово отримують доступ.
• У розділі Налаштування B просто перемістіть цілу папку бази даних в окрему версію даних. Дисковий введення / вивід можна поширювати на вимогу.
• CAVEAT: сильно не рекомендується використовувати InnoDB

Якщо говорити метафорично, що б ви хотіли?

• гігантська квартира з однією спальнею, однією ванною кімнатою та однією кухнею (SetupA)
• кілька квартир, кожна з яких має свою спальню, ванну кімнату та кухню (SetupB)

Що стосується кріплення радіатора в квартирі:

• За допомогою програми A кожен орендар може бути незручним і його потрібно залучати, тому що вам доведеться розмовляти з постраждалими орендарями перед усіма, як це справа кожного
• Завдяки програмі B, окрім того, як чути щось стукати по стіні або в трубах, орендарі можуть продовжувати своє приватне життя
• Цей список та його метафори можуть продовжуватись і продовжуватись

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

У мене також є продукт SaaS і використовую ту саму програму, що і Дейв Рікс.

У кожного замовника є своя база даних

Я б ще кілька пропозицій:

• Ви повинні мати "контролер" бази даних "збалансований навантаження" ("master-master"), який зберігає розташування бази даних (ip), ім'я бази даних та ім'я клієнта. Цей контролер - це те, де ваша програма знає, де знаходиться кожна база даних клієнтів.

• Ваша програма може бути де завгодно - ви можете мати бази даних для багатьох центрів обробки даних по всьому світу.

• Ваша заявка може зростати скільки завгодно. Якщо це Web SaaS, ви можете зробити збалансовану навантаженням ферму веб-сервера, вказуючи на кожну базу даних, як час, коли вхід клієнта.

• Ви можете створити індивідуальні VIEW / Database для деяких клієнтів - не впливаючи на інших. Це важливо, якщо ви намагаєтесь запропонувати налаштування як частину вашого бізнесу.

• Ви можете налаштувати дві веб-ферми + ферми баз даних: одну для "EDGE" та іншу для версій "STABLE". Тоді вам потрібно буде мати невелику групу клієнтів, які бажають перевірити речі та підтвердити, що все працює так, як очікувалося (іншими словами, забезпечення якості [QA]), перш ніж звернутися до всіх своїх клієнтів.

• Ви повинні мати автоматизовану роботу з резервного копіювання на базу даних принаймні один раз на день.

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

  Наприклад, 5 головних серверів + 1 підлеглий сервер з 5 базами даних, що працюють на різних портах - просто достатньо оперативної пам'яті, щоб зробити це.

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

• Вам слід перенести VIP-клієнтів на більш захищений / доступний сервер баз даних, щоб захистити ваш дохід. Пам'ятайте, що багато разів 20% клієнтів представляють 80% вашого доходу. Подбайте про особливих клієнтів.

• У вас повинен бути збір резервного копіювання "сміття", робити "останню резервну копію" та видаляти базу даних, коли клієнт покидає вашу компанію.

• Ви повинні мати зображення бази даних, де ви експортуєте та використовуєте для нових облікових записів.

• Потрібно мати інструмент виправлення баз даних, щоб застосувати нові виправлення до існуючих облікових записів.

• Зберігайте версії всіх своїх патчів SQL, використовуючи такий інструмент для версій, як subversion або git, а також створюйте власну нумерацію. xxx-4.3.0.sql - іноді виправлення йде не так, і ви повинні знати, як відновити / виконати завдання виправлення.

Ну, це все, що я роблю в своїй компанії з продуктом, який має близько 5-ти баз даних з приблизно 600 таблицями.