Große xml Dateien importieren

[Keldorn]

Hallo

Ich komm nicht weiter und brauch ein paar Denkanstöße 😉

Ich muss quasi eine Datenbank importieren
- Die Bereitstellung der Daten erfolgt als xml-Dateien.
- Am Aufbau kann ich nix ändern 😉
- Insgesamt sind es ca. 150 Tabellen
- Es gibt eine XSD Dateien, die alle infos enthält
- Vierteljährlich werden die Grunddaten bereitgestellt, hierbei ist jede Tabelle eine xml Datei
- Größe ist unterschiedlich, die xml reichen von ein paar kb bis zur größten von 1,7GB (ja, kein Schreibfehler GB)
- Täglich werden updates bereitgestellt, diese Dateien enthalten alle Datensätze/Tabellen
- Datenstruktur ist recht flach
<root>
<paar allgemeine InfoDaten>
<Daten-knoten>
<Tabellenname>
<einzelne Felder und Daten…>
im Falle der Grunddaten ist halt immer nur ein Tabelle drin.
Per xml-Datenanbindung hatte ich mir die Klassen erzeugt, für die normalen Dateigrößen und auch die updates klappt das super. Die großen Dateien sind ein problem. Das Einladen dauert Stunden/Tage bevor ich überhaupt zum Parsen komme.
Momentan splitte ich die großen Dateien in mehre kleine Dateien auf und fummele an den Dateien rum, dass sie jeweils gültige xml sind und lade die kleineren Dateien.
Frage ist: ob ich das mit Boardmitteln überghaupt hinbekomme die Dateien als Stück ohne Fummelei zu laden . Ich verrenn mich aber grade, weil ich mir nicht sicher bin, was ich mir gezielt anschauen kann/soll und das auch zum Erfolg führt. Ich würde aber gern beim Standard ohne Fremdkompos bleiben.
Die updates sind nicht so groß, die Einlese-Geschwindigkeit passt. Die Grunddaten vierteljährlich: auch nicht so zeitkritisch, ob das nun 60 oder 70minuten braucht ist, egal, aber es sollte nicht den halben Tag dauern.

- SAX wäre was, aber das geht nicht mit boardmitteln, oder? Der Teil der omnixml der bei delphi mit dabei ist, kann das ja nicht?
- Macht es Sinn sind die großen Dateien als Text sequenziell als Text zu lesen und die Daten zu Fuß auszulesen
- Oder bin ich mit meiner „Fummelei“ gar nicht so verkehrt?
- Himxml hatte ich probiert, ich bekomme aber auch hier mit dem Tree-Demo die große 1,7GB Datei nicht eingelesen --> out of memory

Danke & Gruß Frank

[Uwe Raabe]

Für so große Dateien sollte man besser auf einen SAX Parser umsteigen. Dabei wird die XML-Datei sequentiell gelesen und entsprechende Ereignisse ausgelöst, auf die man dann entsprechend reagieren kann.

Es mag auch andere geben, aber im Moment fällt mir da nur OXML ein: http://www.kluug.net/oxml.php

[peterbelow]

Ich kann Uwe da nur zustimmen, SAX ist für solch große Files die Methode der Wahl. Ich habe früher mal Sax für Pascal verwendet und war damit sehr zufrieden.

[Keldorn]

ok, danke, aber es ist richtig: eben dieser Teil ist bei Delphi im Standard nicht dabei?

[Sinspin]

Hallo, SAX habe ich auch schon verwendet. Auch um Tabellen einzulesen die etwas größer sind. Wir von verwenden /NSoftware TipwXML.
Keine Ahnung ob es das noch kostenlos bei Delphi dabei ist, wenn ich nicht irre war da mal was.

[peterbelow]

Zitat:

Zitat von Keldorn (Beitrag 1503603)

ok, danke, aber es ist richtig: eben dieser Teil ist bei Delphi im Standard nicht dabei?

Stimmt.

[Uwe Raabe]

Zitat:

Zitat von Keldorn (Beitrag 1503603)

