Что следует иметь в виду, если я хочу объединить много БД в одну БД?

Question

Я работаю с полдюжины БД. Все БД имеют одинаковые схемы, одинаковые SP и т. Д. В беседе с человеком, который изначально проектировал БД, большая часть мотивации для использования многих БД была эффективностью; альтернативой может быть добавление столбца практически к каждой таблице и указание в базе данных, указывающее, над каким набором данных ведется работа, в результате чего получается одна гигантская (и, следовательно, более медленная) БД вместо нескольких БД samll. Вместо того, чтобы иметь столбец, чтобы указать, какой набор данных запрашивается, строка подключения используется для выбора базы данных, к которой выполняется обращение.

Единственная причина, по которой мне действительно не нравится эта организация, заключается в том, что она требует много дублирования кода и, следовательно, вредит обслуживанию. Например, каждый раз, когда я хочу изменить хранимую процедуру, мне нужно запускать оператор alter для каждой базы данных.

Одно из решений, которое я рассмотрел, - объединить все данные в одну большую базу данных, добавив дополнительный столбец повсюду, чтобы указать, в какую базу данных будут входить данные, если бы я не объединил их. Затем я могу разделить все таблицы по значению этого столбца. Теоретически, результатом всего этого является то, что базовое представление всех самих данных будет морально таким же, как и сейчас, но без избыточности в индексах, схемах, SP и т. Д.

Мои вопросы:

1. Это хорошая идея? Есть ли лучший способ сделать это?
2. Есть ли в этом какие-то ошибки?
3. Повлияет ли это на производительность?

Answer 1

Каждый будет иметь дело с этим в какой-то момент. Мое личное мнение состоит в том, что несколько баз данных являются болью в задней части и не быстрее. Они - боль из-за головной боли обслуживания. Добавление дополнительного столбца в каждую таблицу по мере необходимости не сильно замедлит ваш процесс, если индексация настроена правильно. И ваше обслуживание будет намного проще. Кроме того, выполнение транзакций между несколькими БД может быть хлопотным и включать MTC.

Кстати, использование одной базы данных часто называют мультитенантной базой данных. Вы можете исследовать это немного. Но я бы по возможности избегал таких БД, как это.

Answer 2

Я не такой, как Рэнди.

Мультитенантная модель имеет свои преимущества.

С одной стороны, обслуживание не сильно отличается от того, есть ли у вас 5 баз данных или 500. В какой-то момент вы перестаете смотреть на обслуживание отдельных баз данных и посмотрите на набор. Да, вы должны сериализовать резервные копии, и вы не можете выполнять переоценку / перестройку индекса для всех баз данных одновременно.

Но для изменений кода в нескольких более или менее идентичных базах данных существуют простые способы написать множество вещей, которые нужно сделать для нескольких баз данных, не отрывая при этом лишних усилий. Я использую инструмент под названием SQLFarms Combine (теперь продается JNetDirect), но есть и другие предложения, такие как RedGate MultiScript, с которыми я не играл.

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

Answer 3

Я бы за объединение этих баз данных. В SQL Server встроены другие средства для учета потенциальных падений производительности очень большой базы данных, такие как дополнительная индексация на втором физическом диске, разбиение на разделы, кластеризация и т. Д. Головная боль и накладные расходы, связанные с развертыванием обновлений схемы для этого множества различных баз данных может занимать много времени, когда его легко обрабатывать в одной базе данных. Я думаю, что в таких случаях SQL Server действительно хорошо масштабируется - пусть сервер баз данных сделает то, для чего он предназначен, и обеспечит оперативный доступ к вашим данным. Вы можете сосредоточиться на разработке приложений и оставить модель хранения для SQL Server.

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