Speicherbedarf bei Datenbank Query

[AndyDF]

Ich möchte hier nicht über Sinn oder Unsinn diskutieren, ob 30T sinnvoll sind oder nicht. Das ist ein reiner Test - dabei handelt es sich auch nicht um eine produktiv DB/Tabelle. Dient nur zur Veranschaulichung des Speicherbedarfs...

Der Ansatz von MSEgui und ZEOS 7.2 finde ich gut. Dadurch wird halt wirklich nur so viel Speicher geholt wie tatsächlich notwendig.

Gibt es in AnyDac eine Möglichkeit, auch so ein Verhalten zu erzielen um den Speicherbedarf in Grenzen zu halten? Oder evtl. in FireDAC?

[Sir Rufo]

Da es hier ja um Speicherbedarf und Performance geht kann man zunächst mal generell festhalten, dass Performance und Speicherbedarf sich umgekehrt proportional verhalten und wie immer gibt es Ausnahmen von der Regel.

Betrachten wir einmal den Fall, wo die Daten im Speicher liegen und für jedes Feld soviel Platz reserviert ist, wie dort maximal gespeichert werden kann. Jetzt haben wir sehr viel Platz verbraucht, allerdings sind die Zugriffe wesentlich schneller, da der Speicherbereich für jede Zeile mit einer einfachen Formel berechnet werden kann.

Code:

ZeilenSpeicher = Zeilenlänge * (Zeile-1)

Mit den Feldern geht das fast analog, da man jetzt nur noch die Länge der vorherigen Felder dazuzählen muss.

Liegen die Daten jetzt aber speicheroptimiert vor (die Felder nur so lang wie nötig), dann muss für jede Zeile die aktuelle Zeilenlänge bestimmt werden. Vereinfachen kann man das durch eine Längenangabe vor jeder Zeile, die dann aufaddiert wird. Es bleibt aber dabei, dass der Verwaltungsaufwand steigt und damit die Performance sinkt.

Wenn Änderungen an den Daten erfolgen, dann wird das insgesamt dramatischer, denn einfach so kann man eben nicht etwas im Speicher "dazwischen einfügen". Hier müssen dann ganze Blöcke verschoben werden. Ist der Platz aber schon reserviert, dann kann der einfach dort hineingeschrieben werden.

Einzig bei der Übertragung kommt es dann auf die Größe an. Hier gibt es unterschiedliche Möglichkeiten (Komprimierung, schlankes Format, ...) um die Performance zu erhöhen, wobei genau das bei sehr kleinen Paketen eher kontraproduktiv ist und bei grossen Paketen die Geschwindigkeit erhöht.

[mse1]

Zitat von AndyDF:

Ich möchte hier nicht über Sinn oder Unsinn diskutieren, ob 30T sinnvoll sind oder nicht.

Mit MSEgui sind übrigens queries mit einigen 100'000 records absolut machbar.

Zitat von Sir Rufo:

Liegen die Daten jetzt aber speicheroptimiert vor (die Felder nur so lang wie nötig), dann muss für jede Zeile die aktuelle Zeilenlänge bestimmt werden. Vereinfachen kann man das durch eine Längenangabe vor jeder Zeile, die dann aufaddiert wird. Es bleibt aber dabei, dass der Verwaltungsaufwand steigt und damit die Performance sinkt.

Wenn Änderungen an den Daten erfolgen, dann wird das insgesamt dramatischer, denn einfach so kann man eben nicht etwas im Speicher "dazwischen einfügen". Hier müssen dann ganze Blöcke verschoben werden. Ist der Platz aber schon reserviert, dann kann der einfach dort hineingeschrieben werden.

Wie gesagt, auch in MSEgui ist der Rekordpuffer Aufbau fix. Für Textdaten wird UnicodeString verwendet welcher im Recordpuffer den konstanten Speicherbedarf eines pointers hat.

[Dejan Vu]

Zitat von mse1:

Mit MSEgui sind übrigens queries mit einigen 100'000 records absolut machbar.

Klar, wenn bei einem VarChar(1000) nur ein Zeichen belegt ist... Aber im Ernst: Das ist schon optimal so und imho auch keine Performancebremse, wenn man den Speicher individuell reserviert. Der Speichermanager ist dafür zuständig, das halbwegs schnell hinzubekommen. Und bei gerade mal -von mir aus- 500.000 einzelne Zellen ist das eh in ein paar ms gemacht. Der bottleneck ist sowieso die Query selbst bzw. die Übertragung.

[mse1]

Mit SQLite ergeben sich für 1'000'000 records 3..4 Sekunden Ladezeit auf einem alten AMD Athlon Linux-Rechner.

[Dejan Vu]

Lokal. Wie interessant.

[mse1]

Für Firebird über ein 100MHz Netzwerk werden es dann 7..8 Sekunden für die gleichen Daten.