ok, danke, aber es ist richtig: eben dieser Teil ist bei Delphi im Standard nicht dabei?

Wenn du die Interfaces für msxml nicht mitzählst, dann nicht. Aber um die zu benutzen wäre auch noch ein gewisser Aufwand nötig.

[completestranger]

Wohin importieren? RDBMS?

[Keldorn]

danke euch, ich schau mal, ob ich mit dem SAX weiterkomme

Zitat:

Zitat von completestranger (Beitrag 1503607)

Wohin importieren? RDBMS?

ja, später direkt in eine DB. hab aber nur eine Pro, da fehlt mir auch irgendwo ein Stückchen und ich kann das nicht direkt.
momentan importiere ich es als Zwischenschritt in normale Clientdatasets, die mit der Größe auch nicht klarkommen :roll:

[completestranger]

Entweder ich bin blind oder es wurde immer noch nicht geschrieben welches RDBMS zum Einsatz kommt.

[Keldorn]

Zitat:

Zitat von completestranger (Beitrag 1503611)

Entweder ich bin blind oder es wurde immer noch nicht geschrieben welches RDBMS zum Einsatz kommt.

dafür habe ich mich noch nicht schlussendlich entschieden.
Welche Bedeutung hätte das für dich?

Aus meiner aktuellen Sicht ist das erstmal zweitrangig, da ich ich ja den Grundbestand UND die updates behandeln möchte. Ziel ist schon, beides per Programm zu importieren. Nicht weiter tiefer geschaut, sicherlich kann ich eine xml auch direkt in ein DBsystem importieren. Da es aber über 150 Einzeldateien sind, beherrscht das keiner. Das hab ich gedanklich erstmal ausgeschlossen.

[Uwe Raabe]

Zitat:

Zitat von Keldorn (Beitrag 1503610)

momentan importiere ich es als Zwischenschritt in normale Clientdatasets, die mit der Größe auch nicht klarkommen :roll:

Was insofern auch nicht verwunderlich ist, da diese ja auch alle Daten im Speicher halten - was bei 1,7 GB XML-Daten ja auch mit einem SAX-Parser nicht unbedingt laufen wird.

Ich würde erstmal versuchen das Memory-Problem mit SAX und dem Schreiben in eine CSV-Datei lösen. Dabei sollte man dann aber auch TStreamWriter anstatt TStringList verwenden.

[Keldorn]

cds: japp, dessen bin ich mir voll bewusst. Eigentliche Datengröße ist ja deutlich kleiner, die xml ist ja durch die <xyz> aufgebläht. Datensätze sind es aber trotzdem genug

[completestranger]

Zitat:

Zitat von Keldorn (Beitrag 1503612)

Zitat:

Zitat von completestranger (Beitrag 1503611)

Entweder ich bin blind oder es wurde immer noch nicht geschrieben welches RDBMS zum Einsatz kommt.

dafür habe ich mich noch nicht schlussendlich entschieden.
Welche Bedeutung hätte das für dich?

Aus meiner aktuellen Sicht ist das erstmal zweitrangig, da ich ich ja den Grundbestand UND die updates behandeln möchte. Ziel ist schon, beides per Programm zu importieren. Nicht weiter tiefer geschaut, sicherlich kann ich eine xml auch direkt in ein DBsystem importieren. Da es aber über 150 Einzeldateien sind, beherrscht das keiner. Das hab ich gedanklich erstmal ausgeschlossen.

Da liegst du meiner Meinung nach gewaltig falsch. Wir importieren maßig, auch bis zu 2.xyz irgendwas GB große XMLs direkt in MSSQL. Es handelt sich dabei um typische EDI Meldungen wie INVOIC, REMADV, DESADV, PRICAT, PRODAT, etc. Die großen Dateien sind in ein paar Sekunden verarbeitet. Es spielt keine Rolle ob es Full- oder Delta-Meldungen sind.

[Sinspin]

Zitat:

Zitat von Keldorn (Beitrag 1503614)

