FireDAC: Viele Records einfügen dauert ziemlich lange

[Der schöne Günther]

Ich habe eine lokale Datenbank auf meiner SSD. Ich habe eine Tabelle mit drei Spalten:

Integer(FKEY)

Float

Float

Im Speicher habe ich jetzt 50.000 Einträge die ich dort speichern möchte. Meine Herren, das dauert lange. Mit AqTime-Profiler dauert das mit 20 Sekunden ca. vier mal so lange wie "in Echt", aber ich kann wenigstens sehen, was so viel Zeit frisst:

Code:

1x TGünthersDatabase.insertData(): 20 Sek
> 50.000x TFDDataSet.Post: 15 Sek
> >   TFDTable.InternalPost: 10 Sek
> >   TFDTable.InternalLast: 5 Sek
> 1x TFDDataSet.EndBatch: 3 Sek

Mein Code sieht so aus:

Delphi-Quellcode:

var
   einDatum: TDatum;
begin
   meineDatenbank.BeginBatch(False);
   try
      for einDatum in meineDatenAusDemSpeicher do begin
         meineDatenbank.Append();
         meineDatenbank.FieldByName('a').AsInteger := irgendeinFKey;
         meineDatenbank.FieldByName('b').AsFloat := einDatum.Float1;
         meineDatenbank.FieldByName('c').AsFloat := einDatum.Float2;
         meineDatenbank.Post();
      end;
   finally
      meineDatenbank.EndBatch();
   end;
end;

Vor Benutzung von Begin/EndBatch war es noch etwas schlimmer, aber viel hat es auch nicht gebracht.


Was können Profis mir noch für Tipps geben? Das kann doch so nicht richtig sein. Ich lese etwas von "Array DML" (was der Advantage Server aber garantiert nicht unterstützt) und "CachedUpdates". Bin ich hier auf dem richtigen Weg oder wird das auch nichts bringen?

[baumina]

DisableControls, falls Du Anzeigekomponenten verbunden hast.

[jobo]

Glaube FieldbyName ist nicht so schnelle, lieber Fields[i].
Insgesamt noch lieber Insert Statements mit Parameter statt Dataset, dann jenachdem möglichst selten commiten, am besten nur einmal am Ende.
Falls auf dem FK ein Index liegt, den solange deaktivieren datenbankseitig, sonst hast Du nicht nur 50T inserts, sondern das gleiche nochmal beim Index.

[Daniel]

ArrayDML war schon ein gutes Stichwort.
Auch kann man mal bei den UpdateOptions schauen. Hat man die Query so eingestellt, dass sie nach jedem .Post() ein .Refresh() macht, dann erklärt dies natürlich die Dauer.

[haentschman]

Moin...

Zitat:

Was können Profis mir noch für Tipps geben?

Dataset Edit / Insert / Post verabschieden.... Generische Listen mit den Datenobjekten + direktes SQL = 20000 Datensätze unter 2 Sekunden (nicht genau gemessen...Bauchgefühl (21..22..fertsch) DBMS: Firebird)

Hinweis: In Firebird kann man Blöcke bilden (1 Block = z.B. 200 SQL) die am Stück ausgeführt werden. Das verschnellert das ganze enorm.

[Der schöne Günther]

Zitat von jobo:

Falls auf dem FK ein Index liegt, den solange deaktivieren datenbankseitig, sonst hast Du nicht nur 50T inserts, sondern das gleiche nochmal beim Index.

Ja, tut es. Warum? Keine Ahnung. Ich verstehe nicht mal wirklich was das ist, ich denke mal, das hilft ihm bei SELECT-Statements den Kram schneller zu finden.

Mit der Lese-Dauer bin ich übrigens sehr zufrieden, Löschen dauert deutlich länger, ist aber auch noch akzeptabel. Nur Hinzufügen ist echt schlimm...


Eins verstehe ich nicht: Warum redet Ihr fast alle von einer Query? Es ist eine Tabelle, TFdTable.

Zitat von haentschman:

[...]

"Alles umschmeißen, anderes DMBS nehmen" wollte ich jetzt am wenigsten hören

Zitat von baumina:

DisableControls, falls Du Anzeigekomponenten verbunden hast.

Das übernimmt schon Begin/EndBatch()

Zitat:

Mit der Methode BeginBatch können Sie ressourcenaufwendige Operationen deaktivieren und die Datenmenge so einrichten, dass Aktualisierungen mit maximaler Ausführungsgeschwindigkeit ausgeführt werden. Der Aufruf von BeginBatch deaktiviert:
Die Aktualisierung von datensensitiven Steuerelementen.
Die Aktualisierung von Einschränkungen.
Die Wartung von Aggregaten.
Das Anzeigen von Wartecursors.
Die ähnlich ressourcenaufwendige Verarbeitung in DatS-Objekten, die nicht durch APIs der Datenmenge gesteuert wird.

[haentschman]

Zitat:

"Alles umschmeißen, anderes DMBS nehmen" wollte ich jetzt am wenigsten hören

Nö...so war das nicht gemeint. Nur der Hinweis auf die Blöcke. Ansonsten ist das ganze ja vergleichbar...

[Daniel]

Die FDTable ist eine Kompatibilitäts-Komponente für diejenigen, die von der BDE kommen. Intern werkelt eine - mehr oder weniger speziell konfigurierte - Query.
Wenn es nur um Insert-Statements geht, kannst Du auch ein FDCommand nutzen, welches eine sehr schlanke Komponente für SQLs ohne Ergebnismenge ist.

[jobo]

Zitat von Der schöne Günther:

Zitat von jobo:

Falls auf dem FK ein Index liegt, den solange deaktivieren datenbankseitig, sonst hast Du nicht nur 50T inserts, sondern das gleiche nochmal beim Index.

Ja, tut es. Warum? Keine Ahnung. Ich verstehe nicht mal wirklich was das ist, ich denke mal, das hilft ihm bei SELECT-Statements den Kram schneller zu finden.

Eins verstehe ich nicht: Warum redet Ihr fast alle von einer Query? Es ist eine Tabelle, TFdTable.

So soll das ja sein ein Index auf Fremdschlüsselfelder, alles gut.
Bei massiven Datenbewegungen (Insert oder Update) auf dem Schlüsselfeld ist der Index leider kontraproduktiv, er ist hauptsächlich eine Hilfe beim schnellen Select.
Der Vorschlag ist aber eher was für den Fall, dass Du mit Delphi Bordmitteln nicht so schnell wirst, wie Du möchtest.

Es reden alle von Query, weil da vermutlich die Erfahrung raus spricht, dass ein Dataset/Table für sowas nicht so geeignet ist.

Mach Dir ein Query Komponente aufs Formular, schreib das Insert Statement rein (parametriert) und fülle die Parameter aus Deinem Memdataset.
Das dann in eine Schleife und Du wirst es wahrscheinlich verstehen, woher die Empfehlung kommt.
Das Queryobjekt oder ein Command schickt einfach die Daten zum Server. Es gibt nahezu kein Overhead im Handling. Das ist beim Dataset eben etwas anders.

[Der schöne Günther]

Der goldene Weg ist es sicher nicht, aber ich habe statt

Delphi-Quellcode:

meinDataset.Append();
[...]
meinDateSet.Post();

nun mal gesagt

meinDataSet.ExecSQL(sqlString, [param1, param2, param3]);
und es ist schon mal 50% schneller. Die Tabellenkomponente benutze ich tatsächlich auch nur zum Einfügen. Hm...