SQLite con due processi python che accedono ad esso: una lettura, una scrittura

Question

SQLite con due processi python che accedono ad esso: una lettura, una scrittura

#1 da (23 voti)
#2 da (10 voti)

22

Sto sviluppando un piccolo sistema con due componenti: uno esegue il polling dei dati da una risorsa internet e lo traduce in dati sql per mantenerlo localmente; il secondo legge i dati SQL dall'istanza locale e li serve tramite json e una riposante API.

Inizialmente pensavo di mantenere i dati con postgresql, ma poiché l'applicazione avrà un volume molto basso di dati da archiviare e il traffico da servire, ho pensato che fosse eccessivo. SQLite è all'altezza del lavoro? Adoro l'idea del minimo ingombro e non c'è bisogno di mantenere un altro server sql per questo compito, ma sono preoccupato per la concorrenza.

Sembra che con la registrazione in anticipo, abilitata, la lettura e la scrittura simultanee di un database SQLite possano avvenire senza bloccare i processi fuori dal database.

Una singola istanza SQLite può supportare due processi simultanei che accedono ad essa, se solo una legge e l'altra scrive? Ho iniziato a scrivere il codice, ma mi chiedevo se si tratta di un'applicazione errata di SQLite.

sql web-development python concurrency sqlite

posta b.b. 08.10.2013 - 18:19

fonte

2 risposte

10

Volevo solo dare un seguito e far sapere a tutti che l'implementazione ha avuto successo. Lavorare con SQLite è stato un vero piacere, e con un solo processo di scrittura alla volta non abbiamo mai avuto problemi con il lock-up ... anche con letture concorrenti molto rapide da un processo secondario.

risposta data 31.10.2013 - 18:30

fonte

Leggi altre domande sui tag sql web-development python concurrency sqlite

Cosa costituisce "distribuzione" per LGPL v3 È legale riutilizzare il codice nei progetti di altri clienti?

score 23 · Accepted Answer

Stai cercando la documentazione per il blocco dei file e la concorrenza .

I processi SQLite utilizzano una serie di blocchi per gestire la concorrenza; per leggere, diversi processi possono ottenere un blocco SHARED .

Un processo che scrive, avrà bisogno di ottenere un blocco RESERVED , e solo quando in realtà devi scaricare le modifiche sul disco si sposta allo stato PENDING . Ogni processo di lettura dovrà quindi sbloccare il file, dopodiché il processo di scrittura sarà in grado di spostarsi a EXCLUSIVE per scrivere sul file di database effettivo.

Poiché il processo di scrittura richiede solo il blocco del file di database per le scritture effettive (svuotamento della memoria, commit), una configurazione con un solo lettore e solo uno scrittore funzionerà abbastanza bene. Mi aspetto che si esibisca altrettanto bene, se non addirittura meglio, come un setup con un solo processo che esegue tutte le operazioni di lettura e scrittura.

SQLite è meno adatto quando ci sono più processi che scrivono frequentemente nello stesso database, poiché la scrittura richiede l'ottenimento dell'esclusivo blocco PENDING per serializzare le modifiche.