Schnelle XML Lib für große Dateien gesucht

[Mithrandir]

Hi,

Ich bin im Zuge meines Routenplaners jetzt am Überlegen, ob es nicht sinnvoller wäre, das Rendern der Karte lokal im Programm zu machen, um mehr Kontrolle über die Darstellung zu bekommen.

Die Rohdaten sind in einem XML-ähnlichen Format gespeichert. Der Download für Deutschland fasst "niedliche" 400 MB und ist entpackt gute 4 GB groß.

Aber auch wenn ich nicht selbst das Rendern übernehme, muss ich zum Aufbau einer Web-API für das Programm eine DB mit allen Straßen und Orten Deutschlands und den dazugehörigen Geokoordinaten aufbauen. Testweise habe ich mir die OSM-Datei für Schleswig-Holstein genommen, die entpackt "nur" 128 MB groß ist und ca. 2,5 Mio. Zeilen fasst. Muetze1s XMLLib scheitert leider an der Größe, und himiXML is ja noch nicht feddisch.. :stupid:

Gefallen hat mir OmniXML, was auf meinem Core2Duo-Läppi mit 4GB RAM in gefühlten 2 Minuten mit dem Laden fertig war.


Könnt ihr mir noch andere Libs empfehlen, die vielleicht schneller sind?

Gruß,
Daniel

[Muetze1]

Zitat:

Zitat von Daniel G

Muetze1s XMLLib scheitert leider an der Größe, ...

Diese benutzt ein DOM Modell und ist kein SAX Parser. Bei deinen Datengrössen musst du diese nicht im Speicher halten, das ist Unsinn. Schon allein aus der Datengrösse her. Genau für solche Fälle sind SAX Parser da und genau diese solltest du dir anschauen. Es geht hier niemals daram alle Daten im Speicher zu halten.

Überhaupt auf die Idee zu kommen, das so zu versuchen, zeigt auf, dass dir diese beiden gegensätzlichen Interfaces zum XML Zugriff nicht geläufig sind. Ich empfehle dir dringendst dich damit zu beschäftigen und dann deine Auswahl/Entscheidung neu zu treffen/überdenken.

Sorry, aber bei solchen Aussagen könnt ich mich immer wieder aufregen. Das erinnert mich gleich an den blöden Kommentar.[/quote]

Nichts persönliches, aber es wird immer gerne gemeckert (hast du nicht getan) und dann ist man schnell der Unfähige, obwohl diejenigen meistens einfach uninformiert sind. Also bitte nicht auf dich beziehen.

[Mithrandir]

Moin Muetze,

aus deinem leicht gereiztem Kommentar lese ich mal raus, dass ich und der Kollege in deinem Blog nicht die Ersten sind. ;) Das "leider" bezog sich auch eher darauf, dass ich die Lib gerne benutze, da sehr einfach. ;)

Zitat:

Zitat von Muetze1

Überhaupt auf die Idee zu kommen, das so zu versuchen, zeigt auf, dass dir diese beiden gegensätzlichen Interfaces zum XML Zugriff nicht geläufig sind.

Nein, sind sie in der Tat nicht. Wie auch?

Zitat:

Zitat von Muetze1

Ich empfehle dir dringendst dich damit zu beschäftigen und dann deine Auswahl/Entscheidung neu zu treffen/überdenken.

Hast du zufällig n paar Links in deinen Lesezeichen, die mich da informativ weiterbringen, von Wikipedia mal abgesehen? Gerade auch mit Bezug auf Delphi.

Zitat:

Zitat von Muetze1

Also bitte nicht auf dich beziehen.

Ok. ;)


Gruß,
Daniel

Edit: Ich habe eben SAXforPascal entdeckt. Das letzte Downloadpaket ist zwar von 2003, aber ich lasse mich mal überraschen..
Edit2: Nee... Bringt leider nicht das gewünschte Ergebnis, da man soviel anpassen muss. Der Parser bricht bei dem Dokument einfach irgendwann ab... Bin also wieder offen für Vorschläge/andere SAX Implementationen...
Edit3: Soo... Ich habe bei Torry diese Komponente gefunden. Die Webseite gibt es nicht mehr, aber die TALXMLDocument parst die Datei (hat übrigens 14055567 Nodes.. :shock: ) in 28 Sekunden. Das nenne ich mal flott...

[Muetze1]

