Modello di concorrenza Amazon QLDB

Amazon QLDB è una valida scelta per i carichi di transazioni online (OLTP) ad alte prestazioni QLDB. QLDB supporta funzionalità di query di tipo SQL e fornisce transazioni ACID complete. Inoltre, gli elementi di dati QLDB sono documenti che offrono flessibilità dello schema e una modellazione intuitiva dei dati. Con un diario come base, puoi utilizzare QLDB per accedere alla cronologia completa e verificabile di tutte le modifiche ai tuoi dati e trasmettere transazioni coerenti ad altri servizi di dati, se necessario.

Controllo ottimistico della concorrenza

In QLDB, il controllo della concorrenza viene implementato utilizzando il controllo della concorrenza ottimistica (OCC). L'OCC opera secondo il principio che più transazioni possono spesso essere completate senza interferire l'una con l'altra.

Utilizzando OCC, le transazioni in QLDB non acquisiscono blocchi sulle risorse del database e funzionano con un isolamento serializzabile completo. QLDB esegue transazioni simultanee in modo seriale, in modo tale da produrre lo stesso effetto come se tali transazioni fossero avviate in serie.

Prima di eseguire il commit, ogni transazione esegue un controllo di convalida per garantire che nessun'altra transazione confermata abbia modificato i dati a cui accede. Se questo controllo rivela modifiche in conflitto o lo stato dei dati cambia, la transazione di conferma viene rifiutata. Tuttavia, la transazione può essere riavviata.

Quando una transazione scrive su QLDB, i controlli di convalida del modello OCC vengono implementati da QLDB stesso. Se una transazione non può essere scritta nel journal a causa di un errore nella fase di verifica di OCC, QLDB restituisce anOccConflictException al livello dell'applicazione. Il software applicativo è responsabile del riavvio della transazione. L'applicazione deve interrompere la transazione rifiutata e quindi riprovare l'intera transazione dall'inizio.

Per informazioni su come il driver QLDB gestisce e riprova i conflitti OCC e altre eccezioni transitorie, vedereInformazioni sulla politica di riprova con il driver in Amazon QLDB.

Utilizzo degli indici per evitare la scansione completa delle tabelle

In QLDB, ogni istruzione PartiQL (inclusa ogniSELECT query) viene elaborata in una transazione ed è soggetta a un limite di timeout della transazione.

Come procedura consigliata, è consigliabile eseguire istruzioni con una clausolaWHERE predicativa che filtra in base a un campo indicizzato o all'ID di un documento. QLDB richiede un operatore di uguaglianza su un campo indicizzato per cercare in modo efficiente un documento; ad esempio,WHERE indexedField = 123 oWHERE indexedField IN (456, 789).

Senza questa ricerca indicizzata, QLDB deve eseguire una scansione completa della tabella durante la lettura dei documenti. Ciò può causare latenza delle query e timeout delle transazioni e aumentare anche le possibilità di un conflitto OCC con transazioni concorrenti.

Ad esempio, considera una tabella denominataVehicle che ha un indice solo nelVIN campo. Contiene i seguenti documenti.

VIN	Make	Modello	Colore
"1N4AL11D75C109151"	"Audi"	"A5"	"Silver"
"KM8SRDHF6EU074761"	"Tesla"	"Model S"	"Blue"
"3HGGK5G53FM761765"	"Ducati"	"Monster 1200"	"Yellow"
"1HVBBAANXWH544237"	"Ford"	"F 150"	"Black"
"1C4RJFAG0FC625797"	"Mercedes"	"CLK 350"	"White"

Due utenti simultanei di nome Alice e Bob stanno lavorando con la stessa tabella in un libro mastro. Vogliono aggiornare due documenti diversi, come segue.

Alice:

UPDATE Vehicle AS v
SET v.Color = 'Blue'
WHERE v.VIN = '1N4AL11D75C109151'

Bob:

UPDATE Vehicle AS v
SET v.Color = 'Red'
WHERE v.Make = 'Tesla' AND v.Model = 'Model S'

Supponiamo che Alice e Bob inizino le loro transazioni contemporaneamente. LaUPDATE dichiarazione di Alice esegue una ricerca indicizzata sulVIN campo, quindi deve leggere solo quel documento. Alice termina e porta a termine con successo la sua transazione per prima.

L'istruzione di Bob filtra i campi non indicizzati, quindi esegue una scansione della tabella e incontra unOccConflictException. Questo perché la transazione effettuata da Alice ha modificato i dati a cui accede la dichiarazione di Bob, che includono tutti i documenti della tabella, non solo il documento che Bob sta aggiornando.

Conflitti di inserimento OCC

I conflitti OCC possono includere documenti appena inseriti, non solo documenti che esistevano in precedenza. Si consideri il diagramma seguente, in cui due utenti in contemporanea (Alice e Bob) stanno lavorando con la stessa tabella in un registro. Entrambi vogliono inserire un nuovo documento solo a condizione che non esista ancora un valore predicato.