cds: japp, dessen bin ich mir voll bewusst. Eigentliche Datengröße ist ja deutlich kleiner, die xml ist ja durch die <xyz> aufgebläht. Datensätze sind es aber trotzdem genug

Ist das immer XML output oder kannst du das Format auch beeinflussen?
Wenn Du die Daten als auch als CSV bekommen kannst sind erstmal die Dateien kleiner und einfacher, zeilenweise, zu lesen, und verarbeiten lassen sie sich auch deutlich leichter.
Noch besser wäre SQL, selbst wenn es ein anderer Dialekt ist und ein paar Ersetzungen gemacht werden müssen.

[Keldorn]

ich nehm jede Anregung gerne auf, sonst hätte ich ja nicht gefragt ;-)
bin aber erstmal krank :?

Zitat:

Zitat von completestranger (Beitrag 1503637)

Da liegst du meiner Meinung nach gewaltig falsch. Wir importieren maßig, auch bis zu 2.xyz irgendwas GB große XMLs direkt in MSSQL. Es handelt sich dabei um typische EDI Meldungen wie INVOIC, REMADV, DESADV, PRICAT, PRODAT, etc. Die großen Dateien sind in ein paar Sekunden verarbeitet. Es spielt keine Rolle ob es Full- oder Delta-Meldungen sind.

DB sind nicht so meins. ich wollte das perspektisisch über firedac aufbauen, damit ich dort unabhängig(er) bin. als DB wollte ich erstmal interbase probieren.
Mit den Sekunden klingt gut, aber da muss ja auch erstmal was dahinterstehen ;-). wenn es SAX ist, dann halt SAX

die updates sind bei mir etwas schwieriger, da werden Datensätze auch geändert, man bekommt ein i(nsert) d(elete) oder u(pdate) mit. Es ist nicht nur ein reines importieren.

Zitat:

Zitat von Sinspin (Beitrag 1503680)

Ist das immer XML output oder kannst du das Format auch beeinflussen?
Wenn Du die Daten als auch als CSV bekommen kannst sind erstmal die Dateien kleiner und einfacher, zeilenweise, zu lesen, und verarbeiten lassen sie sich auch deutlich leichter.
Noch besser wäre SQL, selbst wenn es ein anderer Dialekt ist und ein paar Ersetzungen gemacht werden müssen.

ich kann das Format nicht ändern, die Daten werden zur Verfügung gestellt. xml ist evtl nicht so unglücklich, es sind ein paar weniger Felder drin, die als string[500] oder string[2000] definiert sind, da sind sicher auch Zeilenumbrüche drin und da gehts beine csv ja schon wieder los;-)

[Blup]

Ich würde erst einmal ein Toll für die Kommandozweile schreiben:
- Lesen einer XML-Datei per SAX
- Ausgabe einer SQL-Script-Datei mit den entsprechenden Inserts (ist auch nicht viel anders als CSV-Datei)
Je nach Datenbanksystem alle par 1000 Datensätze ein "Commit;" einfügen, damit das ganze schneller verarbeitet wird und dem Server nicht der Speicher ausgeht. Dann kann man immer noch überlegen ob man diese Funktion und die Ausführung des Skripts in die eigentliche Anwendung integriert.

[completestranger]

Zitat:

Zitat von Keldorn (Beitrag 1503690)

DB sind nicht so meins. ich wollte das perspektisisch über firedac aufbauen, damit ich dort unabhängig(er) bin. als DB wollte ich erstmal interbase probieren.
Mit den Sekunden klingt gut, aber da muss ja auch erstmal was dahinterstehen ;-). wenn es SAX ist, dann halt SAX

die updates sind bei mir etwas schwieriger, da werden Datensätze auch geändert, man bekommt ein i(nsert) d(elete) oder u(pdate) mit. Es ist nicht nur ein reines importieren.

war nur ein vorschlag. die inserts, deletes und updates sind gar kein problem, weil es dann bereits daten im sql server wären und die lassen sich zusammen-joinen, etc.

[bernau]

Als SAX-Parser werfe ich mal den von Stefan Heymanns in den Ring. Verwende ich seit Jahren (Jahrzehnten).

