2009-11-06 2 views
2

Мы используем XSLT для генерации отчетов наших данных. Данные в настоящее время хранятся в Oracle как XML-документы (не используя XMLTYPE, а обычный CLOB). Мы выбираем правильные XML-документы и создать единый документ:Преобразования XSLT на очень большие файлы

<DATABASE> 
    <XMLDOCUMENT> ... </XMLDOCUMENT> 
    <XMLDOCUMENT> ... </XMLDOCUMENT> 
    ... 
</DATABASE> 

В некоторых случаях полный документ XML содержит +100000 документы. Это означает, что сначала загружается огромный XML-документ в память, что вызывает все проблемы памяти.

Как мы можем предотвратить это? Мы используем класс XslCompiledTransform в .NET 2.0.

Я знаю, что существует 2 формы анализа XML-документов: DOM и SAX. Но, как я понимаю, SAX-путь невозможен в сочетании с XSLT. Метод разбора DOM заставляет нас загружать всю вещь в память.

Каковы наши варианты? Помогает ли он сначала записать полный документ на диск? Означает ли Oracle лучшую работу над большими преобразованиями XSLT?

+2

Насколько сложным является содержание XMLDOCUMENT? И насколько сложна трансформация XSLT? Может быть, стоит изменить XSLT на что-то более легкое? –

+0

Проблема в том, что мы намерены использовать это как механизм общего отчета. Нельзя сказать, насколько сложным будет XSLT. Это может быть простой экспорт CSV или вычисление со средними значениями и т. Д. –

+1

SAX может использоваться как вход с некоторыми XSLT-процессорами, например. Саксон [http://saxon.sourceforge.net/]. Однако в общем случае процессор XSLT построит внутреннее представление целого числа данных, которое будет линейно расти в памяти с размером входных данных. Может быть возможно использовать оптимизацию, специфичную для данного процессора, для запуска преобразования в потоковом режиме. Другим решением может быть ограничение количества выбранных элементов и обработка данных в несколько раз.Возможно, вам придется сократить преобразование в несколько этапов. –

ответ

0

CLOB можно передавать, насколько я знаю. Конечно, потоковая передача в локальную файловую систему является одним из вариантов. Но тогда вы столкнетесь с той же проблемой, что и большинство двигателей XSLT выполняют свою работу на DOM. Я бы предложил разделить файл на более мелкие куски (XMLDCOUMENT в вашем случае). Это можно сделать без XSLT, но просто с помощью простого простого выражения. Затем запустите преобразование XSLT для каждого отдельного фрагмента. Это, конечно, будет медленнее, чем все это в памяти, но избавит вас от проблем с памятью, если документ слишком велик.

1

Существует третья модель обработки XML называется VTD-XML, который преодолевает большинство выпуска памяти DOM, и имеет встроенную поддержку XPath, что вы должны смотреть ... XSLT поддержка его на пути ...

4

В зависимости на какие виды преобразований, которые вы хотите сделать, STX может быть альтернативой XSLT:

Streaming преобразования для XML (STX) представляет собой один проход преобразования язык XML документов. STX - , предназначенный для использования в качестве высокоскоростной низкоуровневой памяти, альтернативной XSLT, с использованием W3C XQuery 1.0 и XPath 2.0. Данные Модель. Так как STX не требует построения дерева в памяти, то подходит для использования в сценариях с ограниченными ресурсами .

1

это может помочь. Редактор XMLMax xml может применять таблицу стилей xsl для каждого фрагмента, соответствующего выражению xpath, и записывать все соответствующие выходы в один файл, инкапсулированный в пользовательский root. Он не имеет ограничений размера файла. редактор google xmlmax.

Смежные вопросы