In questo esempio, sia Alice che Bob eseguono le seguentiINSERT istruzioniSELECT e all'interno di una singola transazione. La loro applicazione esegue l'INSERTistruzione solo se l'SELECTistruzione non restituisce risultati.

SELECT * FROM Vehicle v WHERE v.VIN = 'ABCDE12345EXAMPLE'

INSERT INTO Vehicle VALUE
{
    'VIN' : 'ABCDE12345EXAMPLE',
    'Type' : 'Wagon',
    'Year' : 2019,
    'Make' : 'Subaru',
    'Model' : 'Outback',
    'Color' : 'Gray'
}

Supponiamo che Alice e Bob inizino le loro transazioni contemporaneamente. Entrambe le loroSELECT domande non restituiscono alcun documento esistente con unVIN diABCDE12345EXAMPLE. Quindi, le loro candidature procedono con laINSERT dichiarazione.

Alice termina e porta a termine con successo la sua transazione per prima. Quindi, Bob prova a confermare la sua transazione, ma QLDB la rifiuta e lancia unOccConflictException. Questo perché la transazione confermata da Alice ha modificato il set di risultati dellaSELECT query di Bob e OCC rileva questo conflitto prima di confermare la transazione di Bob.

L'SELECTinterrogazione è necessaria affinché questo esempio di transazione sia idempotente. Bob può quindi riprovare l'intera transazione dall'inizio. Ma la sua prossimaSELECT interrogazione restituirà il documento inserito da Alice, quindi l'applicazione di Bob non eseguirà ilINSERT.

Rendere le transazioni idempotenti

La transazione di inserimento nella sezione precedente è anche un esempio di transazione idempotente. In altre parole, eseguire la stessa transazione più volte produce risultati identici. Se Bob esegue il fileINSERT senza prima verificare se un particolare esisteVIN già, la tabella potrebbe finire con documenti conVIN valori duplicati.

Prendi in considerazione altri scenari di nuovo tentativo oltre ai conflitti OCC. Ad esempio, è possibile che QLDB esegua correttamente una transazione sul lato server, ma il client scada in attesa di una risposta. Come buona prassi, rendi le tue transazioni di scrittura idempotenti per evitare effetti collaterali imprevisti in caso di concorrenza o nuovi tentativi.

Conflitti OCC di redazione

QLDB impedisce le redazioni simultanee delle revisioni sullo stesso blocco del diario. Consideriamo un esempio in cui due utenti simultanei (Alice e Bob) desiderano redigere due diverse revisioni di documenti che vengono salvate sullo stesso blocco di un libro mastro. Innanzitutto, Alice richiede la redazione di una revisione eseguendo la proceduraREDACT_REVISION memorizzata, come segue.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'

Quindi, mentre la richiesta di Alice è ancora in elaborazione, Bob richiede la redazione di un'altra revisione, come segue.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '8F0TPCmdNQ6JTRpiLj2TmW', '05K8zpGYWynDlEOK5afDRc'

QLDB respinge la richiesta di Bob con unOccConflictException anche se stanno cercando di oscurare due diverse revisioni del documento. Questo perché la revisione di Bob si trova nello stesso blocco della revisione che Alice sta oscurando. Al termine dell'elaborazione della richiesta di Alice, Bob può quindi riprovare la sua richiesta di redazione.

Allo stesso modo, se due transazioni simultanee tentano di oscurare la stessa revisione, può essere elaborata una sola richiesta. L'altra richiesta fallisce con un'eccezione di conflitto OCC fino al completamento della redazione. In seguito, qualsiasi richiesta di rimozione della stessa revisione genererà un errore che indica che la revisione è già stata redatta.

Gestione delle sessioni concorrenti

Se hai esperienza nell'uso di un sistema di gestione di database relazionali (RDBMS, Relational Database Management System), potresti avere una valida scelta per i limiti di connessioni simultanee. QLDB non ha lo stesso concetto di connessione RDBMS tradizionale perché le transazioni vengono eseguite con messaggi di richiesta e risposta HTTP.

In QLDB, il concetto analogo è una sessione attiva. Una sessione è concettualmente simile all'accesso di un utente: gestisce le informazioni sulle richieste di transazione di dati su un libro mastro. Una sessione attiva è una sessione che esegue attivamente una transazione. Può anche trattarsi di una sessione che ha recentemente terminato una transazione in cui il servizio prevede che ne avvierà immediatamente un'altra. QLDB supporta una transazione in esecuzione attiva per sessione.

Il limite di sessioni attive simultanee per registro è definito inQuote e limiti in Amazon QLDB. Una volta raggiunto questo limite, qualsiasi sessione che tenti di avviare una transazione genererà un errore (LimitExceededException).

Per informazioni sul ciclo di vita di una sessione e su come il driver QLDB gestisce le sessioni durante l'esecuzione di transazioni di dati, vedereGestione delle sessioni con il conducente. Per le best practice per configurare un pool di sessioni nell'applicazione utilizzando il driver QLDB, consulta iConfigurazione della QldbDriver oggetto consigli sui driver Amazon QLDB.