Perché le scritture simultanee non sono consentite su un database SQLite?

Sto programmando un database usando Java con SQLite.

Ho scoperto che solo una connessione alla volta al database ha capacità di scrittura, mentre molte connessioni contemporaneamente hanno capacità di lettura.

Perché l'architettura di SQLite è stata progettata in questo modo? Fintanto che le due cose che vengono scritte non vengono scritte nello stesso posto nel database, perché non possono avvenire due scritture contemporaneamente?

database concurrency sqlite

— Steeltoe
fonte

correlati (forse un duplicato): SQLite con due processi Python accedendo ad esso: una lettura, una scrittura

— moscerino

Perché SQLite è stato progettato per essere "lite". Bassa memoria e bassa elaborazione con prestazioni. Pensa a come farai in modo che SQLite gestisca più scritture nello stesso file. Il design attuale è facile da implementare: l'intero file è bloccato e gli altri devono aspettare. Per gestire la concorrenza in scrittura a un livello di granularità inferiore, è necessario il blocco di righe / pagine ottenuto dai RDMS. Se il requisito richiede la scrittura di concorrenza, allora SQLite non è un candidato e, invece, dovresti cercare un RDBMS leggero: en.wikipedia.org/wiki/…

— Thomas Carlisle,

Risposte:

157

Perché "più scritture simultanee" è molto, molto più difficile da realizzare nel motore di database di base rispetto al singolo autore, al lettore multiplo. È al di là dei parametri di progettazione di SQLite e includerlo probabilmente sovvertirebbe le dimensioni e la semplicità deliziosamente piccole di SQLite.

Supportare alti livelli di concorrenza in scrittura è un segno distintivo di motori di database di grandi dimensioni come DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL e Sybase. Ma è tecnicamente difficile da realizzare, che richiede un ampio controllo della concorrenza e strategie di ottimizzazione come il database, la tabella e il blocco delle righe o, nelle implementazioni più moderne, il controllo della concorrenza multi-versione . La ricerca su questo problema / requisito è voluminosa e risale a decenni fa .

SQLite ha una filosofia di progettazione molto diversa dalla maggior parte di quei DBMS incentrati sul server che supportano più writer. È progettato per offrire la potenza di SQL e del modello relazionale alle singole applicazioni e per essere integrabile all'interno di ciascuna applicazione. Tale obiettivo richiede significativi compromessi. Non aggiungere l'infrastruttura significativa e le spese generali necessarie per gestire più scrittori simultanei è uno di questi.

La filosofia può essere riassunta da un'istruzione nella pagina degli usi appropriati di SQLite :

SQLite non compete con i database client / server. SQLite compete con fopen ().

— Jonathan Eunice
fonte

+1. SQLite è un database in-process. Non esiste un arbitro centrale come in un DB basato su server. Gli scrittori dovrebbero cooperare e fidarsi direttamente l'uno dell'altro. Un singolo scrittore malintenzionato potrebbe provocare il caos non collaborando.

— Jörg W Mittag,

Inoltre, alcuni degli ambienti in cui viene eseguita SQLite potrebbero non supportare più processi.

— david25272,

Presumibilmente una scrittura malevola può già provocare il caos non cooperando. Non possono usare il codice SQLite per farlo, ma possono avere il proprio codice, che potrebbe essere solo una chiamata a unlink ()

— bdsl

Nelle app simultanee, non c'è molta via di mezzo. O ottieni la concorrenza, la coerenza e l'integrità dei dati praticamente nel 100% delle volte, anche in condizioni difficili e casi limite, oppure no. In caso contrario, è fragile, lento e soggetto a crash e le persone smettono di fidarsi molto rapidamente. Ma ottenerlo regolarmente è diabolicamente difficile. Non ci sono molte circostanze in cui gli scrittori possono, assenti una gran quantità di supporto di base, coordinare le scritture interlacciate da sole.

— Jonathan Eunice,

@bdsl I database di qualsiasi tipo devono presumere che gli scrittori non si comportino bene, quindi non perdono i dati. Gli autori di SQLite lo posizionano come un concorrente fopen(), quindi considera tutta la pelosità che deriva dalla scrittura simultanea in un semplice file di testo.

— Blrfl,

Perché non esiste un server in grado di dire se le cose devono essere scritte nello stesso posto o meno. Esistono solo due processi che provano a scrivere su un file.

Come sottolineato in un commento, le scritture simultanee potrebbero anche essere supportate da un thread interno. Non sono sicuro di come funzionerebbe (non ci ha pensato molto). Comunque qui è perché SQLite non usa i thread: il dott. Hipp pensa che i thread siano cattivi.

Il fatto che DR Hipp pensi che i thread siano cattivi è documentato nelle FAQ di SQLite .

— Goyo
fonte

Questo spiega il motivo tecnico per cui non sono consentite scritture simultanee, ma non perché è stata presa la decisione di progettazione.

— Robert Harvey,

La decisione di progettare SQLite in modo che gestisca solo una scrittura alla volta.

— Robert Harvey,

@Goyo non è necessario un server per gestire le scritture simultanee: per quanto un server di database sia un processo separato, potrebbe esserci un thread separato interno a SQLite che ha lo stesso scopo. Robert Harvey ha ragione: c'è stata una decisione di progettazione presa dal team SQLite e non ha nulla a che fare con la capacità di una singola libreria di gestire scritture simultanee (perché in teoria può farlo).

Questa risposta mi sembra soddisfacente. Per gestire le scritture simultanee, sembra che si debba avere un server o un'implementazione sqlite multi-thread. Poiché entrambi sono stati esclusi da altre decisioni di progettazione, l'implementazione di scritture simultanee sarebbe estremamente difficile.

— jpa,

@jpa: SQLite riesce a sincronizzare il blocco tra più processi / thread senza un "server" già. Non è necessario un "server", che utilizza il blocco / sincronizzazione / IPC / OS forniti dal sistema operativo / qualunque cosa sia sufficiente, ma diventa complessa molto velocemente. Il "thread interno" menzionato nel post non ha senso.

— Mat