it-swarm.com.de

SQLite mit zwei python-Prozessen, die darauf zugreifen: ein Lesen, ein Schreiben

Ich entwickle ein kleines System mit zwei Komponenten: Eine fragt Daten von einer Internetressource ab und übersetzt sie in SQL-Daten, um sie lokal zu speichern. Der zweite liest diese SQL-Daten aus der lokalen Instanz und stellt sie über JSON und eine erholsame API bereit.

Ich hatte ursprünglich geplant, die Daten mit postgresql beizubehalten, aber da die Anwendung nur über ein sehr geringes Datenvolumen zum Speichern und zum Bereitstellen des Datenverkehrs verfügt, hielt ich das für übertrieben. Ist SQLite dem Job gewachsen? Ich mag die Idee des geringen Platzbedarfs und der Notwendigkeit, für diese eine Aufgabe keinen weiteren SQL-Server zu warten, aber ich bin besorgt über die Parallelität.

Es scheint, dass bei aktivierter Write-Ahead-Protokollierung das gleichzeitige Lesen und Schreiben einer SQLite-Datenbank erfolgen kann, ohne dass ein Prozess aus der Datenbank gesperrt wird.

Kann eine einzelne SQLite-Instanz zwei gleichzeitige Prozesse unterstützen, die darauf zugreifen, wenn nur eine liest und die andere schreibt? Ich habe angefangen, den Code zu schreiben, habe mich aber gefragt, ob dies eine falsche Anwendung von SQLite ist.

22
b.b.

Sie suchen nach der Dokumentation File Locking And Concurrency .

SQLite-Prozesse verwenden eine Reihe von Sperren, um die Parallelität zu verarbeiten. Zum Lesen können mehrere Prozesse eine SHARED -Sperre erhalten.

Ein Prozess, der schreibt, muss eine RESERVED -Sperre erhalten, und nur wenn tatsächlich Änderungen auf der Festplatte gelöscht werden müssen, wird er in den Status PENDING versetzt. Jeder Lesevorgang muss dann die Datei entsperren. Danach kann der Schreibvorgang zum Schreiben in die eigentliche Datenbankdatei nach EXCLUSIVE verschoben werden.

Da der Writer-Prozess nur die Datenbankdatei für tatsächliche Schreibvorgänge (Speicherbereinigungen, Commits) sperren muss, funktioniert ein Setup mit nur einem Reader und nur einem Writer recht gut. Ich würde erwarten, dass es genauso gut, wenn nicht sogar besser funktioniert als ein Setup mit nur einem Prozess, der das Lesen und Schreiben übernimmt.

SQLite ist weniger geeignet, wenn mehrere Prozesse häufig in dieselbe Datenbank schreiben, da für das Schreiben die exklusive Sperre PENDING erforderlich ist, um Änderungen zu serialisieren.

25
Martijn Pieters

Ich wollte nur nachverfolgen und alle wissen lassen, dass die Implementierung erfolgreich war. Die Arbeit mit SQLite war eine wahre Freude, und mit jeweils nur einem Prozess hatten wir nie Probleme mit der Sperrung ... selbst bei sehr schnellen gleichzeitigen Lesevorgängen aus einem sekundären Prozess.

10
b.b.