# java + xpath -> performanceproblem



## kermitblue (26. Sep 2006)

hallo.

ich muss ein-paar sehr grosse xml files (>4GB) in eine mysql datenbank schmeissen, soweit so gut. habe das ganze mit java, xpath und dom (verwende immer nur kleine haeppchen der grossen files) geloest und es funktioniert, mal abgesehen von der im betreff erwaehnt performance, wunderbar. aber aufgrund der komplexitaet eines einzelnen kind-vom-root knoten (hat zwischen 10.000 und 40.000 zeilen) braucht mein programm zwischen 1 und 1 1/2 stunden fuer ein 10mb haeppchen und das obwohl wir eine ziemlich wuchtige sun dahinter stehen haben. von der auslastung her brauchen wir nur ca zwischen 25 und 50 % des zugesichterten rams (ingesamt 5GB), die prozessorleistung laeuft aber staendig auf 100%. die inserts bzw die datenbank sind nicht das problem - ohne sie (nur mit stout) braucht das proggi genausolang.

ich verwende keinerlei xpath ausdruecke der art "//knoten/kindknoten" sondern immer nur direkt "kindknoten"um von einem eltern knoten auf einen (oder die) kindknoten zuzugreifen.

meine frage nun an alle java, xml (xpath) experten: welche moeglichkeiten der optimierung habe ich? ich verwende zur zeit das standard xpath paket von sun, kennt jemand kommerzielle (oder gratis, noch besser) , die vielleicht performanter sind? oder kann ich den code mit ein paar schaltern oder einen anderen compiler auf speed optimieren (so wie in c) - hab hier noch keine erfahrung. parallelisieren hat ja auch nicht viel sinn, nehm ich an, wenn die prozessoren sowieso auf 100 % laufen? sax ist keine opition, dafuer ist das modell zu komplex... 

hat jemand vorschlaege?

danke
kermitblue


----------



## huckfinn (26. Sep 2006)

Hi,

Mußt du was transformieren oder nur den Baum effizient im einem RDBMS ablegen? 
Brauchst du so etwas wie einen XML Schredder? 

Bis denne Huck


----------



## huckfinn (26. Sep 2006)

Hi noch ne Frage, 

Was mußt du mit denPfadausdrücken adressieren?
Ich ..äh wir haben nämlich einen XML-Schredder mit Pfadstatistik 
geschrieben der das gesamte Dokument in einen RDBMS
speichert und dann Elter-Kind-Knoten Beziehungen wie
bei XPath im Baum rekursiv durchlaufen kann aber mit SQL!
Wir brauchen das für die Zerlegung von sog. Findbuchdateien, 
die sind zwar nicht so stattlich haben aber auch so an die 200MB
..siehe auch
unimatrix.uni-greifswald.de

Bis denne Huck


----------



## kermitblue (27. Sep 2006)

hi!

eigentlich adressieren wir wirklich nur knoten und darin enthaltene textnodes bzw attribute und transformationen gibts auch keine. euer xml shredder hoert sich da ziemlich gut an. verwendet ihr sax zum durchparsen oder habt ihr euch selber was gebastelt?

lg kermitblue


----------



## huckfinn (27. Sep 2006)

Hi,

Zum scannen der XML Datei nehmen wir SAX bauen einen Namespace, Elemente und Attribut Lookup Tree auf (Treemap)  damit können wir 
eine Speicherung mit Referenzindizes realisieren das spart Speicher, schafft Performanz und ist RDBMS konform. Mit diesen Speicherstrukturen kann man dann eine Pfad-, Attribut- und Elementstatistik erstellen, das ist die eigentliche Aufgabe. Wir wollen aber dann auch bei Bedarf schnell und ohne das Dokument von vorne parsen zu müssen, wieder auf Teilgraphen bzw. Pfade zugreifen um dort Informationen rauszuziehen (Textretrival). Das machen wir dann mit SQL. Zur Erklärung,  wir haben das Problem, daß die Findbücher zwar in XML kodiert sind und auch eine klare hierarchische Struktur haben, aber die Inhaltselemente zu 80%  in einem "Talking Context" also gemischt mit Text wie in HTML vorliegen. Bei 164 XML-Elementen bzw Attributen ist das 'ne ganz schön unübersichtliche Sache und wird auch auf Grund der meschlichen Kreativität so vollzogen.  Letztendlich geht es um eine Form von syntaktischen Informationretrival zu realisieren, um die Informationen für das  Open Archive Protokoll for Metadata Harvesting  aufbereiten zu können. Dafür müssen klar definierte von den Maschinen lesbaer Hierarchien existieren (Strukturretrival) in denen die Informationen in allgemeinbeschreibenden Metainformationen des Dublin Core vorliegen (Informationretrival).

