PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Daten aus großer XML-Datei extrahieren


rotalever
2009-06-25, 14:18:55
Ich habe hier mit XML-Dateien von 20-30GB zu tun. Da möchte ich möglichst schnell Daten raus extrahieren. Der Aufbau ist z.B. so:

<A>
<B>...</B>
<C>
<D>...</D>
<E>Test 1</E>
</C>
<F>
...
</F>
</A>
<A>
<B>...</B>
<C>
<D>...</D>
<E>Test 2</E>
</C>
<F>
...
</F>
</A>
usw. usw.


Ich möchte aus jedem "A-Element" den Datensatz mit dem Namen A->C->E extrahieren und zum Beispiel in einer Textdatei speichern, wobei in jeder Zeile ein Datensatz stehen soll. Gibt es dafür irgendwelche fertigen und schnellen Tools? Da die Dateien so groß sind, dauert es mit einer Script-Sprache dann doch recht lange...

edit:
Also am Ende würde ich gerne so eine Datei haben:

Test 1
Test 2
...

universaL
2009-06-25, 14:58:02
mit einem parser der nicht die ganze datei aufeinmal einliest (java - sax parser zum bleistift) söllte das ganze recht fix gehen.

alternativ ein kleiner, selbstgeschriebener parser der zeilenweise arbeitet, mit ein paar regulären ausdrücken dürfte auch recht fix sein. :)

The_Invisible
2009-06-25, 15:35:36
jop, wenn der knoten einen eindeutigen namen hat kann man zeilenweise durchgehen und die daten sehr einfach rausfischen. damit hat man dann gerade mal den speicherverbrauch einer zeile.

mfg

Monger
2009-06-25, 15:50:44
Eigentlich sollte es in fast allen Programmiersprachen auch eine Variante des XML Streams geben. Damit kann man dann zumindest den Hauptspeicherverbrauch gering halten.

Aber 20GB sind halt 20GB. Selbst mit dem schnellsten Parser kann das immer noch nicht schneller gehen als es die Festplatte her gibt.

Wenn es darum geht, einzelne Werte innerhalb dieser Datei zu suchen und zu manipulieren, stellt sich sowieso die Frage ob XML da überhaupt die richtige Wahl gewesen ist. Das schreit eigentlich nach einer richtigen Datenbank, aber nuja...

Gast
2009-06-25, 15:53:09
der schnellste weg wäre, sofern das xml format / die db das unterstützt, die xml datei in eine datenbank zu importieren und als textdatei wieder zu exportieren. ist aber nicht immer möglich.

rotalever
2009-06-25, 15:56:28
alternativ ein kleiner, selbstgeschriebener parser der zeilenweise arbeitet, mit ein paar regulären ausdrücken dürfte auch recht fix sein. :)
Ja das hab ich jetzt gemacht. Mit einer Script-sprache. Schafft so 6MB/s
Eigentlich sollte es in fast allen Programmiersprachen auch eine Variante des XML Streams geben. Damit kann man dann zumindest den Hauptspeicherverbrauch gering halten.
Ja das hatte ich auch schon vorher gemacht, nur war es halt trotzdem irgendwie langsam (so 6 Stunden für die Datei).

Wenn es darum geht, einzelne Werte innerhalb dieser Datei zu suchen und zu manipulieren, stellt sich sowieso die Frage ob XML da überhaupt die richtige Wahl gewesen ist. Das schreit eigentlich nach einer richtigen Datenbank, aber nuja...
Nee suchen nicht direkt, ich will da bestimmte Dinge extrahieren aus den Strings und analysieren, dafür wollte ich aber erstmal das XML in einer besser zu verarbeitendes Format überführen..
Dass das nun XML ist liegt übrigens nicht an mir. Ich habe die Datei so wie sie ist erhalten und keine andere Wahl. In der Datei steht ja auch ziemlich viel Zeug drin, das ich gar nicht brauche, deswegen ist sie ja so groß..

rotalever
2009-06-25, 15:57:28
der schnellste weg wäre, sofern das xml format / die db das unterstützt, die xml datei in eine datenbank zu importieren und als textdatei wieder zu exportieren. ist aber nicht immer möglich.
Hat die Datenbank nicht selber noch enormen Verwaltungsoverhead?

Gast
2009-06-25, 16:02:54
außerdem gibts xpath auch noch

Gast
2009-06-25, 16:03:54
und xslt :) so das wars

Gast
2009-06-25, 16:05:23
Hat die Datenbank nicht selber noch enormen Verwaltungsoverhead?
glaube ich hatte da was falsch verstanden ??

Monger
2009-06-25, 16:26:02
Hat die Datenbank nicht selber noch enormen Verwaltungsoverhead?
Kann man so pauschal nicht sagen. Sowas wie SQL Server Compact (der ja für kleinere Datenmengen gedacht ist) hat auch keinen nennenswerten Overhead, und bei größeren Daten (und 20GB finde ich persönlich schon recht mächtig) juckt der Overhead auch nicht mehr.

rotalever
2009-06-25, 17:12:35
Naja, wie gesagt habe ich es jetzt einfach wie beschrieben gemacht und nach 50 Minuten sind die knapp 2Mio. Datensätze nun extrahiert.

Jetzt fängt die eigentliche Arbeit an...
Danke für die guten Tipps.

Berni
2009-06-25, 23:47:36
Auch wenns schon erledigt ist:
StAX ist auch eine sehr gute Alternative (in Java): Performancemäßig praktisch gleich mit SAX (je nach Anwendungsszenario etwas schneller oder langsamer), dafür aber einfacher zu Programmieren.

Gast
2009-06-26, 10:12:08
Hat die Datenbank nicht selber noch enormen Verwaltungsoverhead?

Ein richtiges DBMS kann da nur deutlich schneller sein als selbstgefrickelte Abfragen, erst recht bei 20GB. Gute DBMS erlauben auch nicht nur XML Spalten, sondern können XML auch indexieren.

rotalever
2009-06-26, 13:09:12
Ein richtiges DBMS kann da nur deutlich schneller sein als selbstgefrickelte Abfragen, erst recht bei 20GB. Gute DBMS erlauben auch nicht nur XML Spalten, sondern können XML auch indexieren.
Ja, nur das ich das ja nie machen wollte. Ich wollte einfach alles extrahieren, also einmal sequentiell durchgehen durch die Datei.