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

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

Настройка «А»:

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Конечный результат - большая база данных со многими таблицами.

Настройка "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Конечный результат - множество баз данных с несколькими таблицами.

При прочих равных условиях (например, количество данных, количество экземпляров приложения и т. Д.), Каковы преимущества и недостатки использования любого из этих подходов? Что может отрицательно сказаться на производительности и обслуживании базы данных? Приложение основано на PHP 5, работает под управлением Apache 2.x, и мы работаем с MySQL 5.x.

Большое спасибо за ваше время и мысли!

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

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

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

Причиной, по которой я пошел с этим подходом, а не с подходом с одной огромной базой данных, был большой размер потенциальной базы данных, которая была бы создана ... каждая из 1000 баз данных имела 200 таблиц, и многие из отдельных таблиц в каждой из базы данных содержали много сотен миллионов строк данных!

Конфигурация одной базы данных потребовала бы, чтобы определенные таблицы (около 8 из них) имели многомиллиардные строки данных, а общий размер базы данных был бы более 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), имя базы данных и имя клиента. Этот контроллер - то, где ваше приложение знает, где находится каждая база данных клиентов.

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

• Ваше приложение может расти столько, сколько вы хотите. Если это веб-SaaS, вы можете создать ферму веб-сервера с балансировкой нагрузки, указывающую на каждую базу данных, в качестве времени входа пользователя.

• Вы можете создать настроенный VIEW / Database для одних клиентов, не влияя на других. Это важно, если вы пытаетесь предложить настройку как часть вашего бизнеса.

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

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

• У вас должен быть другой сервер для репликации. Один и тот же хост может реплицировать множество баз данных (использовать разные порты для каждого сервера на одном хосте), если вы не можете позволить себе одинаковое количество «главных» и «подчиненных» хост-серверов.

  Например, 5 главных серверов + 1 подчиненный сервер с 5 базами данных, работающими на разных портах - просто достаточно оперативной памяти для этого.

• Вы должны использовать инструмент «миграции» для перемещения одной базы данных на другой сервер в любое время.

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

• Вы должны иметь резервное копирование-удаление сборщика мусора, чтобы сделать «последнее резервное копирование» и удалить базу данных, когда клиент покидает вашу компанию.

• У вас должен быть образ базы данных, куда вы экспортируете и используете для новых учетных записей.

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

• Сохраняйте версии всех своих патчей SQL, используя инструмент управления версиями, такой как Subversion или Git, а также создайте свою собственную нумерацию. xxx-4.3.0.sql - иногда исправление происходит неправильно, и вы должны знать, как восстановить / выполнить задачу исправления.

Ну, это все, что я делаю в своей компании с продуктом, имеющим около 5 тыс. Баз данных и около 600 таблиц в каждой.