Kodieren gegen großes Datenvolumen (Datendatei > 2 GB, > 15 Mio. DS)

[Delphi.Narium]

Zitat von Harry Stahl:

Das ist natürlich schon klar, dass ich mit einer "echten" leistungsfähigen Datenbank-Engine ganz andere Sachen machen kann (wenn man sich denn damit auskennt, das ist ja bei mir das bekannte "Schwarze Loch").

Aber ich habe es ja Anfangs erwähnt, dass das Programm gar nicht für Arbeit mit Mio. DS ausgelegt ist. Wäre aber dennoch interessant, wenn man das zur Not dennoch mal auch mit diesem Programm machen könnte...

Daher die Frage nach Optimierungen. Für die Version 5 kann ich mir dann ja immer noch überlegen, eine richtige DB-Engine zu nehmen...

Formulieren wir es mal etwas provokant:

Lieber implementierst Du eine eigene Datenbankengine, statt eine vorhandene zu nutzen, da Du Dir die Nutzung einer vorhandenen als "schwarzes Loch" vorstellst.

Bin mal so vermessen zu behaupten: Die Beseitigung des "schwarzen Loches" ist weniger aufwändig, als eine sinnvolle und funktionierende Implementierung dessen, was Du vorhast.

Das Schreiben einer Datenbankanwendung mit Delphi ist so banal einfach, dass man da nichtmal wirklich DB-Knowhow haben muss.

[Harry Stahl]

Auf die "richtige" DB-Anwendung werde ich mich später mit Sicherheit mit Freuden drauf stürzen. Momentan kommt mir es aber dennoch auf eine weitere Optimierung der Effizienz und Geschwindigkeit der aktuellen Programmfassung an.