http://www.destructor.de/xmlparser/index.htm

Dort nach TXMLScanner schauen.

[dummzeuch]

MSXML kann übrigens auch SAX. Ist auch ziemlich schnell, nur das Fehlerhandling ist wie immer bei COM eine Katastrophe, was die übliche Fehlermeldung ja auch schon sagt: "catastrohic failure" ;-)

[freimatz]

Zwischenfrage: wieso SAX? Kann eine moderne DB wie MSSQL nicht direkt die XML importieren? Vielleicht muss man die XML noch ein bischen umformatieren. Aber dazu gibts doch sicher heutzutage viele Tools - oder nicht?

[jobo]

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Ich vermute, dass Parsing auch unterschiedlich spannend ist. Sind es gigantisch große Objekte in XML oder sind es einfach nur viele kleine Records.

Was ich nicht verstehe am "Import", wohin, wenn der TE keine DB will oder zumindest lieber vermeiden.

Allein wegen der Größe und den schon erkennbaren Schwierigkeiten scheint es mir nicht empfehlenswert lokal mit einer 2GB XML Datei zu arbeiten oder dann mit 2 davon, wenn eine abgeglichen werden soll. Lieber alles in die DB und zwar direkt vom Server importieren lassen, statt die GB noch lokal durch ein Programm zu jagen.

[Blup]

Zitat:

Zitat von jobo (Beitrag 1503736)

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers, sondern höchstens von Tools die der DB-Hersteller zusätzlich liefert. Es ist wahrscheinlich einfacher sein eigenes kleines DB-unabhängiges Tool zu bauen, das die XML in eine SQL-Datei (Skript) wandelt, als sich auf eine bestimmte DB mit einem passenden Tool festzulegen. Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

[jobo]

Zitat:

Zitat von Blup (Beitrag 1503749)

Zitat:

Zitat von jobo (Beitrag 1503736)

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers,...Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

Ja, mag sein, wahrscheinlich gibt es viele DB Server die 24/7 so perfekt ausgelastet sind, dass sie vielleicht nicht viel mehr vertragen. (Abgesehen davon, dass sie am Ende trotzdem die Daten aufnehmen müssen) Doch wenn es um massive DV geht und gängige Tools mehr oder weniger zusammenbrechen, wenn es nur um das Parsing geht, gibt es vielleicht ein Problem oder?
Ein DB Server sollte überhaupt kein Problem haben, mit GB Daten umzugehen, das sehe ich weniger als Hoffnung, denn als Statement und eine komprimierte GB XML Datei ist zur Netzübertragung noch besser geeignet. Also solche kann sie vielleicht sogar gleich in den Import / DB gestreamt werden.
Und wie soll ein Prozess, bei dem GB Daten auf einem (einzigen) System verarbeitet werden (Import, Parsing, Verteilung / ETL) schneller werden dadurch, dass man einen (entfernten) Client zusätzlich ins Spiel bringt, der die GB Daten dann atomisiert und 1000e bis Millionen von Einzelschritten über Netz ausführt und dabei wahrscheinlich kaum Datenoverhead spart.

Und apropos Zuständigkeit, es gibt gute, kostenlose Tools zur Zerlegung großer XML Dateien, das braucht man auch nicht selbst zu schreiben.

[Keldorn]

Danke für die rege Diskussion, hilft mir :thumb::thumb:

Grundlegend hatte ich eben so ein Tool im Kopf. Das sollte sich um den automatischen import und updates kümmern und dann eben später eine DB aufbauen. Ich war der Ansicht, dass ich die Daten erstmal intern halte und dann halt bei Bedarf die DB aufbaue. Und hier dann auch unabhängiger vom DB-Zielsystem bin.
Problem ist halt auch der unschöne Aufbau, die Tabellennamen heißen nur z.B. „T10000“ und das Programm sollte die auch besser & lesbarer anlegen: „T1000-Beschreibung“.

Select T10000.xyz
…
From T10000
Where T1000.blub = T20000.blub etc
Liest sich irgendwie überhaupt nicht.

