Das Lesen von Großen XML-Datei mit StAX und XPath

Wenn die Leistung ist ein wichtiger Faktor, und/oder das Dokument groß ist (beides scheint hier der Fall sein), ist der Unterschied zwischen Ereignis-parser (wie SAX oder StAX) und die native Java XPath-Implementierung ist, dass letztere baut eine W3C-DOM-Dokument vor der Auswertung des XPath-Ausdrucks. [Es ist interessant zu beachten Sie, dass alle Java Document Object Model Implementierungen wie der DOM oder Axiom verwenden einen Ereignis-Prozessor (wie SAX oder StAX) zu bauen, die in-memory-Repräsentation, also, wenn Sie jemals nur mit dem event-Prozessor-Sie sparen Speicher und die Zeit, die es braucht, um zu bauen einen DOM.]

Als ich erwähnte, die XPath-Implementierung im JDK arbeitet auf eine W3C-DOM-Dokument. Sie können dies in den Java-JDK-source-code-Umsetzung durch die Betrachtung com.sun.org.apache.xpath.internal.jaxp.XPathImpl, in denen vor der evaluate () - Methode aufgerufen wird, wird der parser muss zuerst analysieren Sie die Quelle:

  Document document = getParser().parse( source );

Nachdem diese Ihre 10 GB XML wird dargestellt im Speicher (plus was auch immer overhead) — wahrscheinlich nicht das, was Sie wollen. Während möchten Sie vielleicht einen eher "generischen" Lösung, die sowohl Ihrem Beispiel XPath-und XML-markup-scheint relativ einfach, so scheint es nicht zu sein eine wirklich starke Begründung für ein XPath (außer vielleicht Programmierung Eleganz). Das gleiche gilt auch für die XProc Vorschlag: diese würden auch eine DOM. Wenn Sie wirklich brauchen, eine DOM-Sie könnte verwenden Axiom eher als das W3C-DOM. Axiom hat eine viel freundlichere API und baut den DOM über StAX, so es ist schnell, und Jaxen verwendet für seine XPath-Implementierung. Jaxen erfordert einige Art von DOM (W3C-DOM, DOM4J oder JDOM). Dies gilt von allen XPath-Implementationen, also, wenn Sie nicht wirklich brauchen, XPath kleben mit nur die Ereignisse parser empfohlen werden würde.

SAX ist der alte streaming-API mit StAX neuere, und viel schneller. Entweder über das native JDK StAX-Implementierung (javax.xml.stream) oder die Woodstox StAX-Implementierung (das ist deutlich schneller, nach meiner Erfahrung), würde ich empfehlen, eine XML-ereignisfilter, dass die ersten Spiele auf element-Typ-Namen (zum erfassen von <txn> Elemente). Dies erzeugt kleine Ausbrüche von Veranstaltungen (element, Attribut, text), die überprüft werden können, für die entsprechenden Benutzer Werte. Auf eine gute Partie, Sie können entweder ziehen Sie die notwendigen Informationen über die Veranstaltungen oder pipe der bounded events zu bauen ein mini-DOM aus, wenn Sie Sie gefunden, das Ergebnis war einfacher zu navigieren. Aber es klingt wie das wäre des guten zuviel, wenn das markup ist einfach.

Wäre dies wahrscheinlich die einfachste, Schnellste Ansatz und vermeiden Sie die Speicher-overhead der Aufbau eines DOM. Wenn Sie übergeben werden die Namen der Elemente und attribute für den filter (also, dass Sie Ihre matching-Algorithmus ist konfigurierbar) könnte man es relativ generisch.

Ist es definitiv ein Fall für XProc mit einem streaming und Parallelverarbeitung Umsetzung wie QuiXProc (http://code.google.com/p/quixproc)

In dieser situation, verwenden Sie

  <p:for-each>
    <p:iteration-source select="//transactions/txn"/>
    <!-- you processing on a small file -->
  </p:for-each>

Können Sie auch wrapp jeder der resultierenden transformation mit einer einzigen Zeile von XProc

  <p:wrap-sequence wrapper="transactions"/>

Hoffe, das hilft

Streaming-Transformationen für XML (STX) könnte das sein, was Sie brauchen.