Große xml Dateien importieren

[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 von 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.

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 von Blup:

Zitat von 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.

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

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

[completestranger]

Zitat von Blup:

Zitat von 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.

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 von Keldorn:

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]

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