Beim import filtere ich auch bestimmte und zu alte Daten raus, für meine Zwecke brauch ich z.B. keine 5 Jahre alten Daten, die die eigentlich DB auch nur aufblähen.
Bei den updates komme ich halt auch nicht an dem Punkt vorbei, dass mit jedem record erstmal geschaut werden muss, was mit ihm passiert (insert, update, löschen).

Grundlegend ist auch alles dabei, das meiste sind aber schon viele kleine records mit mehreren strings[10].

Deswegen auch die clientdatasets, da hier schon die gleiche Struktur vorliegt. Das hat ja auch geklappt, die CDS können schon die großen Daten halten, nur nicht speichern (insuffizient memory). Das ging halt nun nicht, Pech und google bringt hier auch nicht viel außer es geht nicht.
Werde bei Firedac bleiben und die Daten nun direkt in der ZielDB halten.
Für den eigentlichen import schaue ich mir die Hinweise intensiver an, danke

Ich muss erstmal wieder fit werden und werde mich sicherlich mit paar Punkten nochmal melden:-D

[completestranger]

Zitat:

Zitat von Blup (Beitrag 1503749)

Zitat:

Zitat von jobo (Beitrag 1503736)

Ich hätte jetzt auch mal "direkter DB Import" gerufen.
DB können das, limitierend sind da eher noch die Ausgangsdateigrößen von >2GB.

Das ist aber nicht die Aufgabe eines Datenbankservers, sondern höchstens von Tools die der DB-Hersteller zusätzlich liefert. Es ist wahrscheinlich einfacher sein eigenes kleines DB-unabhängiges Tool zu bauen, das die XML in eine SQL-Datei (Skript) wandelt, als sich auf eine bestimmte DB mit einem passenden Tool festzulegen. Die Übermittlung von einem GB-SQL-Skript an den Server sollte bei heutiger Netzwerkgeschwindigkeit nur ein par Sekunden dauern. Wichtiger scheint hier die Verarbeitungsgeschwindigkeit des Servers.

ja und das lesen von großen XMLs/JSONs mit mehreren hunderttausend "zeilen" dauert in SQL auch nur wenige sekunden. und es ist DEFINITIV aufgabe SQLs, sonst würde die ISO/IEC es nicht im standard aufnehmen

https://en.wikipedia.org/wiki/SQL:2003 - XML-related features (SQL/XML)
https://en.wikipedia.org/wiki/SQL:2016 - JSON

man sollte sich gegen neue dinge nicht wehren, besonders wenn der bedarf vorhanden ist. jede mir bekannte VERNÜNFTIGE SQL server software unterstützt XML/JSON

MSSQL: T-SQL
XML: https://docs.microsoft.com/en-us/sql...xml-sql-server
JSON: https://docs.microsoft.com/en-us/sql...l-server-ver15

ORACLE: PL/SQL
XML: https://docs.oracle.com/cd/B19306_01...9/xdb04cre.htm
JSON: https://docs.oracle.com/database/121/ADXDB/json.htm

PostgreSQL: PL/pgSQL
XML: https://www.postgresql.org/docs/9.1/functions-xml.html
JSON: https://www.postgresql.org/docs/9.3/functions-json.html

MariaDB: SQL/PSM
XML: https://mariadb.com/kb/en/load-xml/
JSON: https://mariadb.com/kb/en/json-functions/

etc. pp.

einen SQL server mit mehreren tausenden befehlen zu bombardieren ist falsch, solange/sobald man mit wenigen befehlen zum gleichen ergbnis kommt

[completestranger]

Zitat:

Zitat von Keldorn (Beitrag 1503917)

Beim import filtere ich auch bestimmte und zu alte Daten raus, für meine Zwecke brauch ich z.B. keine 5 Jahre alten Daten, die die eigentlich DB auch nur aufblähen.
Bei den updates komme ich halt auch nicht an dem Punkt vorbei, dass mit jedem record erstmal geschaut werden muss, was mit ihm passiert (insert, update, löschen).

