marcov hat geschrieben: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.
af0815 hat geschrieben:Socke hat geschrieben: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.
sqlite3_3.7.10-x64_86.zip
Verein
Links
