In-Memory Datenbank -- Speicherdurchsatz?

[Socke]

Hallo zusammen,

Ich habe hier einige zusammenhängende SQL-Abfragen aus einer MS Access-Datenbank auf eine SQLite3-Datenbank umgestellt, damit ich den Festplattenzugriff von Access durch eine schnellere In-Memory-Datenbank aushebeln kann.

Bei der Ausführung der Abfrage habe ich aber nur eine konstante CPU-Auslastung von genau 17% durch SQLite. Selbst bei meinen 6 CPU-Kernen (à 2,8 GHz) ist kein einziger voll ausgelastet. Die Access-Datenbank rechnet an der gleichen Abfrage aber mehrere Tage herum.

Woran kann das liegen? Gibt es eine Möglichkeit, um festzustellen, ob an dieser Stelle der Speicherdurchsatz (RAM <-> Prozessor) limitiert und die CPU gar nicht stärker ausgelastet werden kann?

[marcov]

Keine Ahnung, aber: wenn Speicherdurchsatz limitiert, zeigt Taskmanager 100% cpu (ein voller Kern) an. Logisch, weil Taskmanager nur das % benutzte scheduling timeslices zaehlt. Es guckt nicht innerhalb der CPU.

Also was hier auch passiert, es ist nicht CPU<->speicher, aber et was anderes. Meist logisches ist da einfach blocking I/O.

[MmVisual]

Mit
"BEGIN EXCLUSIVE TRANSACTION"
"COMMIT TRANSACTION"
kann man SQLite dazu veranlassen dass erst mal alle Operationen im RAM durchgeführt werden und erst mit dem Commit wird die Datei wieder beschrieben. Somit benötigt es für eine umfangreiche Bearbeitung kein Festplattenzugriff.
Allerdings kann nur eine EXE / ein Task darauf zugreifen.

Oder war das jetzt die falsche Frage zu meiner Antwort?

[Socke]

kann man SQLite dazu veranlassen dass erst mal alle Operationen im RAM durchgeführt werden und erst mit dem Commit wird die Datei wieder beschrieben.

Ich arbeite mit der Datenbank :memory: und lade vor der Abfrage alle Daten hinein. Von daher habe ich hier keinen Festplattenzugriff durch sqlite.

Keine Ahnung, aber: wenn Speicherdurchsatz limitiert, zeigt Taskmanager 100% cpu (ein voller Kern) an. Logisch, weil Taskmanager nur das % benutzte scheduling timeslices zaehlt. Es guckt nicht innerhalb der CPU.

Also was hier auch passiert, es ist nicht CPU<->speicher, aber et was anderes. Meist logisches ist da einfach blocking I/O.

Wie gesagt, meine Datenbank liegt vollständig im RAM. Der Weg vom RAM in den Prozessor und Zurück wird üblicherweise nicht als I/O betrachtet.

Mein Ansatz ist jetzt viel eher: 17 % CPU-Auslastung x 6 Kerne = 102 % Gesamtauslastung. Hätte ich also 6 Threads, die meine CPU zu je 17 % Auslasten, wären auch alle Prozessorkerne voll ausgelastet. Da das nicht der Fall ist, schiebt das System wohl den einen Thread von sqlite von Prozessorkern zu Prozessorkern.

Mir hat sqlite3 gerade nach 30,5 Stunden etwas gesagt:

Error: near line 4: out of memory

Ich schätze mal nicht, dass ich in Zeile 4 einen SQL-Fehler habe; daher suche ich gerade nach einer 64-Bit Programmdatei.

[af0815]

Unter Windows: schon mal mit den Tools von Sysinternals (jetzt bei MS) probiert um ein wenig mehr Infos zu bekommen. Prozess Explorer und Prozess Monitor geben doch ein bischen Infos über die Prozesse.

Das Abfragen bei SQL etwas länger dauern können ist ja Ok, aber Stunden/Tage. Ich bin ja überhaupt nicht neugierig - aber was machst du mit der DB ?!

[Christian]

Probier es trotsdem mal in eine Transaktion zu packen, SQLite behandelt dann einiges anders auch bei in memory datasets. Ergebnis ist schon interessant. Auch wenn es keine Exklusive sein muss.

[MmVisual]

Wenn Du laufend irgend welche Locates machst und es sind viele 1000 Datensätze, dann wird das ganze auch im Memory sehr langsam.

