Господа,

Вопрос на фантазию:

Стоит задача максимально быстро затянуть в базу сиквела полную базу фиас по домам. В этом плане кто как бы выстроил процесс?

Поясню в чем интерес и что следует учесть: база данных домов представленна кучей файлов .dbf вида :HOUSE01.dbf, HOUSE02.dbf, HOUSENN.dbf

Сейчас NN ограниченна размером в 99, но будем учитывать что в итоге порог файлов может перешагнуть эту отметку и потенциально файлов будет больше 100.

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

есть несколько идей как грузить:
как мне видится максимально быстро было бы загрузить каждую dbf в отдельную таблицу в параллельных потоках по типу:
нарисовать глобальный скоуп задач DF покрывающий каждый потенциальный файл
после этого сделать merge всего этого добра в единую таблицу. но этот подход не попадает в рамки условия что в будующей добавятся новые файлы, нужно будет добавлять дополнительные задачи data flow для новых файлов.
но тут есть потенциальный минус: в одной DF указывать кучу избыточных источников к примеру перечислить 100 источников каждый на свою dbf, то при запуске когда пакет попытается обратиться к источнику данных и не найдет его, он остановит весь шаг dataflow, а загрузки желательно должны быть не зависимы друг от друга: то есть если к примеру HOUSE05.dbf не положили - ничего страшного загрузится все без нее.
(и кстати у меня пакет при использовании овер 70 источников данных валится с ошибкой доступа oledb, не стал разбираться с чем это связанно)

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

можно конечно выстроить модель: foreach var_dbf in catalog { run dataflow => oledb.AccessMode = Openrowset from variable, oledb.OpenrowsetVariable = var_dbf }
но такой подход будет файлы грузить последовательно а не параллельно.


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

кстати еще пришла мысль в голову что динамически можно выстроить в таком ключе:

в одном пакете собрать список файлов в папке и в for each цикле по данному списку запускать параметризированный пакет вида

псевдокод


где var_sourcefile = будет первым параметром пакета
var_destination_table = вторым параметром пакета


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

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

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

и пока копался как раз наткнулся на некоторые костыли в плане возможных извращений как раз источников данных по провайдеру jet.oledb - они нормально не параметризируются из-за этого сделать более менее адаптивный пакет к динамическому содержимому -приходится придумывать какие то мудреные схемы.

crutchmaster,




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

во вторых это спортивный интерес.

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

Этим же разработчик управляет. Хочет, останавливает пакет при ошибке, хочет, не останавливает.

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

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