Hi!

Zitat:

Zitat von Daniel G

aus deinem leicht gereiztem Kommentar lese ich mal raus, dass ich und der Kollege in deinem Blog nicht die Ersten sind. ;)

Ja, leider. Ich habe schon soviele dumme Diskussionen führen müssen über meine Lib, warum die denn so unfähig mal so schnell 2 GB zu verarbeiten oder was man denn so für einen Scheiss verzapft hat - der geht ja gar nicht bei 500 MB XMLs. Und nach tagelangem e-mail Verkehr darf man sich dann anhören, dass die Lib es einfach trotzdem schaffen muss und SAX & DOM irrelevant sind, da ausreden. Von daher bin ich empfindlich an der Stelle...

Aber ich hatte es auch nicht so verstanden, wie geschrieben: nichts persönliches.

Bei einem DOM Parser wird die XML Datei geparst und jeder Knoten wird entsprechend im Speicher dargestellt und ist somit jederzeit sofort verfügbar. Bei einem SAX Parser wird grundsätzlich nichts im Speicher angelegt sondern er hangelt sich durch die Struktur der XML Datei und ruft immer einen entsprechenden Callback auf für den aktuellen Kontext den er gerade parst (Text, Node, Attribute, etc). Der Callback kann von dem Nutzer des Parsers dann genutzt werden um, wenn Struktur, Position und Name stimmen, die entsprechenden Informationen abzulegen. Dafür kann man dem Sax Parser auch mal sagen: überspringe die aktuelle Subknoten und gehe zum nächsten Knoten auf gleicher Ebene, etc. Auch einen Knoten oder zurück oder direkte Addressierung eines Elementes um von da an zu parsen. Dies ist der richtige Weg bei grossen Datenmengen, da du eh nur einen Teild er Daten aus der großen Menge brauchst. Von daher entweder vor dem rendern der Kartendaten vllt. ein paar Details vorher ermitteln oder alles online ermitteln beim malen. Aber ein kleines Vorcache sollte sich da schon anbieten.

Das SAX Prinzip unterscheidet sich aber halt völlig vom DOM Prinzip, muss es aber auch - sonst würden wir immernoch dabei sein und alle Daten in den Speicher laden.

Und nun zu den Links:

1. DOM Modell: http://www.w3.org/DOM/
2. SAX Modell: http://www.saxproject.org/
3. SAX Implementation für Delphi: http://saxforpascal.sourceforge.net/ (Overview, SAX vs DOM)

Das SAX Projekt ist von 2003 und man müsste nach dem Download erstmal die auf der SF.net Seite angegebenen Bugs fixen, aber es ist eine Möglichkeit. Alle anderen Möglichkeiten wären entsprechende ActiveX Objekte wie z.B. MSXML. Dieser kann beides DOM & SAX und wird ja von CodeGear aufbereitet mitgeliefert.

[alzaimar]

Darf ich fragen, wieso man die XML-Daten nicht 'einfach' in ein geeignetes Format übersetzt, z.B. in eine Datenbank? Ich weiss zwar nicht en Detail, wie man auf die Daten zugreifen muss, aber imho sollte eine gut geplante Datenbank den Job doch mit links erledigen, oder nicht?

[Daniel]

Falls Du auf Unicode verzichten kannst, kann ich Dir diese Komponente empfehlen:
http://www.destructor.de/xmlparser/index.htm

Ist ein SAX-Parser und ziemlich flott obendrein.

[Mithrandir]

Hi ihr,

Zitat:

Zitat von Muetze1

Das SAX Projekt ist von 2003 und man müsste nach dem Download erstmal die auf der SF.net Seite angegebenen Bugs fixen, aber es ist eine Möglichkeit.

Argh, auf die Idee, im Bugtracker zu gucken, bin ich gar nicht gekommen... Danke... :wall: Vielleicht wird das dann ja doch noch was mit SAXforPascal und mir.. :stupid:

Zitat:

Zitat von Muetze1

Alle anderen Möglichkeiten wären entsprechende ActiveX Objekte wie z.B. MSXML. Dieser kann beides DOM & SAX und wird ja von CodeGear aufbereitet mitgeliefert.

Zitat:

Zitat von alzaimar