Was willst du den mit einem Schredder machen?

Bis denne Alex


----------



## kermitblue (27. Sep 2006)

wir müssen einfach nur die gegebenen xml files in eine datenbank werfen -> wichtig hierbei ist eben die performance... unsere aktuelle loesung ist viel zu langsam  du weisst nicht zufaellig ob es hier open-source loesungen gibt? ist ja wirklich (mal abgesehen von der performance) eine einfache sache... wie lang habt ihr fuer die implementation gebraucht und wie komplex ist die struktur?


----------



## huckfinn (27. Sep 2006)

Hi,

Also wir schreiben unter GPL/MPL ist ja 'n DFG Projekt. Wir können also Codeschnipsletten tauschen wenn ihr auch unter GPL oder OpenSource arbeitet. Die Implementierung hat an die 2 Monate gedauert allerdings ist das das Problem nicht so einfach wie bei euch. Außerdem brauchen wir zwei Leseszyklen zum Abgleich der vorhandenen Element-/ Attributlisten mit den den hinzukommenden. Wir haben mal 'ne kleine Statistik gemacht um zu sehen ob's für uns reicht !KEIN PROFILING! Um die Verbunddatenbank des   ARIADNE-Servers mit (596 GB mit 6120 000 Elementen) einzulesen und sie auch wieder zu reprduzieren (XML rein SQL aufbauen und alles wieder rauschreiben) brauchen wir ca. 17h ohne das System  (AMD 2GHz Takt /1 GB RAM / PostgresSQL 8) an die Wand zu fahren.  Das enspricht einer grob geschätzten Schreibeschwindigkeit von 510 Elementen (DB2XML) pro Sekunde und einer Lesegeschwindikeit von 480 Elementen pro Sekunde. Das ist etwa 1/3 MB pro Sekunde.  
Tja die Tools sind im OpenSource Bereich offensichtlich rar gesät und werden auch mit den Evaluierungsvarianten der großen SQL Datenbanken nicht ausgeliefert. Ich habe im Mai in einem Linuxforum auch ein POST  Vielleich ist es erst mal ein guter Anfang wenn du die theoretische Geschwindigkeit einer SAX Implemntierung für dein Problem ermittelst. Ich kann dir ja das Progrämmchen mit dem wir gestartet sind schicken. Allerdings brauch ich 'ne Maill, das gehört glaube ich nicht in dieses Forum. 

Bis denne Huck


----------



## kermitblue (27. Sep 2006)

die geschwindigkeit is schon enorm  (wir sind schneckig dagegen unterwegs obwohl wir eine 4 prozessor maschine mit 6GB ram haben... aber das ist dom...). wir bauen das teil fuer ein österreichisches forschungsinstitut - ob die das dann unter die GPL stellen wollen weiss ich leider nicht... fallst du mir trotzdem (kleinste) codeschnippsel aus den anfängen des projektes schicken koenntest wäre ich dir sehr dankbar, falls es nicht geht, verstehe ich das natürlich...  meine email adresse wäre gerpreis@hotmail.com

danke, 
liebe grüsse


----------



## huckfinn (27. Sep 2006)

Hi 

Ich schicke dir 'ne vollständige Variante als Netbeansprojekt zu ..muß aber sie aber noch schick machen .. irgend ein omimöses namespacehandling hat mein co da reingepinselt undüberall das Copyleft reinschreiben OK!

Bis denne huck


----------



## kermitblue (27. Sep 2006)

super danke!!


----------

