AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Speicherbedarf bei Datenbank Query
Thema durchsuchen
Ansicht
Themen-Optionen

Speicherbedarf bei Datenbank Query

Ein Thema von AndyDF · begonnen am 1. Sep 2014 · letzter Beitrag vom 2. Sep 2014
Antwort Antwort
AndyDF

Registriert seit: 6. Sep 2006
Ort: Allgäu
99 Beiträge
 
Delphi 10.4 Sydney
 
#1

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 10:57
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?
Andreas Blenk

Geändert von AndyDF ( 2. Sep 2014 um 11:00 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 11:29
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
mse1

Registriert seit: 21. Nov 2007
115 Beiträge
 
#3

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 12:51
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.

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.
Martin Schreiber
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 13:04
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.
  Mit Zitat antworten Zitat
mse1

Registriert seit: 21. Nov 2007
115 Beiträge
 
#5

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 13:52
Mit SQLite ergeben sich für 1'000'000 records 3..4 Sekunden Ladezeit auf einem alten AMD Athlon Linux-Rechner.
Angehängte Grafiken
Dateityp: png loadtime.png (36,6 KB, 12x aufgerufen)
Martin Schreiber
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#6

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 14:35
Lokal. Wie interessant.
  Mit Zitat antworten Zitat
mse1

Registriert seit: 21. Nov 2007
115 Beiträge
 
#7

AW: Speicherbedarf bei Datenbank Query

  Alt 2. Sep 2014, 15:20
Für Firebird über ein 100MHz Netzwerk werden es dann 7..8 Sekunden für die gleichen Daten.
Martin Schreiber
  Mit Zitat antworten Zitat
Antwort Antwort

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:54 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-2025 by Thomas Breitkreuz