28

別の XML ファイルに変換する必要がある非常に大きな XML ファイルがあり、XSLT を使用してこれを行いたいと考えています。私は、速度の最適化よりもメモリの最適化に関心があります (ただし、速度も良いでしょう!)。

このタスクに推奨する Java ベースの XSLT プロセッサはどれですか?

他の方法 (XSLT 以外、Java 以外) をお勧めしますか? もしそうなら、その理由は?

問題の XML ファイルは非常に大きいですが、それほど深くはありません。数百万の行 (要素) がありますが、深さは約 3 レベルしかありません。

4

3 に答える 3

34

現在、 XSLT 2.0プロセッサは 3 つしか知られていませんが、そのうちの 1 つであるSaxon 9.xは、(少なくとも私の経験によれば) 速度とメモリ使用率の両方でおそらく最も効率的です。Saxon-SA (Saxon のスキーマ認識バージョンであり、B (基本) バージョンのように無料ではありません) には、ストリーミング処理用の特別な拡張機能があります。

さまざまな既存の XSLT 1.0プロセッサから、.NET XslCompiledTransform (Java ではなく C# ベース!) がチャンピオンのようです。

XSLT 1.0 プロセッサの Java ベースの世界では、 Saxon 6.xが再びかなり優れています。

更新：

現在、この質問が最初に回答された日から 3 年以上が経過しましたが、前述の XSLT プロセッサ間の効率の違いが変化したという証拠はありません。

ストリーミングに関しては：

  1. 「数百万のノード」を持つ XML ドキュメントは、ストリーミングがなくても十分に処理できます。私は、Saxom 9.1.07 が整数値を持つ第 3 レベルの要素を約 100 万個含む XML ドキュメントを処理する実験を行いました。変換は単純にそれらの合計を計算します。私のコンピューターでの変換の合計時間は 1.5 秒未満です。使用メモリは 500MB で、10 年前の PC でも可能だった量です。

以下は、変換に関する詳細を示す Saxon の情報メッセージです。

Saxon 9.1.0.7J from Saxonica
Java version 1.6.0_17
Stylesheet compilation time: 190 milliseconds
Processing file:/C:\temp\delete\MRowst.xml
Building tree for file:/C:\temp\delete\MRowst.xml using class net.sf.saxon.tinytree.TinyBuilder
Tree built in 1053 milliseconds
Tree size: 3075004 nodes, 1800000 characters, 0 attributes
Loading net.sf.saxon.event.MessageEmitter
Execution time: 1448 milliseconds
Memory used: 506661648
NamePool contents: 14 entries in 14 chains. 6 prefixes, 6 URIs
  1. Saxon 9.4 には、巨大な XML ドキュメントの処理に使用できるsaxon:stream() 拡張関数があります。

ドキュメントからの抜粋は次のとおりです。

基本的に、Saxon でストリーミングを行う方法は 2 つあります。

バースト モード ストリーミング: このアプローチでは、大きなファイルの変換が、ファイルの小さな断片の一連の変換に分割されます。各ピースは順番に入力から読み取られ、メモリ内の小さなツリーに変換され、変換され、出力ファイルに書き込まれます。

このアプローチは、構造がかなりフラットなファイルに適しています。たとえば、数百万のログ レコードを保持するログ ファイルで、各ログ レコードの処理が以前のログ レコードから独立している場合です。

この手法の変形では、xsl:for-each の代わりに、新しい XSLT 3.0 xsl:iterate 命令を使用してレコードを反復処理します。これにより、レコードが処理されるときに作業データを維持できます。これにより、たとえば、実行の最後に合計または平均を出力したり、1 つのレコードの処理をファイル内の前にあるものに依存させることができます。 . xsl:iterate 命令を使用すると、ループを早期に終了することもできます。これにより、実際にファイル全体を読み取らずに、大きなファイルの先頭からデータを処理する変換が可能になります。

バースト モード ストリーミングは XSLT と XQuery の両方で使用できますが、XQuery には xsl:iterate 構造に相当するものはありません。

ストリーミング テンプレート: このアプローチは、テンプレート ルールを各レベルのノードに一致させることによって、入力 XML 階層の再帰的な下降を実行する従来の XSLT 処理パターンに従いますが、メモリ内にツリーを構築することなく、一度に 1 つの要素を実行します。

すべてのテンプレートはモード (おそらくデフォルトの名前のないモード) に属し、ストリーミングは新しい xsl:mode 宣言を使用して指定できるモードのプロパティです。モードがストリーミング可能であると宣言されている場合、そのモード内のすべてのテンプレート ルールは、ストリーミング可能な処理のルールに従う必要があります。

ストリーミング処理で許可されるルールは非常に複雑ですが、重要な原則は、特定のノードのテンプレート ルールは、そのノードの子孫を 1 回しか順番に読み取ることができないということです。現在の Saxon 実装の制限により、さらにルールが課せられます。たとえば、グループ化を使用することは理論的にはストリーミング実装と一致しますが、Saxon では現在実装されていません。

  1. XSLT 3.0には標準のストリーミング機能があります。ただし、W3C ドキュメントはまだ「ワーキング ドラフト」の状態であり、ストリーミング仕様は後続のドラフト バージョンで変更される可能性があります。このため、現在のドラフト (ストリーミング) 仕様の実装は存在しません。

  2. 警告: XSLT プロセッサに関係なく、すべての変換をストリーミング モードで実行できるわけではありません。巨大なドキュメントのストリーミング モード (限られた量の RAM を使用) で実行できない変換の 1 つの例は、それらの要素の並べ替えです (たとえば、共通の属性による)。

于 2009-01-20T15:03:46.563 に答える
9

Java 実装がJoostであるSTXを考慮することができます。XSLT に似ていますが、ストリーム プロセッサであるため、非常に少ない RAM を使用して膨大なファイルを処理できます。

Joost は、標準の javax.xml.transform.TransformerFactory として使用できます。

于 2009-01-20T11:32:31.077 に答える
4

ストリーミング モードの Saxon サポートを参照してください。http://www.saxonica.com/html/documentation/sourcedocs/streaming/

このストリーミング モードが適していない場合は、メモリ使用量が少なくなるように最適化された、Saxon のタイニー ツリー モードを試すことができます。（とにかくデフォルトです）

于 2009-01-20T11:30:23.330 に答える