Perché il blocco ottimistico è più veloce del blocco pessimistico?

Entrambe le forme di blocco fanno sì che un processo attenda una copia corretta del record se è attualmente in uso da un altro processo. Con il blocco pessimistico, il meccanismo di blocco proviene dal DB stesso (un oggetto di blocco nativo), mentre con il blocco ottimistico, il meccanismo di blocco è una forma di controllo delle righe come un timestamp per verificare se un record è "stantio" o meno.

Ma entrambi causano il blocco di un secondo processo. Quindi chiedo: perché il blocco ottimistico è generalmente considerato più veloce / superiore rispetto al blocco pessimistico? E ci sono casi d'uso in cui il pessimista è preferito all'ottimista? Grazie in anticipo!

Domanda duplicata da:

/programming/129329/optimistic-vs-pessimistic-locking

Copia / incolla risposta dal link sopra:

Il blocco ottimistico è una strategia in cui leggi un record, prendi nota di un numero di versione e verifica che la versione non sia cambiata prima di riscrivere il record. Quando si riscrive il record, si filtra l'aggiornamento sulla versione per assicurarsi che sia atomico. (ovvero non è stato aggiornato tra quando si controlla la versione e si scrive il record sul disco) e si aggiorna la versione in un colpo solo.

Se il record è sporco (ovvero versione diversa dalla tua), interrompi la transazione e l'utente può riavviarla.

Questa strategia è maggiormente applicabile ai sistemi ad alto volume e alle architetture a tre livelli in cui non si mantiene necessariamente una connessione al database per la sessione. In questa situazione il client non può effettivamente mantenere i blocchi del database poiché le connessioni vengono prese da un pool e potresti non utilizzare la stessa connessione da un accesso al successivo.

Il blocco pessimistico è quando si blocca il record per uso esclusivo fino a quando non si è finito con esso. Ha un'integrità molto migliore rispetto al blocco ottimistico, ma richiede di stare attenti con il design dell'applicazione per evitare deadlock. Per utilizzare il blocco pessimistico è necessaria una connessione diretta al database (come in genere accade in un'applicazione server client a due livelli) o un ID transazione disponibile esternamente che può essere utilizzato indipendentemente dalla connessione.

In quest'ultimo caso, si apre la transazione con il TxID e quindi si riconnette utilizzando tale ID. Il DBMS mantiene i blocchi e consente di riprendere il backup della sessione tramite TxID. Ecco come funzionano le transazioni distribuite che utilizzano protocolli di commit a due fasi (come Transazioni XA o COM +).

Modifica (aggiunta di ulteriori informazioni per rispondere alla domanda di rendimento):

Le prestazioni dipendono dal tuo ambiente. Prendi in considerazione i seguenti fattori per decidere:

troverai ottimista sarà migliore a causa della concorrenza nella maggior parte delle situazioni. A seconda del RDBMS e dell'ambiente, tuttavia, potrebbe essere meno o più performante. In genere con il blocco Optimistic scoprirai che il valore deve essere modificato in una riga da qualche parte.

Con MS SQL Server, ad esempio, viene spostato in TempDB e alla fine della colonna viene aggiunto qualcosa tra 12-14 byte. L'attivazione del blocco ottimistico con un livello di isolamento come Isolamento istantanea può causare frammentazione e il tuo fattore di riempimento dovrà essere regolato poiché le righe ora hanno dati aggiuntivi alla fine che potrebbero causare una pagina quasi piena per causare una divisione della pagina, che si abbasserà la tua prestazione. Se il tuo TempDB è sotto ottimizzato, non sarà così veloce.

Quindi immagino che una checklist sia:

• -Hai abbastanza IO / risorse per gestire la forma del versioning delle righe? In caso contrario, stai aggiungendo un sovraccarico. In tal caso, se stai leggendo spesso i dati mentre li stai spesso bloccando per le scritture, noterai un buon miglioramento della concorrenza tra letture e scritture (sebbene le scritture blocchino ancora le scritture, le letture non bloccheranno più le scritture e viceversa)
• -Il tuo codice è suscettibile a deadlock o si verifica il blocco? Se non si verificano lunghi blocchi o molti deadlock, l'overhead aggiuntivo del blocco Optimistic non renderebbe le cose più veloci, ovviamente, nella maggior parte dei casi qui stiamo parlando di millisecondi.
• -Se il tuo DB è grande (o su hardware molto limitato) e le tue pagine di dati sono quasi piene, a seconda del RDBMS, potresti causare spaccature di pagina importanti e frammentazione dei dati, quindi assicurati di prendere in considerazione la reindicizzazione dopo averlo acceso.

Questi sono i miei pensieri in merito, aperti ad ascoltare di più dalla comunità.

Si fraintende il blocco ottimistico.

Il blocco ottimistico non causa l'attesa reciproca delle transazioni.

Il blocco ottimistico può causare il fallimento di una transazione, ma lo fa senza che sia mai stato eseguito alcun "blocco". E se una transazione fallisce a causa del blocco ottimistico, l'utente deve ricominciare tutto da capo. La parola "ottimista" deriva esattamente dall'aspettativa che la condizione che causa il fallimento delle transazioni proprio per questo motivo, si verifichi solo in modo molto eccezionale. Il blocco "ottimistico" è l'approccio che dice "Non prenderò blocchi reali perché spero che non saranno necessari comunque. Se si scopre che mi sbagliavo, accetterò l'inevitabile fallimento".

Il blocco ottimistico è generalmente più veloce perché in realtà non esiste alcun blocco dal punto di vista del database. Dipende interamente dall'applicazione se rispettare la colonna della versione (o pseudo-colonna, come ora_rowscn) o meno. Normalmente hai molte applicazioni connesse allo stesso database, quindi db diventa una risorsa condivisa e, se si blocca, tutti i client saranno interessati.

Con una strategia di blocco ottimista, il "blocco" si verifica sul lato client e non influisce sugli altri.

Tuttavia, se un record viene aggiornato frequentemente, potresti finire per rileggerlo troppe volte (in caso di blocco ottimistico), vanificando così i maggiori vantaggi della strategia ottimistica.

Non sarei d'accordo sulla superiorità di nessuno dei due approcci; entrambi possono essere usati in modo improprio. Il pessimistico è più soggetto a errori solo perché è più pericoloso: il blocco si verifica a livello di db, dipende da RDMS che potresti non avere il controllo su ciò che è bloccato (blocco dell'escalation), devi occuparti manualmente dell'ordine di blocco.

