![]() |
AW: Große xml Dateien importieren
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?
|
AW: Große xml Dateien importieren
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. |
AW: Große xml Dateien importieren
Zitat:
|
AW: Große xml Dateien importieren
Zitat:
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. |
AW: Große xml Dateien importieren
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 |
AW: Große xml Dateien importieren
Zitat:
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 ![]() ![]() 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: ![]() JSON: ![]() ORACLE: PL/SQL XML: ![]() JSON: ![]() PostgreSQL: PL/pgSQL XML: ![]() JSON: ![]() MariaDB: SQL/PSM XML: ![]() JSON: ![]() etc. pp. einen SQL server mit mehreren tausenden befehlen zu bombardieren ist falsch, solange/sobald man mit wenigen befehlen zum gleichen ergbnis kommt |
AW: Große xml Dateien importieren
Zitat:
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:
hab n zweieinhalb menütiges video erstellt in dem eine 330 mebibyte JSON mit fast 320k datensätze in ~ 55 sekunden verarbeitet wird
delete from produktiv
from produktiv p join staging s on s.primarykey = p.primarykey where s.veraltet = 1 * datei in stream laden * in mssql server schieben * im mssql server verarbeiten ![]() |
AW: Große xml Dateien importieren
: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. |
AW: Große xml Dateien importieren
danke, ich schau mir das alles tiefgründig an :thumb:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:17 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz