Из какого крупнейшего XML-файла SSIS может извлекать данные?

Question

У нас есть архитектура, в которой мы используем SSIS для извлечения данных из пакетных файлов XML в промежуточную базу данных для проверки перед их экспортом в производство.

Мы в некоторой степени контролируем формат XML, и меня попросили определить, какое максимальное количество записей должен содержать пакетный файл XML. На основе схемы XML и некоторых примеров данных я могу оценить средний размер записи и сделать некоторые прогнозы.

Однако, подойдя к этому с другой стороны, я хотел бы получить представление о технических ограничениях SSIS при работе с большими файлами XML.

Мне известно, что SSIS сгладит и преобразует документ XML в свое собственное табличное представление в памяти, поэтому ОЗУ становится очевидным ограничивающим фактором, но в какой пропорции?

Можете ли вы сказать что-то вроде: SSIS требует примерно в 2,5 раза больше размера файла, который вы пытаетесь загрузить, в доступной памяти? Предполагая, что у меня есть блок 32 ГБ, выделенный для этой функции загрузки данных, насколько большими могут быть мои файлы XML?

Я знаю, что могут быть и другие факторы, такие как сложность схемы, количество вложенных элементов и т. Д., Но было бы неплохо иметь отправную точку.

Answer 1

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

например. Этот парень экспортировал весь контент Википедии (20Гб XML-файл): http://www.ideaexcursion.com/2009/01/26/import-wikipedia-articles-into-sql-server-with-ssis/

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

Answer 2

Это не так просто.

Прежде всего, имейте в виду, что SSIS «выравнивает» XML так, что для каждого пути через XML существует один выход из источника XML. Тривиальным примером является то, что

<Parent><Child><Grandchild/></Child></Parent>

выдаст три выхода и три выхода с ошибкой. Становится хуже:

<Parent><Child><Grandchild><Notes/></Grandchild><Notes/></Child><Notes/></Parent>

Это приведет к выводам Parent, Child, Grandchild, Parent-Child-Grandchild-Notes, Parent-Child-Notes и Parent-Notes, как нормальным, так и ошибочным.

Проект, над которым я работал, начинал с 203 результатов. Я был в состоянии сгладить схему XML и произвести только 19 или около того. Это все еще много, учитывая, что каждый вывод должен иметь свою собственную обработку.

Кроме того, задача XML не может обрабатывать 1 ГБ или более XML. Он действительно загружает весь документ в память. Попробуйте создать XmlDocument.Load для такого файла и посмотрите, что происходит - вот что происходит с SSIS.

Мне пришлось создать собственный «Источник элементов XML», который обрабатывал дочерние элементы корневого элемента по одному. Это позволило мне сгладить XML, а также обрабатывать большие документы (сработал тестовый документ объемом 10 ГБ).

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

Вместо этого SSIS добавляет суррогатный ключ (я думаю, именно так он и называется) к каждому дочернему элементу. Будет добавлен ParentID к родителю, ChildID к ребенку и ChildParentID также добавлен к ребенку, чтобы ссылаться на родителя ребенка. Их можно использовать, чтобы «снова собрать элемент вместе», но только после того, как все данные закончат запись в промежуточные таблицы. Это единственный раз, когда вы можете быть уверены, что любой данный элемент был обработан полностью - когда они все имеют!