Идеи для объединения тысяч баз данных в одну базу данных - PullRequest
3 голосов
/ 11 марта 2009

У нас есть сервер SQL, который имеет базу данных для каждого клиента, и у нас есть сотни клиентов. Итак, представьте себе следующее: база данных001, база данных002, база данных003, ..., база данных999. Мы хотим объединить все эти базы данных в одну базу данных.

Мы хотим добавить столбец siteId, 001, 002, 003, ..., 999.

Мы изучаем варианты, чтобы сделать этот переход максимально плавным. И мы хотели бы услышать любые ваши идеи. Это ОЧЕНЬ сложная проблема.

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

Есть идеи, ребята?

Ответы [ 8 ]

7 голосов
/ 11 марта 2009

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

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

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

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

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

4 голосов
/ 11 марта 2009

Почему вы хотите это сделать?
Вы можете прочитать о Мультитенантной архитектуре данных , а также прослушать SO # 19 (около 40-50 минут) об этом проекте.

3 голосов
/ 11 марта 2009

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

  • Сверните все данные в консолидированные таблицы в одну основную консолидированную базу данных (далее - консолидированная БД).
  • Эти таблицы должны иметь такой идентификатор, как SiteID.
  • Создание новых баз данных с существующими именами.
  • Создание представлений со старыми именами таблиц, которые используют безопасность на уровне строк для запросов к таблицам в консолидированной БД, но используют SiteID для фильтрации.
  • Настройте базы данных для цепочки владения несколькими базами данных, чтобы учетные записи служб не могли «случайно» запрашивать базовые таблицы в консолидированной БД. Доступ должен осуществляться через представления или хранимые процедуры и другие конструкции, которые будут обеспечивать безопасность на уровне строк. Теперь, если это одна и та же учетная запись службы для всех сайтов, вы можете избежать цепочки владения несколькими БД и назначить права на объекты в консолидированной БД.
  • Переписать хранимые процедуры, чтобы либо обработать изменение (поскольку они теперь ссылаются на представления и не знают, как попасть в базовые таблицы и включить SiteID), либо использовать вместо них триггеры вместо, чтобы перехватывать запросы на обновление и помещать соответствующие специфичная для сайта информация в базовых таблицах.
3 голосов
/ 11 марта 2009

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

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

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

Теперь все ваши запросы, хранимые процедуры, представления, файлы udf необходимо будет переписать, чтобы гарантировать, что siteid является их частью. Обратите особое внимание на любой динамический SQL. В противном случае вы могли бы показывать информацию клиента A клиенту B. Клиентам это не нравится. Однажды мы привели клиента из отдельной базы данных в основное приложение (когда они решили, что не хотят платить за отдельный сервер). Разработчик пропустил только одно место, где должен быть добавлен client_id. К сожалению, это отправляло электронные письма каждому клиенту относительно информации, являющейся собственностью этого клиента, и, что еще хуже, это был ночной процесс, который продолжался посреди ночи, поэтому об этом не было известно до следующего дня. (Разработчику очень повезло, что его не уволили.) Суть в том, чтобы быть очень осторожным, когда вы делаете это и тестируете, тестируете, тестируете и еще тестируете. Обязательно протестируйте все автоматизированные закулисные вещи, а также вещи пользовательского интерфейса.

3 голосов
/ 11 марта 2009

Решение "site-id" - это то, что сделано.

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

Также обратите внимание, что - в качестве оптимизации - вам может не потребоваться добавлять столбец siteId в КАЖДУЮ таблицу.

Иногда у вас есть отношения "содержит". Это FK master-detail, часто определяемый каскадным удалением, так что детали не могут существовать без родителя. В этом случае детям не нужен siteId, потому что они не существуют независимо.

1 голос
/ 11 марта 2009

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

Предполагая, что вы рассмотрели это и посчитали это "достаточно безопасным". Вам может потребоваться / вы хотите создать VIEWS или навязать какой-либо другой контроль доступа, чтобы клиенты не могли видеть данные друг друга.

IIRC, продукт под названием «Надежный Oracle», имел возможность разделять данные на основе такого ключа (примерно во время выхода Oracle 7 или 8). Идея заключалась в том, что к любому данному запросу автоматически добавляется «и sourceKey = @userSecurityKey» (или некоторые другие). Эта функция может быть включена в более поздние версии популярного коммерческого продукта.

1 голос
/ 11 марта 2009

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

0 голосов
/ 11 марта 2009

Чтобы расширить ответ Грегори, вы также можете создать родительский ssis, который вызывает пакет, выполняющий фактическое перемещение внутри контейнера цикла foreach.

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

Ваша таблица может содержать список всех ваших клиентских баз данных и иметь флаг, чтобы пометить, когда вы будете готовы их переместить. Таким образом, вы не сидите без дела, запуская пакет ssis в 32,767 базах данных. Я подсел на цикл foreach в ssis.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...