Speicherbedarf bei Datenbank Query

[AndyDF]

Hallo zusammen,

ich bin gerade auf etwas gestoßen und frage mich ob man hier die Performance steigern kann.

Und zwar habe ich in einer Beispiel-Tabelle zwei Felder. Eines als VARCHAR(100) und das andere als VARCHAR(1000) deklariert. In der Tabelle befinden sich ca. 30.000 Datensätze. Alle Rows in beiden Spalten sind mit nur einem Zeichen bestückt.

Wenn ich jetzt einen FetchAll zunächst auf die 1. Spalte ausführe und dann zum Vergleich auf die 2. Spalte ausführe so kann ich feststellen, dass wesentlich mehr Speicher beim FetchAll auf die Spalte VarChar(1000) reserviert wird. Ist auch klar(?), da ja das Feld 10 mal so viel Zeichen speichern kann.

Aber ist es wirklich klar? Firebird selbst kann ja damit umgehen und reserviert bei VARCHAR nur so viel Speicher wie tatsächlich in den Zellen steht. In IBExpert oder auch mit AnyDac wird jedoch immer so viel Speicher reserviert wie max. in der Spalte an Daten kommen könnte.

Jetzt meine Frage: Gibt es eine Möglichkeit, so dass beim FetchAll (z.B. über einen AnyDac Query) nur so viel Speicher reserviert / benötigt wird, wie tatsächlich aus der Datenbank kommt? Oder macht das keinen Sinn? Ich denke dadurch könnte die Performance doch gesteigert werden?!?

Viele Grüße,
Andy

[jobo]

Also, die Frage ist berechtigt. Aber wer braucht 30T Datensätze mit einem Buchstaben? Ist ja schlimmer als Telefonbuch.
Wie wärs mit 30 Datensätzen? Oder 300?

oder alternativ mal ein
Select substring(<LangesFeld>,1,1) probieren, dann halt mit 30T Datensätzen.

[AndyDF]

Hallo,

die Beispieldaten sind in diesem Beispiel nicht relevant. Die 30T Datensätze nur deshalb, damit man auch was im Speicher merkt. Ein Zeichen war nur mein Test um zu zeigen, dass die Speicherreservierung nichts mit dem tatsächlichen Inhalt zu tun hat. Es gehen natürlich auch 10435 Datensätze.

Mir geht es bei meiner Frage nicht um die Optimierung der Daten sondern vielmehr um den reservierten Speicher. In unserer Produktivumgebung schaut es eh ganz anders aus. Aber wir haben viele Felder mit der Länge 100. Aber nur wenige Zellen sind auch wirklich mit 100 Zeichen bestückt. Dennoch wird sehr viel Speicher belegt, wenn wir viele Datensätze fetchen müssen. Und meiner Meinung nach viel Speicher umsonst.

Viele Grüße,
Andreas

[mkinzler]

Deshalb auch der Einwand, warum man so viele DS fetchen muss

[hstreicher]

ich sehe das so :

Der Client kennt deine Daten nicht, da sie ja noch nicht übertragen sind ,
er muss sich also bei der Speicherreservierung nach dem maximalen Speicherbedarf des Record / der Felder richten
entsprechend gross wird's dann auch , da er den Speicher ja nach "Worst Case" reservieren muss

mfg Hannes

[Blup]

Für was braucht man 30.000 Datensätze gleichzeitig im Speicher?
Wenn man dem Anwender wirklich so viele Datensätze in einem Grid anzeigen will, genügt erst einmal nur die ID (Primärschlüssel).
Vieleicht noch die Spalte nach der sortiert ist, um im Grid zu suchen.
Die Daten die jeweils tatsächlich zur Anzeige oder Bearbeitung benötigt werden, kann man einzeln nachladen.

Sehr viele Textfelder der selben Größe in einer Tabelle?
Das weist auf eine ungünstige Tabellenstruktur hin.

[Dejan Vu]

Ich glaube, zu dem Thema 'Wer braucht schon 30.000 Datensätze' haben wir schon diverse Threads, auch mit dem Ansatz des Paging etc. So trivial, wie man denkt, ist die Aufgabe allerdings nicht.

Es ist schön und praktisch, alle 30.000 DS im Speicher zu haben. Dann kann man nämlich viel einfacher Filtern, exportieren, summieren, Charts zeichen etc. Nicht, das das mit Paging nicht ginge, aber eben etwas schwerer und vor allen Dingen nicht so schnell.

30.000 DS gehen ja noch. Bei 3 Millionen ist das dann aber schon blöd.

[mse1]

Zitat von AndyDF:

Aber ist es wirklich klar? Firebird selbst kann ja damit umgehen und reserviert bei VARCHAR nur so viel Speicher wie tatsächlich in den Zellen steht. In IBExpert oder auch mit AnyDac wird jedoch immer so viel Speicher reserviert wie max. in der Spalte an Daten kommen könnte.

MSEgui und ZEOS 7.2 machen das tatsächlich so. Da stehen im TDataset record für Textfelder jeweils nur ein pointer zu den effektiven Daten variabler Grösse. In MSEgui ist es direkt ein UnicodeString.

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