XML - bei uns die richtige Wahl?

[moelski]

Moin !

Ich bin gerade dabei etwas tiefer in das Thema XML einzusteigen und wir überlegen generell ob wir unser selbst ersonnenes Datenformat in ein XML basiert überführen sollten.
Aber ich bin mir noch nicht ganz sicher ob das eine so gute Entscheidung ist und evtl. kann hier jemand mal ein bisserl aus Erfahrung was dazu sagen.

Ein Hauptgrund für dieses Posting ist ein Kommentar von hier: http://www.efpage.de/DelphiXML.html

Zitat:

...Bei einigen hundert kB stört das noch nicht so, aber bei großen Dateien werden sie die Verzögerung merken...

Ich beschreibe mal grob waraus unsere Dateien aufgebaut sind (das sind derzeit MemoryStreams die als Datei abgelegt werden):

Zunächstmal gibts da einen Header mit zig Informationen wie Datum, Uhrzeit, verwendetes Gerät, etc etc. Eigentlich etwas was geradezu geschaffen ist für XML. Weiterhin befindet sich im Kopf auch noch eine INI Datei die als Text eingebettet wird.
Weiter geht es dann mit Blöcken (die Anzahl der Blöcke hängt vom User ab). ein Block besteht dabei im groben aus folgendem:
1) aufgezeichnete Daten - das sind serielle Telegramme die von einem Gerät aufgezeichnet werden.
2) TChart (teilweise mit eingebetteten Daten
3) 2 RTF´s
4) Statusinfos die für den Block benötigt werden

Nun können gerade die TChart Blöcke und die aufgezeichneten Daten recht lang werden. Es gibt User die machen Langzeitmessungen und da kann es vorkommen das ein Block an reinen Daten schon 24Stunden * 60 Minuten * 60 Sekunden * Telegrammlänge an Bytes hat.
Dazu kommt dann noch das TChart mit seinen Eigenschaften und ggf. sogar mit den Daten.

Also in Summe können da schon ganz ordentlich Daten zusammenkommen. Also ich sag mal in Summe bewegen wir uns im Schnitt so um die 1-20MB Dateigröße.

Macht es Sinn ein solches Konstrukt nach XML umzustellen? Generell hätte XML ja schon reizvolle Vorteile wenn ich so an das "direkte Lesen" der Dateien denke, oder das User die Daten ohne unser Zutun weiterverwenden könnten, oder den direkten Zugriff mittels XPath und das Wegfallen von Überprüfungen von Größe und Position wie es bei Streams immer von Nöten ist.

Wenn aber XML die Sache verlangsamt, dann wäre es nicht so der Brüller

Vielleicht kann mir jemand da mal ein paar Tips / Argumente geben.

[OregonGhost]

Ich habe mit XML diesbezüglich zwei wesentliche Erfahrungen gemacht:
1. Du machst es dir immer am einfachsten, wenn du XML-Serialisierung verwenden kannst. Die geht fast automatisch und ist normalerweise, je nach Bibliothek, sehr schnell. In .NET wird beispielsweise für die Serialisierung Code generiert, der die Klassen sozusagen hartgecodet in XML schreiben und daraus lesen kann. Das funktioniert eigentlich auch mit größeren Dokumenten sehr angenehm.
2. Man kann XML ja auch zippen. Da sind erstaunlich hohe Komprimierungsraten möglich und die Geschwindigkeit ist gar nicht so schlecht. Eines meiner Projekte schaltet einfach einen GZipStream zwischen die Datei und die XML-Serialisierung, damit hat man sehr einfache Handhabung und es läuft bisher alles wunderbar und schnell genug (es müssen dabei ohnehin eine Menge andere Dinge gemacht werden, gegen die der XML-Overhead winzig wird).

Davon abgesehen bietet XML natürlich gewisse Vorteile wie das einfache Umwandeln in andere Formate, einfache Report-Generierung etc.
Ein Teil dieser Vorteile fällt bei dir jedoch weg, weil du ja anscheinend viele Daten doch wieder in einem speziellen Format kodierst.

Edit: Ich würde dir bei so großen Dokumenten grundsätzlich von einem DOM-Parser abraten und, wenn Serialisierung nicht verfügbar ist, entweder einen SAX-Parser oder einen Polling-Parser anraten, je nachdem, was du lieber magst oder besser für dein Dokument geeignet ist.

Als Fazit: Probier es aus. Schreib dir ein kleines Programm, dass dir eine beispielhafte, sehr große XML-Datei generiert und miss die Zeit, und dann lass das Programm die Datei wieder einlesen und miss wieder die Zeit (und die Dateigröße). Eine einfache Implementierung ist nicht aufwändig, aber damit kannst du auf jeden Fall herausfinden, ob die Performance oder die Datengröße ein Hinderungsgrund ist.

[moelski]

Moin !

Danke für die Hinweise!

Zitat:

Ich würde dir bei so großen Dokumenten grundsätzlich von einem DOM-Parser abraten und

Mist und das genau wollte ich verwenden

[OregonGhost]

Warum? Mit einem Polling-Parser kannst du genauso arbeiten wie mit dem DOM, nur dass du ihn antreibst, anstatt dass er selbst erstmal das ganze Dokument parst und in den Speicher lädt. Auch mit SAX ist es nicht wirklich komplizierter als mit DOM, nur etwas anders im Aufbau.

Übrigens, auf der von dir verlinkten Seite steht ja auch noch der Tipp, Binärdaten außerhalb der XML-Datei zu lagern. Du könntest also alle Daten, die sich gut in XML pressen lassen, in der XML speichern, alle Binärdateien referenzieren und das alles zusammen dann in eine ordinäre ZIP-Datei packen. So macht es zum Beispiel Office 2007.

[Bernhard Geyer]

Zitat von OregonGhost:

So macht es zum Beispiel Office 2007.

Und die haben es letztendlich von OpenOffice abgekupert die das schon immer so machen.

[moelski]

Moin !

Ok, SAX muss ich mir nochmal genauer ansehen. Ich habe mir bis jetzt nur DOM angesehen.

Zitat:

Du könntest also alle Daten, die sich gut in XML pressen lassen, in der XML speichern, alle Binärdateien referenzieren und das alles zusammen dann in eine ordinäre ZIP-Datei packen. So macht es zum Beispiel Office 2007.

Je länger ich drüber nachdenke ... Desto interessante klingt das ...
Das hätte sogar in gewisser Weise Vorteile. Dann dann müsste man aus dem XML z.B. kein TChart exportieren, sondern köntne es direkt verwenden. Und Vorschaubilder oder ähnliches wären auch direkt vorhanden und nicht als Binärklumpen ...

Die Idee hat was