Query DB a lunga esecuzione con scrittura simultanea allo stesso tempo [closed]

Stai essenzialmente chiedendo come vengono eseguiti i lock e quando. Questo sarà trattato nella documentazione per ogni implementazione del database.

Come esempio per PostgreSQL la lettura richiesta è:

link

In particolare vedrai che spetta al programmatore impostare i livelli di isolamento. Detto questo ci sono dei valori predefiniti come:

Read Committed is the default isolation level in PostgreSQL.

E poi continua a spiegarlo. La tabella spiega cosa può accadere a ciascun livello di isolamento.

Puoi anche utilizzare il blocco esplicito nella maggior parte degli RDMS:

link

Questo spiega l'impostazione predefinita anche almeno per la selezione:

ACCESS SHARE - The SELECT command acquires a lock of this mode on referenced tables. In general, any query that only reads a table and does not modify it will acquire this lock mode.

Se vuoi assicurarti di non leggere nulla aggiunto dopo l'inizio della query, puoi usare "ESCLUSIVO". Dalla tabella puoi vedere cosa significa.

This mode allows only concurrent ACCESS SHARE locks, i.e., only reads from the table can proceed in parallel with a transaction holding this lock mode.

Che può essere utile se il tuo problema lo richiede.

Riguardo a NoSQL ce ne sono così tanti. Non sono sicuro da dove cominciare, ma guardando l'articolo di wikipedia su NoSQL indica che alcuni non offrono nemmeno isolamento. (Oppure ACID ).

Nel linguaggio di RDBMS, stai parlando di Livelli di isolamento . Il modo in cui questi variano dipende dal RDBMS in questione (e anche dalla versione).

Forse lo scenario più semplice è Leggi promesso contro Lettura non inviata . Se si desidera leggere solo dati puliti, ad esempio quello che è stato impegnato nel database, il risultato può differire dai dati non salvati che potevano essere validi al momento ma che sono stati successivamente ripristinati. Una sottigliezza che viene persa su molti nuovi sviluppatori privi di database nous è che mentre le letture pulite restituiscono dati "corretti", le letture sporche possono essere più veloci poiché non devono attendere il completamento delle transazioni per completare l'immagine dei dati.

Se i dati spuri in realtà variano da caso a caso. Chiaramente, le applicazioni bancarie e finanziarie richiedono assolutamente dati precisi, mentre dire che tirare una divisione di genere da un grande data warehouse per un report di gestione richiederebbe forse un livello inferiore di accuratezza.

Per alcune attività, potresti desiderare che ci sia una visione coerente dei dati per la durata della tua operazione, nel qual caso, viene eseguita un'istantanea dei dati e la query funziona contro di essa fino a quando l'operazione non viene eseguita indipendentemente i record vengono aggiunti al successivo data vintage.

Oltre al tempo di interrogazione, c'è anche la considerazione di quanto velocemente vengono scritti nuovi record. Se nella tabella è presente un numero elevato di indici, i nuovi record verranno aggiunti ad un tasso inferiore rispetto a un numero basso di indici sulla tabella.

Ho esperienza del server ms-sql con segnalazione di query su un database (replica in tempo reale) che riceve centinaia di righe al secondo.

La risposta breve sarà sempre "dipende"; la risposta può essere qualsiasi tra 1000 e 1150 (o anche 990 a 1160 se si esegue "Leggi non inviato" come menzionato da Robbie Dee)

in sql server una scansione della tabella, per impostazione predefinita, blocca le pagine mentre legge, assicurando che il riutilizzo della stessa riga non dia una risposta inconsistente. Scrive che si verificano dopo aver avviato la query, ma che coinvolgono una riga / pagina di dati che non hai ancora letto sarà visibile a te.

La regolazione del livello di isolamento può cambiare in 2 modi:

1) con isolamento 'snapshot', non vedrai le scritture che sono richieste dopo aver avviato la query. (ciò che accade alla scrittura dipende dal fatto che si abbia un database di controllo delle versioni delle righe, come oracle o sql-server con l'isolamento dello snapshot abilitato)

2) quando usi un permissivo "permetti letture sporche" Leggi non inviato (o una tabella "con (nolock)"), allora ciò che accade non è definito. in particolare possono verificarsi 3 scenari extra durante la lettura di una pagina intera che sta per essere suddivisa:

a) sei alla fine di una pagina e la nuova pagina è più avanti della scansione della tabella; leggerai tutte le righe copiate nella nuova pagina due volte. (potenziale violazione della chiave primaria nei risultati restituiti, o se si tratta di un aggiornamento, la stessa riga ha restituito due volte con dati diversi.)

b) sei all'inizio della pagina e la nuova pagina è indietro rispetto alla scansione della tabella corrente; le righe che vengono spostate dalla pagina corrente a quella nuova non verranno lette, con il risultato che le righe corrispondenti non vengono restituite.

c) la tua query di lettura non è una scansione di tabella, ma utilizza un indice, che contiene ID di riga: la modifica nella riga ID causata dalla divisione della pagina può comportare la modifica della riga e risultati che non corrispondono alla query essere restituito.

nota: in SQL Server quasi tutte le modifiche (inclusa l'eliminazione di righe) possono causare una suddivisione della pagina.