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.

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

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

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

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

**Harry Stahl**

Zitat von Redeemer:

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.

Tfilestream zu verwenden war eine gute Idee fürs Laden und Speichern der eigenen Datendatei, da ich so das zusätzliche Anlegen von großen TMemorystreams vermeiden kann. Wenn die DB verschlüsselt ist, muss ich allerdings doch wieder TMemorystream verwenden, da das verschlüsseln und entschlüsseln auf einem TFilestream zu langsam ist. Letztlich aber nicht so schlimm, da ich die Verschlüsselung immer nur auf eine komprimierte Datei anwende, die ist deutlich kleiner als die eigentliche Datenmenge und das dekomprimieren der entschlüsselten Datei geht zügig genug mit dem Filestream.

Mit den ganzen Optimierungen ist es mir jetzt immerhin gelungen (in der Windows 64-Bit bzw. Linux-64-Bit-Version mit mindestens 16 GB RAM) die 2,1 GB große csv-Datei mit über 15 Mio. Datensätzen zu importieren und in meinem komprimierten Datenformat zu speichern (dann werden da ca. 600 MB draus). Wie gesagt, arbeiten kann man damit dann nicht mehr flüssig (z.B. die "Life"-Filterung wird dann extrem hakelig und laden und speichern dauert z.B. einige Sekunden), also nach wie vor bleibt es bei der Zielgruppe der User, die nicht mehr als 100.000 - 200.000 DS mit dem Programm bearbeiten müssen. Hat aber einfach Spaß gemacht, die Leistungsgrenzen mal ein wenig aufzubohren und ein wenig mehr Gefühl dafür zu bekommen, bei welchen Aktionen u.U. schnell ein großer Speicherverbrauch auftreten kann.

Letztlich hat das auch dazu geführt, dass ich unter Windows erstmals eine 64-Bit-Version eines Programm veröffentlicht habe, denn mit dem Wegfall der 2 GB Speichergrenze in der 64-Bit-Programmfassung kommt man in diesem Fall dann doch deutlich weiter... (wäre schön, wenn Delphi - das ja auch noch ein 32-Bit-Programm ist - da gleichfalls mal bald nachziehen würde...

)