In-Memory Datenbank -- Speicherdurchsatz?

[af0815]

Für SQLite ist es ja kein Problem, mehrere Threads zu starten, die verschiedene Auswertungen durchführen.

Mehrere threads aus der Sicht der DB sind mehrer Verbindungen/Benutzer. Da würde ich vorsichtig sein. Das kann durch das locking von Sqllite nach hinten losgehen.

[Socke]

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.

Ich glaube einfach, dass die SQLite3.exe für Win32 nicht mit mehr als 2 GB RAM umgehen kann. Es werden nämlich maximal 3 Queries ausgeführt. Lazarus/Free Pascal habe ich in meinen Tests bisher noch gar nicht verwendet.

Für SQLite ist es ja kein Problem, mehrere Threads zu starten, die verschiedene Auswertungen durchführen.

Mehrere threads aus der Sicht der DB sind mehrer Verbindungen/Benutzer. Da würde ich vorsichtig sein. Das kann durch das locking von Sqllite nach hinten losgehen.

SQLite sperrt immer die gesamte Datenbank-Datei, wenn Daten geschrieben werden. Das ist bei mir aber eher ein geringes Problem, da die Sachlage wie folgt aussieht:

• Es gibt eine Ausgangsdatenmenge; diese verändert sich nicht
• Es gibt verschiedene SQL-Abfragen
• Die SQL-Abfragen bauen teilweise aufeinander auf
  • Die Unterabfragen können in SQLite bequem als View bzw. als berechnete Tabelle erstellt werden
  • Tabelle oder View hängt von der Anzahl der darauf aufbauenden Abfragen ab
• Es gibt also voneinander unabhängige Abhängigkeitsgraphen

Die Abhängigkeitsgraphen können dann in verschiedenen Threads ausgeführt werden; die Datenbanken werden zur Beschleunigung in den Arbeitsspeicher geladen. Verschiedene Auswertungspfade erhalten verschiedene Datenbank-Dateien zur Speicherung der (Zwischen-)Ergebnisse.

Die Dokumentation zum locking spricht immer von Datenbank-Dateien. Daher gehe ich davon aus, dass ich die Ausgangsdaten bzw. Zwischenergebnisse überall gleichzeitig einbinden kann, da diese nur gelesen werden.

[af0815]

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.

Ich glaube einfach, dass die SQLite3.exe für Win32 nicht mit mehr als 2 GB RAM umgehen kann. Es werden nämlich maximal 3 Queries ausgeführt. Lazarus/Free Pascal habe ich in meinen Tests bisher noch gar nicht verwendet.

Hier Memory Limits for Windows Releases die Infos von MS zu den Speicherlimits.

[Socke]

Hier Memory Limits for Windows Releases die Infos von MS zu den Speicherlimits.

Dass Windows (hier: Windows 7, 64 bit) meine 8 GB RAM ansprechen kann und darf, weiß ich; Neben diesem Limit gibt es aber noch die Begrenzung durch 32-Bit-Programmdateien, die auch unter Windows-64-Bit maximal 4 GB Speicher verarbeiten können. Bei diesen muss aber noch ein Flag in der Programmdatei gesetzt sein, damit Windows diesen auch wirklich bis zu 4 GB RAM zuweist; ansonsten ist schon bei 2 GB Schluss (das kommt davon, wenn man Zeiger in vorzeichenbehafteten Typen speichert und das höchstwertige Bit nicht verwendet).

Daher habe ich mir gerade SQLite3 für Windows 64 Bit gebaut. Damit werde ich als nächstes testen, wie viel Arbeitsspeicher nach 31 Stunden belegt sind
Im Anhang findet ihr SQLite3 Version 3.7.10 für Windwox x64_86 (Win64). -- Für alle, die danach suchen. Lizenz lasse ich bei Public Domain; Gewährleistungen sind bis auf das absolute gesetzliche Minimum ausgeschlossen. Im Zweifelsfall bitte selber bauen.

[Socke]

Daher habe ich mir gerade SQLite3 für Windows 64 Bit gebaut. Damit werde ich als nächstes testen, wie viel Arbeitsspeicher nach 31 Stunden belegt sind

Test abgeschlossen: bei 2 GB war wieder Schluss. Jetzt lasse ich das ganze mal mit einer Datei-Datenbank arbeiten.

[Edit]
Test Abgeschlossen. Die Berechnung war nach etwa 32 Stunden fertig -- also nicht wesentlich mehr als in-memory. Tatsächlich war es auch kein Problem, die fertige Datenbank wieder komplett in den Speicher zu laden.

Immerhin habe ich mit den Statistiken (Fullscan und Autoindex) ein Argument, warum die bisherige Datenbank technologische Schwächen hat.
[/Edit]

Ich habe da auch noch einen interessanten Link gefunden, wie sich SQLite bei großen Datenbankdateien verhält: http://stackoverflow.com/questions/7841 ... abase-file" onclick="window.open(this.href);return false;