Il blocco ottimistico presuppone che le transazioni simultanee possano essere completate senza influire reciprocamente. Quindi il blocco ottimistico è più veloce perché non vengono applicati blocchi durante le transazioni. È la prevenzione da causare problemi di concorrenza non curare. La transazione verifica solo (set di dati in tre modi, tipo di data / ora, Verifica valore vecchio e nuovo) i dati che nessun'altra transazione ha modificato i dati. In caso di modifica, la transazione viene ripristinata.

Il blocco pessimistico presuppone che le transazioni simultanee entrino in conflitto tra loro, quindi richiede il blocco, viene fatto specificando il livello ISOLATION (Leggi non confermato, Leggi impegnato, Lettura ripetibile e serializzabile) della gestione delle transazioni. Cura i problemi di concorrenza acquisendo il blocco. i blocchi servono a proteggere risorse o oggetti condivisi (tabelle, righe di dati, blocchi di dati, elementi memorizzati nella cache, connessioni e interi sistemi). Sono disponibili molti tipi di blocchi come blocchi condivisi, blocco aggiornamenti, blocco inserto, blocchi esclusivi, blocchi delle transazioni, blocchi DML, blocchi dello schema e blocchi di backup-ripristino.

per avere più idea

È falso dire che il blocco pessimistico è più lento piuttosto che ottimistico o dire che l'ottimismo è più veloce. Una query classica per dimostrare questo modo di pensare non appropriato è fare un aggregato sui diversi RDBMS, come:

SELECT COUNT(*) FROM atable

Vedrai che, nel RDBMS che supporta l'approccio nativamente ottimistico, il tempo impiegato da questa query è molto più significativo di quelli che hanno un blocco nativamente pessimistico

Ad esempio sul mio PC, la stessa query richiede 27 ms su SQL Server e 109 su PostGreSQL ...

Il sovraccarico extra necessario per leggere le versioni morte delle righe MVCC e non contare i record dei fantasmi nell'aggregato aggiunge un costo extra che il pessimista non ha!