Мы не смогли попробовать базу данных для пользовательской установки. Планируете восстановить?

Question

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

Теперь мы столкнулись с тем, что сейчас развертывания очень медленные.

Стоит ли когда-нибудь задумываться о переносе всех баз данных обратно в одну, чтобы уменьшить сложность среды? Или это слишком рискованная идея?

Проблема, которую я вижу сейчас, состоит в том, что очень трудно объединить эти базы данных с сохранением ссылочной целостности (первичные ключи таблиц разных баз данных не могут быть явно дифференцированы).

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

Answer 1

Ваш вопрос довольно широкий.

a) Убедитесь, что объединенные базы данных не страдают от снижения производительности с помощью таких вещей, как операторы JOIN, когда, скажем, 1000 баз данных объединены, даже если каждая из них мала. Что касается вашей ссылочной целостности ... которая, как я полагаю, основана на auto_increment ... вы можете заменить эти отношения, изменив схему и вытеснив UUID или аналогичное уникальное непоследовательное значение. Или даже пара суррогатных ключей в дополнение к вашему автоматическому приращению PK.

b) Выполните бенчмаркинг , чтобы убедиться, что ваше приложение будет реагировать в пределах производительности

в) Существует ли прямая рентабельность инвестиций для этого? Каковы долгосрочные выгоды от затрат на миграцию? Стоимость уменьшенной сложности увеличена (если есть)?

d) Как это влияет на ваши планы резервного копирования и аварийного восстановления? Это делает их дешевле? Помедленнее? Дороже?

Подход к инструментам абстракции и управления:

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

Answer 2

Для перенесенных данных ... UUID базы данных клиента один может начинаться с 10000000, UUID базы данных клиента два может начинаться с 20000000. UUID базы данных клиента три может начинаться с 30000000 .....

По моему мнению, когда вы размещаете базу данных для своих клиентов, лучше всего будет использовать одну базу данных, которая обрабатывает несколько клиентов. Конечно, вам нужно добавить таблицу «клиенты» для записи клиентов и столбец «customer_id» для всех данных верхнего уровня, которые находятся в таблице, и включить проверки во все ваши SQL, чтобы гарантировать, что представление клиента ограничено их собственные данные.

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