Bei solchen Aktionen auf Locate verzichten, mache stattdessen lieber eine TStringList und suche darin nach dem String.
In der Stringliste wird mit AddObject der String sowie die Datensatz-Nummer gespeichert, somit geht das Suchen viel schneller.

Ich hatte neulich eine EXE umgebaut, wo die Einstellung der Sprache 15 Sekunden dauerte, nach diesem Umbau (auf TStringListe) dauert das ganze nur noch 1,5 Sekunden.

Die DB kannst Du beibehalten, nur nicht suchen mit Locate, sondern dafür etwas anderes erfinden.

[Socke]

Das Abfragen bei SQL etwas länger dauern können ist ja Ok, aber Stunden/Tage. Ich bin ja überhaupt nicht neugierig - aber was machst du mit der DB ?!

Im Allgemeinen analysiert die Datenbank Berechtigungsdaten aus einem SAP-System; Im Speziellen ist das hier jetzt eine Abfrage zur Funktionstrennung auf Benutzerebene.

Probier es trotsdem mal in eine Transaktion zu packen, SQLite behandelt dann einiges anders auch bei in memory datasets. Ergebnis ist schon interessant. Auch wenn es keine Exklusive sein muss.

Ich werde das vielleicht in den nächsten Tagen ausprobieren können. Mir sind da noch ein paar andere Termine dazuwischen gekommen.
Ursprünglich hatte ich vor, die verschiedenen Abfragen in einer Datenbank zu parallelisieren -- aber da kann man ja immer noch mit verschiedenen Datenbanken arbeiten.

Wenn Du laufend irgend welche Locates machst und es sind viele 1000 Datensätze, dann wird das ganze auch im Memory sehr langsam.

Locate?! Ich arbeite hier direkt mit SQL. Und zu der Datenmenge: ich rede hier von ca. 4,5 Millionen Datensätzen. Da ist das kein Wunder, dass das ganze ein paar Minuten braucht, und das man das nicht wirklich auf einem Produktivsystem machen möchte.

Auf der anderen Seite sagt mir SQLite etwas mit der Statistik:

Code: Alles auswählen

Fullscan Steps:                      3815
Sort Operations:                     0
Autoindex Inserts:                   4483211

Nämlich: Der einzige vorhanden Datenbankindex auf der Tabelle ist nicht ausreichend.

[MmVisual]

Ich denke, dass bei dieser Menge SQLite wohl nicht ganz das richtige ist, nehme besser MySQL oder PostgreSQL.

Ich hatte mal eine Datei-Datenbank beschrieben, in die ich alle Dateien (Name, Größe, Datum usw.) abgelegt hatte. Somit konnte ich meine CD Sammlung in der Datenbank durchsuchen und musste nicht mehr die CD's einlegen. über 1 Mio Datensätze mit Interbase / Delphi. Um da nach einem Text (Dateiname) mit LIKE zu suchen dauert auch ein paar Sekunden.

SQLite ist dafür etwas zu schwach.

[Socke]

Ich denke, dass bei dieser Menge SQLite wohl nicht ganz das richtige ist, nehme besser MySQL oder PostgreSQL.

SQLite hat den unschlagbaren Vorteil, dass ich die SQL-Statements aus MS Access ohne Änderungen übernehmen kann. MySQL kenne ich da zu wenig, aber ich meine mal etwas gelesen zu haben, dass man die bescheuerten Backticks (`abc`) auch durch die einfachen Anfürhungszeichenersatzzeichen ('abc') per Einstellung ersetzen könne. Jedenfalls benötige ich eine gangbare Möglichkeit die Abfragen ohne großen Aufwand umzustellen.

Ich hatte mal eine Datei-Datenbank beschrieben, in die ich alle Dateien (Name, Größe, Datum usw.) abgelegt hatte. Somit konnte ich meine CD Sammlung in der Datenbank durchsuchen und musste nicht mehr die CD's einlegen. über 1 Mio Datensätze mit Interbase / Delphi. Um da nach einem Text (Dateiname) mit LIKE zu suchen dauert auch ein paar Sekunden.

SQLite ist dafür etwas zu schwach.

Hast du hier einen Vergleich zwischen Interbase/Delphi und SQLite angestellt? SQLite unterstützt mittlerweile auch Volltextsuche (mit entsprechend vorher aufgebauten Indizes).

[MmVisual]

Nein, hab ich nicht. Damals hatte ich nur IB eingesetzt,ist schon einige Jahre her.

[Christian]