und warum sollte das GEGEN eine SQL lösung sprechen? die dinger heißen nicht umsonst relational DATAbase management system (RDDBMS).
die daten liegen dann z. b. in einer temp-tabelle oder einfach in einer "staging"-tabelle, da kannst du dann filtern mit der WHERE-clause was die daten hergeben.
deine INSERTs, UPDATEs und DELETEs kannst du dann auch machen aka

Code:

delete from produktiv
from produktiv p
join staging s on s.primarykey = p.primarykey
where s.veraltet = 1

hab n zweieinhalb menütiges video erstellt in dem eine 330 mebibyte JSON mit fast 320k datensätze in ~ 55 sekunden verarbeitet wird
* datei in stream laden
* in mssql server schieben
* im mssql server verarbeiten
https://1drv.ms/u/s!AryujEYLwnlNgXQq..._0dzp?e=EbYCFL

[jobo]

:thumb:


Mir fällt nichts ein, was gegen den Import direkt auf dem Server spricht (außer, wie gesagt, das Teil ist eh schon 24/7 überlastet).
Allein die reine Übertragung der Datei zum Server als Zipfile spart an der Stelle grob 90% Volumen / Zeit. Klar geht es heute schneller durchs Netz als vor 5 Jahren, rechnet man den Upload beim Kunden und die üblichen asynchronen Übertragunsraten mit, macht es schon einen ziemlichen Unterschied. Das kann man dann noch hochrechnen, wenn die Sache häufiger stattfindet.

So einen Vorgang überhaupt per XML zu realisieren ist dennoch fragwürdig. Ich hatte in dem Bereich auch schon diverse Diskussionen mit Kunden. "Ja aber XML ist doch so flexibel". Ja, klar, aber Flexibilität hat ihren Preis. Der XML Overhead dürfte je nach Modell zwischen 25-50 % Datenvolumen liegen. Die Komplexität des Parsings eines Riesenobjekts ist halt was anderes, als bei einem Zeilen orientierten Format. Irgendwo dazwischen würde ich JSON ansiedeln.

Apropos Flexibilität:
XML bietet zwar eine enorme strukturelle Flexibilität inkl. Typen und Validierung, aber an der Stelle kann man sich auch wieder schnell ins Knie schießen, weil es dank der Möglichkeiten auch unheimlich viele Fallstricke gibt. Wahrscheinlich ist nichts so nervig, wie eine pingelige XML Verarbeitung. Codierung, Escaping und am Ende handgemachte Fehler (hand coded XML processing) mit irgendwelchen seltenen Artefakten, wo Elemente nicht geschlossen werden, wenn Vollmond ist oder sowas, da kommt keine Freude auf.
Also XML Import lieber ausschließlich dann, wenn es ein vollautomatisierter Prozess ist, ohne humanoiden Eingriff und mit guten, bewährten (also viel benutzten und ständig gepflegten) Libs.

ETL:
Die Vorstellung in 2GB XML per Code rumzuhampeln, krasse xpath Filter und Suchen zu bemühen und unübersichtliche, case und if Romane zu verfassen, Datensuche, Abgleich, Löschung, Ergänzung durchzuführen ist für mich absolut unterirdisch.
Lieber wie completeStranger schrieb: Alles importieren (Importieren = in die Datenbank, nicht in die Produktivtabellen). Dann schön bequem und effizient mit SQL verarbeiten. Nichts wird schneller, robuster und zuverlässiger sein, versprochen.
Vielleicht wiederhole ich mich, aber das ist streng genommen nicht ETL, sondern eher LET oder LTE. Erst Laden (in die DB!), dann Extrahieren, Transformieren. Früher, als DB Ressourcen relativ langsam und teuer waren, hat man nur lieber handgestreichelte Daten ins System importiert. Heute hat man einerseits mehr Power und Ressourcen, andererseits ist der Abgleich auch kleiner, externer Datenmengen mit einer xTB großen DB ziemlich ressoucenintensiv.

[Keldorn]

danke, ich schau mir das alles tiefgründig an :thumb: