Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello di QLDB concorrenza Amazon

Amazon QLDB è progettato per soddisfare le esigenze dei carichi di lavoro di elaborazione delle transazioni online (OLTP) ad alte prestazioni. QLDBsupporta funzionalità SQL simili a quelle di interrogazione e fornisce transazioni complete. ACID Inoltre, gli elementi di QLDB dati sono documenti, che offrono flessibilità dello schema e una modellazione intuitiva dei dati. Con un diario come elemento centrale, è possibile accedere QLDB alla cronologia completa e verificabile di tutte le modifiche ai dati e trasmettere transazioni coerenti ad altri servizi di dati, se necessario.

Controllo ottimistico della concorrenza

NelQLDB, il controllo della concorrenza viene implementato utilizzando il controllo di concorrenza ottimistico (). OCC OCCfunziona secondo il principio che più transazioni possono spesso essere completate senza interferire l'una con l'altra.

UtilizzandoOCC, le transazioni in ingresso QLDB non acquisiscono blocchi sulle risorse del database e funzionano con un isolamento serializzabile completo. QLDBesegue transazioni simultanee in modo seriale, in modo da produrre lo stesso effetto che se tali transazioni fossero avviate in modo seriale.

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

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

Per informazioni su come il QLDB driver gestisce e riprova OCC i conflitti e altre eccezioni transitorie, consulta. Comprendere la politica relativa ai nuovi tentativi con l'autista in Amazon QLDB

Utilizzo degli indici per evitare scansioni complete delle tabelle

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

Come procedura ottimale, è consigliabile eseguire istruzioni con una clausola di WHERE predicato che filtri in base a un campo indicizzato o a un ID di documento. QLDBrichiede un operatore di uguaglianza su un campo indicizzato per cercare in modo efficiente un documento; ad esempio, o. WHERE indexedField = 123 WHERE indexedField IN (456, 789)

Senza questa ricerca indicizzata, è QLDB necessario 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 conflitto con transazioni concorrenti. OCC

Ad esempio, si consideri una tabella denominata Vehicle che ha un indice solo sul campo. VIN Contiene i seguenti documenti.

Due utenti simultanei di nome Alice e Bob utilizzano la stessa tabella in un registro. 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 transazioni contemporaneamente. La UPDATE dichiarazione di Alice esegue una ricerca indicizzata sul VIN campo, quindi deve solo leggere quel documento. Alice termina e per prima cosa effettua con successo la transazione.

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

Conflitti di inserimento OCC

OCCi conflitti possono includere documenti appena inseriti, non solo documenti che esistevano in precedenza. Considerate il diagramma seguente, in cui due utenti simultanei (Alice e Bob) lavorano con la stessa tabella in un libro mastro. Entrambi desiderano inserire un nuovo documento solo a condizione che non esista ancora un valore del predicato.

In questo esempio, sia Alice che Bob eseguono le seguenti INSERT istruzioni SELECT 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 transazioni contemporaneamente. Entrambe le loro SELECT domande non restituiscono alcun documento esistente con un diVIN. ABCDE12345EXAMPLE Quindi, le loro applicazioni procedono con la INSERT dichiarazione.

Alice termina e per prima cosa effettua con successo la transazione. Poi, Bob prova a commettere la sua transazione, ma la QLDB rifiuta e ne lancia una. OccConflictException Questo perché la transazione impegnata di Alice ha modificato il set di risultati della SELECT query di Bob e OCC rileva questo conflitto prima di eseguire la transazione di Bob.

La SELECT query è necessaria perché questo esempio di transazione sia idempotente. Bob può quindi ripetere l'intera transazione dall'inizio. Ma la sua prossima SELECT query 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, l'esecuzione della stessa transazione più volte produce risultati identici. Se Bob esegue la INSERT senza prima verificare se un particolare particolare esiste VIN già, la tabella potrebbe finire con documenti con VIN valori duplicati.

Oltre ai conflitti, considera altri scenari di nuovi tentativi. OCC Ad esempio, è possibile che una transazione venga eseguita QLDB correttamente sul lato server, ma che il client scada durante l'attesa di una risposta. È consigliabile rendere le transazioni di scrittura idempotenti per evitare effetti collaterali imprevisti in caso di concorrenza o tentativi ripetuti.

Conflitti redazionali OCC

QLDBimpedisce le redazioni simultanee delle revisioni sullo stesso blocco di giornale. 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 stored procedure, come segueREDACT_REVISION.

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

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

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

QLDBrifiuta la richiesta di Bob con un OccConflictException anche se stanno cercando di redigere 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 ritentare la sua richiesta di redazione.

Analogamente, se due transazioni simultanee tentano di redigere la stessa revisione, è possibile elaborare solo una richiesta. L'altra richiesta ha esito negativo con un'eccezione di OCC conflitto fino al completamento della redazione. Successivamente, qualsiasi richiesta di redazione della stessa revisione genererà un errore che indica che la revisione è già stata redatta.

Gestione delle sessioni simultanee

Se hai esperienza nell'uso di un sistema di gestione di database relazionali (RDBMS), potresti conoscere i limiti delle connessioni simultanee. QLDBnon ha lo stesso concetto di RDBMS connessione tradizionale perché le transazioni vengono eseguite con messaggi di HTTP richiesta e risposta.

NelQLDB, il concetto analogo è una sessione attiva. Una sessione è concettualmente simile a un accesso utente: gestisce le informazioni sulle richieste di transazioni di dati a un registro. 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. QLDBsupporta una transazione in esecuzione attiva per sessione.

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

Per informazioni sul ciclo di vita di una sessione e su come il QLDB driver gestisce le sessioni durante l'esecuzione di transazioni di dati, vedere. Gestione delle sessioni con il driver Per le migliori pratiche per configurare un pool di sessioni nell'applicazione utilizzando il QLDB driver, consulta Configurazione dell'oggetto QldbDriver i consigli sui QLDB driver di Amazon.