Was ich vorhatte, habe ich mit meiner aktuellen Lösung 100% erfüllt (DB-Programm, das bei Verwendung von Datensätzen um die 100.000 herum absolut zügig und effizient zu verwenden ist und alle Anforderungen (incl. relationales Datenbankmodell, berechnete Felder, Import und Export relevanter Formate, Abfragen, etc., nutzbar auf 5 Plattformen (Windows, MAC, Linux, IOS und Android)) unterstützt.

Als das hier alles so mit der Plattformübergreifenden Entwicklung los ging, war ich froh, dass ich meine eigene Lösung hatte, denn anderweitig gab es ja erst mal nicht so viel. Außerdem ist meine Lösung extrem flach und einfach zu verwenden und leicht anpassbar, insofern macht es absolut Sinn, sich so etwas vorzuhalten.

Die Optimierungs-Tipps im Zusammenhang mit dem Umgang mit großen Datenvolumen kann man sicher auch noch anderweitig verwenden.

Ich denke, auch für eine der "normalen" Delphi SQL-Datenbanken muss eine eigene csv-Import-Routine geschrieben werden, oder gibt es da schon Lösungen, die alle so denkbaren Varianten (Linux / Windows Dateiformate, String-Kodierungen / Plattformen) abdeckt?

[Delphi.Narium]

Wüsste jetzt nicht, dass ich jemals für 'ne Datenbankanwendung 'nen CSV-Import benötigt habe.

In der ODBC-Verwaltung findet man z. B. auch "Treiber" für CSV-Dateien, das ist dann wohl nicht zwingend plattformunabhängig. Man kann damit aber auf CSV-Dateien in der gleichen Form zugreifen, wie auf alle übrigen Datenbanken. Für die Datenbankkomponenten ist das absolut transparent.

Wenn man z. B. die Zeoslib-Datenbankkomponenten (oder vermutlich auch alle anderen Datenbankkomponenten) nutzt, so muss man nur in der Komponente, die für die Verbindung zur Datenbank zuständig ist, angeben, um was für eine Datenbank es sich handelt. Alle anderen Komponenten sind davon nicht betroffen.

Lediglich durch Änderung dieser Konfigurationsparameter kann man einem Programm eine "andere Datenbank unterschieben". Natürlich kann man das auch über eine Konfigurationsdatei, 'nen Konfigurationsdialog (o. ä.) steuern, so dass man ein Programm so implementieren kann, dass ihm die darunterliegende Datenbank schlicht egal ist.

Und damit hat man dann auch Plattformunabhängigkeit.

Man schreibe das Programm so, dass man über eine Konfiguration die Datenbank wählt und kann dann auf jeder Plattform die Datenbank verwenden, die dort am besten geeignet ist.

Zum Datenbankwechsel ist (bei halbwegs intelligenter Programmierung) kein Neukompilieren des Programmes nötig.

Wenn ich mal 'ne Datenbankanwendung brauche, ohne 'ne Datenbank zu nutzen, nehme ich dafür KbmMemTable. Das sind Textdateien mit 'nem Header, in dem im Klartext steht, wie der Inhalt der Datei aufgebaut ist, was es so an Index gibt ...
Die Daten sind je Datensatz in einer Zeile, die von Aufbau und Struktur einer CSV-Datei entspricht.

Der Zugriff auf diese Dateien erfolgt über eine Schnittstellen-/Konfiguratinskomponente und damit verbundene, von TDataSet abgeleitete, Komponente. Die kann man im Quelltext genauso nutzen, wie jede beliebige andere Datenbankkomponente auch.

Damit könntest Du vermutlich Dein Eingangsproblem auch lösen, da alle Deine Anforderungen auch von diesen Komponenten erfüllt werden. Das Handling ist aber sicherlich einfacher, als mit Stringlisten ...

[Thomas Horstmann]

Wie entwickeln Datenbanken die auch mal mehrere Milliarden Datensätze enthalten können. Unser System ist zwar multidimensional aufgebaut aber die Probleme sind wahrscheinlich ähnlich. Es hat sich gezeigt, das die Standardkomponenten wie TStringList, TDictionary usw. für so etwas nicht ausgelegt sind. Auch Tricks wie TList.Capacity bringt nicht viel. Deshalb wurde alles ziemlich weit unten neu "aufgebaut". Auch auf TObject wurde verzichtet, da der Overhead (Geschwindigkeit und Speicher) im Vergleich zu TRecord zu groß ist. D.h. es blieb nur noch TRecord, Arrays, Pointer und selber QuickSort Routinen schreiben (zum Suchen und Einfügen). Und an einigen kritischen Stellen ASM verwenden. Damit läuft es aber sehr ordentlich. Also eher "back to the basics"

[Harry Stahl]

Zitat von Thomas Horstmann:

Wie entwickeln Datenbanken die auch mal mehrere Milliarden Datensätze enthalten können. Unser System ist zwar multidimensional aufgebaut aber die Probleme sind wahrscheinlich ähnlich. Es hat sich gezeigt, das die Standardkomponenten wie TStringList, TDictionary usw. für so etwas nicht ausgelegt sind. Auch Tricks wie TList.Capacity bringt nicht viel. Deshalb wurde alles ziemlich weit unten neu "aufgebaut". Auch auf TObject wurde verzichtet, da der Overhead (Geschwindigkeit und Speicher) im Vergleich zu TRecord zu groß ist. D.h. es blieb nur noch TRecord, Arrays, Pointer und selber QuickSort Routinen schreiben (zum Suchen und Einfügen). Und an einigen kritischen Stellen ASM verwenden. Damit läuft es aber sehr ordentlich. Also eher "back to the basics"

Ja, danke das sind Erfahrungsberichte, die ich sehr interessant finde. Habe mir schon so was gedacht.

Wie gesagt, meine jetzige Lösung ist nur eine "kleine" Lösung, aber für die Version 5 im nächsten Jahr will ich dann doch auch große Datenmengen (> 100 Mio. oder mehrere Mrd) zügig verarbeiten können.

Habt Ihr dann ganz auf die "typischen" SQL-DB's verzichtet und eine eigene Lösung gebastelt?

Und selbst das TDictionary haltet Ihr nicht für geeignet? Wegen des Anlegens der Sammlung oder Speicherverbrauch? An der Geschwindigkeit könnte es doch eher nicht liegen, oder?

Die vorgetragenen Argumente pro SQL sind mir alle einleuchtend, dennoch hänge ich ein wenig an eigenen Lösungen, da die oft sehr viel mehr Flexibilität für "Sonderwünsche" bieten.

[dummzeuch]

Wenn in den Daten viele Strings doppelt vorkommen, hilft vielleicht String Interning. Das hat mir mal sehr geholfen, den Speicherbedarf einer Anwendnung zu reduzieren. Dadurch werden doppelte Strings zu einem einzigen zusammengefasst, der dann entsprechnend einen höheren Referenzzähler hat.

Eine Implementation auf Basis einer Stringlist findest Du z.B. in meiner dzlib. Die ist allerdings noch für AnsiStrings entwickelt und mit UnicodeStrings nicht getestet.

[Thomas Horstmann]

Unsere Datenbank ist multidimensional und da läuft die Speicherung anders wie in der relationalen Wert. Eine Tabelle besteht nicht aus einem großen "Array", sondern aus viele kleinen, die untereinander per Pointer verbunden sind. Ggf. werden diese Konstrukte dann Milliarden mal durchlaufe, so dass es "unten" auf jedes if/then/else ankommt. Und 10% mehr Speicher oder weniger Geschwindigkeit ist dann schon ein Ausschlusskriterium. Wir haben einiges getestet und alles ab TObjekt war nicht brauchbar.

Aber das ist auch der Vorteil von Delphi; es ist relativ alt und systemnah. Strukturen wie Array, Pointer, Record usw. kommen aus einer Zeit als CPU und Speicher knapp waren. Da musst alles extrem optimiert werden. Und dem Kunden heute kann es "grundsätzlich" nie schnell genug gehen.

[Harry Stahl]

Zitat von dummzeuch:

Wenn in den Daten viele Strings doppelt vorkommen, hilft vielleicht String Interning. Das hat mir mal sehr geholfen, den Speicherbedarf einer Anwendnung zu reduzieren. Dadurch werden doppelte Strings zu einem einzigen zusammengefasst, der dann entsprechnend einen höheren Referenzzähler hat.

Eine Implementation auf Basis einer Stringlist findest Du z.B. in meiner dzlib. Die ist allerdings noch für AnsiStrings entwickelt und mit UnicodeStrings nicht getestet.

Interessante Idee, nur kommen hier im Prinzip keine doppelten Strings vor, da jeder String mit einem eindeutigen ID versehen ist (somit ist jeder String anders).

Aber dennoch interessant, evtl. kann man es ja mal bei einer anderen Gelegenheit verwenden.

[mkinzler]

Zitat:

Das ist natürlich schon klar, dass ich mit einer "echten" leistungsfähigen Datenbank-Engine ganz andere Sachen machen kann (wenn man sich denn damit auskennt, das ist ja bei mir das bekannte "Schwarze Loch").

Dann bleibe ja noch der Zwischenweg: ORM. Der Zugriff auf Datenbanekn über Nicht-Datenbank-Strukturen.