Darf ich fragen, wieso man die XML-Daten nicht 'einfach' in ein geeignetes Format übersetzt, z.B. in eine Datenbank? Ich weiss zwar nicht en Detail, wie man auf die Daten zugreifen muss, aber imho sollte eine gut geplante Datenbank den Job doch mit links erledigen, oder nicht?

Darfst du. ;) Passiert auch, das habe ich im Eingangspost nicht erwähnt: Es geht mir primär eigentlich nur darum, einmal diese Datei zu verarbeiten, um dann die darin enthaltenen Daten in eine Datenbank zu verwursten. Deswegen brauche ich auch nicht zwingend so ein XML-Monster. Aber StrPos fand ich eher unelegant. Vielleicht könnte man mit RegExen arbeiten... :gruebel:

Zitat:

Zitat von Daniel

Falls Du auf Unicode verzichten kannst, kann ich Dir diese Komponente empfehlen:
http://www.destructor.de/xmlparser/index.htm

Ist ein SAX-Parser und ziemlich flott obendrein.

Die Komponente selbst habe ich schon ausprobiert und mir war es irgendwie nicht möglich, eine funktionierende Demo zu erstellen... :gruebel:
Aber da sprichst du einen Punkt an, den ich selbst noch nicht bedacht habe: Unicode-Fähigkeit müsste gegeben sein. Ich geh zwar nicht davon aus, dass jemals ein Asiate das Programm nutzen wird, aber eventuell gibt es ja Leute aus Deutschland, die in Asien eine Rundreise planen (auch wenn ich mich auf die asiatische Karte dafür noch nicht verlassen würde). Da wäre es ungeschickt, wenn man nur Kästchen sehen würde.

[alzaimar]

Falls sicher ist, das sich das XML-Format nicht ändert, könnte ein handgebissener 'Parser' die richtige Lösung sein. Mit einem optimierten PosEx aus dem FastCode-Projekt hüpfe ich in einem Knoten der Form '<Foo Uninteresting stuff Bar="Wupdi"..' sehr schnell von '<Foo' zu 'Bar="Wupdi"' und habe somit das Wupdi schnell extrahiert. Ich hüpfe also von Knoten zu den Attributen (die stehts in der gleichen Reihenfolge sein müssen) und wieder zum nächsten Knoten und extrahiere die Daten aus einem 50MB Winzling in knapp einer Sekunde. Großartig optimiert ist mein Code nicht, denn mir reicht das.

[Mithrandir]

Zitat:

Zitat von alzaimar

Falls sicher ist, das sich das XML-Format nicht ändert, könnte ein handgebissener 'Parser' die richtige Lösung sein.

Zumindest in nächster Zeit nicht, denke ich zumindest. Man will zwar grad die API auf eine neue Version updaten, aber das verzögert sich zum einen gerade etwas und zum anderen betrifft das auch nur die API, nicht die Rohdaten. :o)

Zitat:

Zitat von alzaimar

Mit einem optimierten PosEx aus dem FastCode-Projekt hüpfe ich in einem Knoten der Form '<Foo Uninteresting stuff Bar="Wupdi"..' sehr schnell von '<Foo' zu 'Bar="Wupdi"' und habe somit das Wupdi schnell extrahiert. Ich hüpfe also von Knoten zu den Attributen (die stehts in der gleichen Reihenfolge sein müssen) und wieder zum nächsten Knoten und extrahiere die Daten aus einem 50MB Winzling in knapp einer Sekunde. Großartig optimiert ist mein Code nicht, denn mir reicht das.

Das klingt sehr interessant. Optimieren kann man ja immer noch und von dem FastCode-Projekt habe ich schonmal gehört. Ist denn die Implementierung so trivial, wie es sich anhört?

[bigg]

Jetzt mal ehrlich, wenn die XML-Datei stolze 4 GB groß ist, dann drückt wohl eher dein verbauter Festwertspeicher auf die Performancebremse. Da kannst du noch so oft vergleichen. Nicht zu vergessen ist die Tatsache, das sich die Datei beim zweiten Vergleich bereits zum Teil noch im Speicher befindet und du mit Sicherheit dein System nicht neugestartet hast. Zweitens haben Alzamir und Muetze1 vollkommen recht. Ein 4 GB XML-File mit einem DOM-Parser in den Speicher laden ist einfach nur hohl. :stupid:
Ein SAX-Parser mit Hibernate plus entsprechender Datenbank sind da wohl die gewünschte Lösung. :angel: