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

Question

У нас есть база данных с ~ 100K бизнес-объектами. Каждый объект имеет около 40 свойств, которые хранятся среди 15 таблиц. Я должен получить эти объекты, выполнить некоторые преобразования на них и затем записать их в другую базу данных (с той же схемой.) Это ADO.Net 3.5, SQL Server 2005.

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

Моим первым проходом в программе было чтение объекта из исходной БД, выполнение преобразования и вызов подпрограммы библиотеки для каждого из ее 40 свойств для записи объекта в целевую БД. Повторите 100 000 раз. Очевидно, что это крайне неэффективно.

Какие есть хорошие решения для решения этого типа проблемы?

Спасибо

Answer 1

Это как раз то, для чего хороши службы интеграции SQL Server (SSIS). Это документировано в Books Online, так же как и SQL Server.

Answer 2

Я с Джоном, SSIS - это путь для любого повторяющегося процесса импорта больших объемов данных. Это должно быть намного быстрее, чем те 30 часов, которые вы сейчас получаете. Вы также можете написать чистый код t-sql, чтобы сделать это, если две базы данных находятся на одном сервере или связаны между собой. Если вы идете по маршруту t-sql, вам может потребоваться создать гибрид кодов на основе множеств и циклического кода для запуска в пакетах (скажем, 2000 записей за раз), а не блокировать таблицу на все время, когда большая вставка будет брать.

Answer 3

Плохие новости: у вас есть много вариантов

использовать преобразования плоских файлов: извлекать все данные в плоские файлы, манипулировать ими с помощью grep, awk, sed, c, perl в требуемые операторы вставки / обновления и выполнять их для целевой базы данных

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

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

PRO: быстро, только одна технология; CON: Требуется прямое соединение между базами данных. Вы можете достичь предела SQL или доступных знаний SQL довольно быстро, в зависимости от типа преобразования.

используйте t-sql или любой другой итеративный язык, который предоставляет база данных, все остальное похоже на чистый SQL-подход.

PRO: довольно быстро, так как вы не покидаете базу данных. CON: я не знаю t-sql, но если это что-то вроде PL / SQL, это не самый хороший язык для сложных преобразований.

используйте язык высокого уровня (Java, C #, VB ...): вы бы загружали свои данные в соответствующие бизнес-объекты, манипулировали ими и сохраняли их в базе данных. В значительной степени то, что вы, кажется, делаете прямо сейчас, хотя кажется, что есть лучшие ORM, например, NHibernate

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

PRO: Извините, вам придется попросить кого-то об этом, у меня пока нет ничего, кроме плохого опыта с этими инструментами.

CON: узкоспециализированный инструмент, который вам необходимо освоить. Мой личный опыт: медленнее в реализации и выполнении преобразования, чем рукописный SQL. Кошмар для удобства обслуживания, так как все скрыто в проприетарных репозиториях, поэтому для IDE, контроля версий, CI, тестирования вы застряли с тем, что дает вам инструмент, если таковой имеется.

PRO: Даже сложные манипуляции могут быть реализованы простым и понятным способом, вы можете использовать все модные инструменты, такие как хорошие IDE, Testing Frameworks, CI Systems, чтобы поддержать вас при разработке преобразования.

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

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

Answer 4

Сколько раз вам нужно это сделать? Если только один раз, и он может работать без присмотра, я не вижу причин, по которым вам не следует повторно использовать существующий клиентский код. Автоматизация работы людей - вот для чего нужны компьютеры. Если это неэффективно, я знаю, что это отстой, но если вы собираетесь потратить неделю на настройку пакета служб SSIS, это тоже неэффективно. Кроме того, ваше клиентское решение может содержать бизнес-логику или проверочный код, который вам нужно запомнить для переноса в SQL.

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

Answer 5

К сожалению, я бы сказал, что вам нужно забыть свою клиентскую библиотеку и сделать все это в SQL.