DbImport hängt sich auf

[jaenicke]

Zitat:

Zitat von Medium (Beitrag 1224635)

Noch flotter geht meiner Erfahrung nach der Ex- und dann wieder Import über CSV.

Das ist bei uns umgekehrt gewesen. Wir hatten das vorher so gemacht...
Eine Datenbank mit mehreren Millionen Einträgen dauerte so dann aber z.B. Stunden und auch kleinere dauerten relativ lange.

Dann habe ich das ganze auf FireDAC umgestellt und spreche die beiden Datenbanken nun direkt an. Der Import dauert nun statt Stunden mit riesigen temporären Dateien nur noch ca. 20 Minuten. Und unsere kleinren DBs sind innerhalb von wenigen Sekunden durch statt in Minuten.

[Medium]

Wenn von SQL-Dump die Rede ist, verstehe ich das Auswerfen einer SQL-Script Datei mitsamt Tabellendefinitionen und etlichen INSERT-Statements. Mit diesen läuft es bei mir um Größenordungen langsamer als über ein CSV, und das CSV sollte wie gesagt auf dem Server lokal auf der Platte liegen. Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

[jaenicke]

Zitat:

Zitat von Medium (Beitrag 1224646)

Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

Ich mache das nicht einzeln, ich bereite immer Häppchen vor und schiebe die dann auf einmal in die DB. FireDAC hat einen entsprechenden Modus, bei dem die Inserts erst gesammelt und dann gesammelt abgeschickt werden.

[Medium]

Klar, das mache ich auch - von Hand - so dass sich nachher etwas ergibt wie

SQL-Code:

INSERT INTO foo (field1, field2, field3) VALUES (0, 1, 2), (3, 4, 5), (6, 7, 8), ...

, und das ca. so lang, wie die max-Länge es zuließ. Aber dennoch flitzt mir der CSV-Import davon. Kann ich mangels geeigneter DB bzw. Daten gerade nicht schnell mit Messungen belegen, und auf nicht schnell hab ich grad keine Lust :). Fakt ist, dass ich nach Unzufriedenheit mit o.g. Methode nach Alternativen im Netz suchte, und bin dabei eben erst auf CSV gestoßen und fühlte mich glücklicher. Wenn mal Luft ist ne Test-App bauen.
(Bei mir war es übrigens meist MySQL, und ich meine auch mal ein MSSQL so sehr flott gefüttert zu haben.)

[Union]

Wie stellst Du dann binäre Blobdaten im CSV dar? Hexcodiert?

[Medium]

Schon beantwortet ;)

Zitat:

Zitat von Medium (Beitrag 1224635)

Ich weiss nur nicht, wie sich das dann mit BLOBs verhält. Dürfte problematisch sein.

Ich tendiere ohnehin eher dazu, Dateien im Filesystem zu erstellen und diese dann nur per Pfad zu referenzieren. Die Nachteile davon sind mir bewusst, bisher brauchte ich dass auch nur in zwei sehr kleinen Fällen, wo z.B. konkurrierende Zugriffe defacto kein Thema waren, und die nur bei uns intern eingesetzt werden.
Bei BLOBs dürfte das daher eher keine Option sein. Denkbar wäre noch - das müssten aber beide beteiligten DBMS unterstützen - der Weg über Base64*. Weiss ich aber nicht, nie gemacht, keine Ahnung wie das die Performance beeinträchtigen würde im Vergleich zu Stream-to-Stream mit INSERTs.

Edit *) Müsste doch aber eigentlich gehen, oder wie machen die DBMS das mit BLOBS bei einem SQL-Dump? Das sind ja auch nur Textfiles. Wie dem auch sei: Ich bin BLOBs bisher wenn möglich ausgewichen, und kann daher dazu keine wirklich qualifizierte Aussage machen. War in dem Fall hier imho aber auch nicht nötig für den TE.

[Union]

Bei MySQL sieht dann ein Insert so aus:

Code:

'0x...'

[Furtbichler]

Die meisten RDBMS unterstützen 'Bulk Inserts'. In die Richtung würde ich tendieren, wenn es mehr als 1000 Datensätze sind.

Bei MSSQL genügt der 'BULK INSERT' Befehl, aber dann ohne Progressbar. Über die API könnte das SqlBulkCopy-Objekt verfügbar sein, das Callbacks unterstützt.

Firebird unterstützt externe Tabellen. Ob das das Schnellste ist, weiß ich nicht, aber das Feature ist nett.

MySQL kennt 'LOAD DATA', Oracle 'BULK COLLECT'.

Wenn es nicht gerade ein Hinterhof-RDBMS ist, sollte das passende zu finden sein.

Ein BULK INSERT in MSSQL geht sehr schnell: 100.000 Datensätze in 1-2 Sekunden.

[Perlsau]

Zitat:

Zitat von Medium (Beitrag 1224646)

Wenn von SQL-Dump die Rede ist, verstehe ich das Auswerfen einer SQL-Script Datei mitsamt Tabellendefinitionen und etlichen INSERT-Statements. Mit diesen läuft es bei mir um Größenordungen langsamer als über ein CSV, und das CSV sollte wie gesagt auf dem Server lokal auf der Platte liegen. Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

Ich hatte das mal mit OpenStreetMap-Daten getestet, die ja bekanntlich riesig sind: Das Einlesen via Delphi-Code dauerte Tage, via SQL-Dump dagegen nur Stunden.