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

**Harry Stahl**

Nun habe ich ein Update von meinem (einfachen) Datenbank-Programm fertig gestellt (keine große Nummer, eher für einfache Aufgaben und wenig Datenvolumen gedacht). Sollte vorab vielleicht erwähnen, dass ich hier alle Daten im Speicher halte (Stringlisten) und keine besondere Daten-Engine verwende.

Eigentlich wollte ich letzte Woche "nur" mal testen, wie viel Datensätze das Programm aus einer csv-Datei importieren kann (das hat das Release dann noch ein paar Tage verzögert...

).

Einige 10.000 oder 100.000 ging ja schon vorher, aber wie steht es mit Mio.Datensätzen?

Der erste Versuch, eine 170 MB große Datendatei mit ca. 2,1 Mio. DS zu importieren (in der Windows 32-Bit-Version) scheiterte kläglich an mangelndem Arbeitsspeicher.

OK, da kann man ja noch was optimieren. Den Stream brauch ich doch an Stelle X gar nicht mehr, also warum erst warten mit der Freigabe bis Stelle y, usw...

Die Daten werden in einen Stream eingelesen, der auf bestimmte Dinge überprüft wird und anschließend über eine Stringlist in mein Datenbank-Endformat gebracht (das z.B. aus der 170 MB-Datei dann eine nur noch 70 MB große Datei macht).

Was mir dabei auffiel - und mir jedenfalls nicht bewusst war - welche einfachen "bequemen" Dinge doch viel Arbeitsspeicher kosten:

Ein "if (pos '/sb', slData.text) <> 0" veranlasst Delphi, für (sldata.text) einen extra String zu bauen, der noch mal richtig schön Arbeitsspeicher braucht. Für kleine Datenmengen kein Problem, aber wenn man mehrere 100 MB geladen hat, schon.

Also lieber zeilenweise durch die Liste iterieren und nach dem Teil suchen.

Soweit habe ich das dann tatsächlich hinbekommen, dass ich in der 32-Bit-Version die 2,1 Mio. DS importieren und anzeigen lassen kann (schnell ist das Programm aber dann nicht mehr, in der allgemeinen Anzeige schon, aber in der Filterung von DS nicht, dazu später). Zur Erinnerung: Eine 32-Bit-Version kann nicht mehr als 2 GB Arbeitsspeicher in Anspruch nehmen.

OK und wie viele DS kann das Programm dann in einer 64-Bit-Version laden?

Eine große Datendatei zum freien Download habe ich hier gefunden:

https://sdm.lbl.gov/fastbit/data/samples.html

Eben die 2 GB-Datei mit 15 Mio. Datensätzen.

Aber auch hier scheiterte erst mal der Datenimport, weil die Stringliste nicht optimal arbeitet, wenn ein Encoding (UTF-8) auf den Stream angewendet werden soll.

Hier half mir ein Tipp von Uwe (

https://www.delphipraxis.net/1316866-post22.html), den ich für meine Bedürfnisse angepasst habe, so dass ich also auch die 2 GB in die Stringliste reinladen kann.

Interessanterweise benötigt die eingelesene Stringliste das 3-4 Fache an Arbeitsspeicher.

Hier fangen meine Fragen an:

* Warum eigentlich? UTF8- ist ja nicht gleich Größe mal zwei sondern eher Größe und ein wenig dazu.
* Gibt es Delphi-Interne Alternativen zur Stringliste (um die Daten zu halten), bzw. externe Lösungen, die nicht soviel Speicher verbrauchen?
* Die Sortierung (mit bis zu 3 keys) mache ich derzeit auch über eine Stringliste, eine TDictionary (das verwende ich für den Primärkey je Tabelle) hilft da nicht weiter, da ich ja nicht doppelte Einträge aufnehmen kann. Gibt es andere schnelle Alternativen für Sotierungen (mit mehreren Schlüsseln)?

**Delphi.Narium**

Zitat:

... externe Lösungen ...

Datenbank und SQL? Sind extra dafür erfunden worden.

Käme nie auch nur im Ansatz auf die Idee, solche Datenmengen mit Stringlisten ... im Arbeitsspeicher zu verarbeiten. Das muss zwangsläufig irgendwann an Speichermangel scheitern. Und wenn nicht an logischen Speichergrenzen, dann an physikalischen.

Datenbanken können alles das, wonach Du suchst.

**Redeemer**

Platzsparender wäre (falls der Arbeitsspeicher nicht zu fragmentiert ist) TMemoryStream und sich ein TDictionary<Integer, Integer> o.ä. mit Zeilenstartpositionen anzulegen. Da man beim Zeilenstart zwischen ANSI und UTF-8 nicht unterscheiden muss, würde man das Kodieren nach UTF-16LE („WideString“) erst beim Zugriff vornehmen. Schreiben wird aber schwer und insbesondere das Überschreiten von Capacity ein großes Problem.

Vermutlich ebenfalls möglich wäre ein TFileStream (oder TStringReader, wenn der intern auch so funktioniert), der die Dinge in einem Array von RawBawbyteString ablegt, grundsätzlich wäre es aber gut, die Zeilenzahl zu kennen.

**Bernhard Geyer**

Zitat von Delphi.Narium:

Zitat:

... externe Lösungen ...

Datenbank und SQL? Sind extra dafür erfunden worden.

Zitat von Delphi.Narium:

Käme nie auch nur im Ansatz auf die Idee, solche Datenmengen mit Stringlisten ... im Arbeitsspeicher zu verarbeiten. Das muss zwangsläufig irgendwann an Speichermangel scheitern. Und wenn nicht an logischen Speichergrenzen, dann an physikalischen.
Datenbanken können alles das, wonach Du suchst.

Alternativ einfach mal im Bereich der NoSQL-Datenbank nachschauen. Evtl. bieten diese Ja eine alternative zu einer herkömmlichen SQL-Datenbank.
Stichworte wären hier Lucene (Volltextsuche), Graphen-Datenbanken (

https://de.wikipedia.org/wiki/Graphdatenbank) oder die "üblichen NoSQL-"Datenbanken" (

https://de.wikipedia.org/wiki/NoSQL)

**Harry Stahl**

Zitat von Delphi.Narium:

Zitat:

... externe Lösungen ...

Datenbank und SQL? Sind extra dafür erfunden worden.

Käme nie auch nur im Ansatz auf die Idee, solche Datenmengen mit Stringlisten ... im Arbeitsspeicher zu verarbeiten. Das muss zwangsläufig irgendwann an Speichermangel scheitern. Und wenn nicht an logischen Speichergrenzen, dann an physikalischen.

Datenbanken können alles das, wonach Du suchst.

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

**Harry Stahl**

Zitat von Redeemer:

Platzsparender wäre (falls der Arbeitsspeicher nicht zu fragmentiert ist) TMemoryStream und sich ein TDictionary<Integer, Integer> o.ä. mit Zeilenstartpositionen anzulegen. Da man beim Zeilenstart zwischen ANSI und UTF-8 nicht unterscheiden muss, würde man das Kodieren nach UTF-16LE („WideString“) erst beim Zugriff vornehmen. Schreiben wird aber schwer und insbesondere das Überschreiten von Capacity ein großes Problem.

Vermutlich ebenfalls möglich wäre ein TFileStream (oder TStringReader, wenn der intern auch so funktioniert), der die Dinge in einem Array von RawBawbyteString ablegt, grundsätzlich wäre es aber gut, die Zeilenzahl zu kennen.

Ja, stimmt, capacity könnte ich auch sinnvoller vorbelegen...

**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"