Мы привели базу данных попытки к сбою на пользовательскую установку. Запланировать восстановиться?
Существует веб-приложение, которое находится в производственном режиме в течение приблизительно 3 лет к настоящему времени. Исторически, из-за различных причин там был принят решение для использования базы данных - на пользовательскую установку.
Теперь мы столкнулись с тем, что теперь развертывание является очень медленным.
Мы должны когда-либо полагать, что кладение обратно всех баз данных к единственной уменьшает сложность среды? Или это - слишком опасная идея?
Проблема, которую я вижу теперь, состоит в том, что очень трудно объединить эти базы данных с сохранением ссылочной целостности (первичные ключи другой базы данных' таблицы не могут, очевидно, дифференцироваться).
Базы данных не являются так очень большими, таким образом, у нас нет многого преимуществами уменьшенной загрузки при наличии нескольких баз данных.
2 ответа
Ваш вопрос довольно широкий.
a) Убедиться, что объединенные базы данных не страдают от снижения производительности при использовании таких вещей, как операторы JOIN, когда, скажем, объединяется 1000 баз данных, даже если каждая из них небольшая. Что касается ссылочной целостности... которая, как я предполагаю, основана на auto_increment ... вы можете заменить эти отношения, изменив схему и заменив UUID или аналогичное уникальное, непоследовательное значение. Или даже парой суррогатных ключей в дополнение к вашему PK с автоматическим инкрементом.
b) Проведите бенчмаркинг, чтобы убедиться, что ваше приложение будет отвечать в пределах производительности
c) Есть ли прямая окупаемость инвестиций для этого? Каковы долгосрочные выгоды по сравнению с затратами на миграцию? Стоит ли уменьшение сложности возросших затрат (если таковые имеются)?
d) Как это повлияет на ваши планы резервного копирования и аварийного восстановления? Станут ли они дешевле? Медленнее? Дороже?
Абстракция и инструменты управления:
если бы это был я, то в зависимости от ситуации я бы сохранил масштабируемость, которая обеспечивается за счет разделения на клиентов, и создал набор инструментов управления для абстрактного создания одной виртуальной базы данных. Используя эти инструменты, вы сможете получить упрощенное управление без потери технической гибкости. Я подозреваю, что вы хотите упростить стоимость управления всеми этими базами данных (исходя из вашего заявления о развертывании). Создание "панели управления" для вашей фермы может быть хорошим способом упростить сложную систему (особенно когда развертывания могут использовать различные версии схем).
Для перенесенных данных... UUID базы данных первого клиента могут начинаться с 10000000, UUID базы данных второго клиента могут начинаться с 20000000. UUID базы данных третьего клиента может начинаться с 30000000.....
По моему мнению, когда вы размещаете базу данных для своих клиентов, единая база данных, которая работает с несколькими клиентами, в целом является лучшей идеей. Конечно, вам нужно добавить таблицу "customers" для записи клиентов, столбец "customer_id" для всех данных верхнего уровня, которые находятся в таблице, и включить проверки во все ваши SQL, чтобы убедиться, что представление клиента ограничено его собственными данными.
Я бы создал новую базу данных с дополнительными столбцами, а затем протестировал ее с фиктивным клиентом или тремя на некоторое время, чтобы убедиться, что все ошибки стерты. Затем я бы перенес всех клиентов одного за другим, проверяя, вписываются ли данные.