SQLite schlägt im Einzelnutzerbetrieb auch bei Datenmengen im GB Bereich die nicht Kommerziellen DB Systeme soweit ich das beobachtet hab alle. Vorrausgesetzt die Indizies sind vernünftig gesetzt.
Bei Mehrbenutzer wirds dann aber schnell langsam.

[MmVisual]

Da ist meine Erfahrung anders. Ich hatte mal vor einem Jahr ein Versuch unternommen und die Zeiten gemessen.
Die Randbedingungen des Versuchs hab ich allerdings vergessen

in jedem Fall waren MySQL und SQLite etwa gleich schnell, hingegen PostgreSQL fast doppelt so schnell.
Gleiche EXE, gleicher Quellcode, mit ZEOS Komponente die Datenbank umgestellt, gleiche Datenmenge.

MySQL / PostgreSQL sollten auf einem Mehrkernsystem schneller sein, da dies echte Server sind und die können die Kerne ausnutzen. Hingegen die SQLite DLL läuft im gleichen Thread/Kern und ist somit gebunden.
Folge>> 6 Kerne, nur einer zu 100% belastet = 16,66% Gesamt CPU Auslastung.

Bei MySQL kann man auch sehr gut die Berechnungen dem Server überlassen, was die eigene EXE wiederum beschleunigen sollte.

Bei MySQL kann man auch problemlos 2 PC's nutzen, der eine mit der Datenbank, der zweite mit der EXE, was unter Umständen nochmals ein Geschwindigkeitsschub bringt (je nach dem wie viele Daten tatsächlich vom Server geladen werden).

Bei meinem EleLa merke ich von der Geschwindigkeit her kein Unterschied, weder Lokal noch über Netzwerk (MySQL), allerdings sind da jetzt auch keine Mio Datensätze drin.

[Socke]

Bei MySQL kann man auch sehr gut die Berechnungen dem Server überlassen, was die eigene EXE wiederum beschleunigen sollte.

Meine Programm/Script/Was-weiß-ich soll dann auch nur soetwas wie ein SQL-Loader werden, der die Datenbank dazu animiert bestimmte SQL-Dateien auszuführen. Von daher liegt eine Beschleunigung der Exe-Datei zwischen nicht möglich und nicht nötig.

MySQL / PostgreSQL sollten auf einem Mehrkernsystem schneller sein, da dies echte Server sind und die können die Kerne ausnutzen. Hingegen die SQLite DLL läuft im gleichen Thread/Kern und ist somit gebunden.
Folge>> 6 Kerne, nur einer zu 100% belastet = 16,66% Gesamt CPU Auslastung.

Für SQLite ist es ja kein Problem, mehrere Threads zu starten, die verschiedene Auswertungen durchführen. Bei den Server-RDBMS brauche ich eine Dokumentation, ob eine Abfrage automatisch oder nach Konfiguration parallelisiert wird bzw. werden kann; ansonsten gilt immer noch:

SQLite hat den unschlagbaren Vorteil, dass ich die SQL-Statements aus MS Access ohne Änderungen übernehmen kann. MySQL kenne ich da zu wenig, aber ich meine mal etwas gelesen zu haben, dass man die bescheuerten Backticks (`abc`) auch durch die einfachen Anfürhungszeichenersatzzeichen ('abc') per Einstellung ersetzen könne. Jedenfalls benötige ich eine gangbare Möglichkeit die Abfragen ohne großen Aufwand umzustellen.

[marcov]

Mein Ansatz ist jetzt viel eher: 17 % CPU-Auslastung x 6 Kerne = 102 % Gesamtauslastung. Hätte ich also 6 Threads, die meine CPU zu je 17 % Auslasten, wären auch alle Prozessorkerne voll ausgelastet. Da das nicht der Fall ist, schiebt das System wohl den einen Thread von sqlite von Prozessorkern zu Prozessorkern.

Das hört sich an als eine einfache single threaded Application. Der nutzt nur ein Kern, aber Windows schiebt sie regelmäßig von core nach core um Thermische Grunde

Also ganz normal.

Mir hat sqlite3 gerade nach 30,5 Stunden etwas gesagt:

Error: near line 4: out of memory

Ich schätze mal nicht, dass ich in Zeile 4 einen SQL-Fehler habe; daher suche ich gerade nach einer 64-Bit Programmdatei.

Hört sich mehr an als ein Programmierfehler. E.g. ein pro query alloziertes Object (object von SQLite, nicht Lazarus) das nicht richtig freigegeben wird. zb transaction context oder so.