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 concorrenza Amazon QLDB

Amazon QLDB è progettato per soddisfare le esigenze dei carichi di lavoro OLTP (Online Transaction Processing) ad alte prestazioni. QLDB supporta funzionalità di query simili a SQL e fornisce transazioni ACID complete. Inoltre, gli elementi di dati QLDB sono documenti che offrono flessibilità dello schema e una modellazione dei dati intuitiva. Con un journal come elemento centrale, puoi utilizzare QLDB per accedere alla cronologia completa e verificabile di tutte le modifiche ai tuoi dati e trasmettere transazioni coerenti ad altri servizi dati, se necessario.

Controllo ottimistico della concorrenza

In QLDB, il controllo della concorrenza viene implementato utilizzando il controllo della concorrenza ottimistico (OCC). OCC opera in base al 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 le transazioni simultanee in modo seriale, in modo da produrre lo stesso effetto che si otterrebbe 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 su QLDB, i controlli di convalida del modello OCC vengono implementati da QLDB stesso. Se una transazione non può essere scritta sul journal a causa di un errore nella fase di verifica di OCC, QLDB restituisce OccConflictException una 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 driver QLDB gestisce e riprova i conflitti OCC e altre eccezioni transitorie, vedere. Comprendere la politica dei nuovi tentativi con il driver in Amazon QLDB

Utilizzo degli indici per evitare scansioni complete delle tabelle

In QLDB, ogni istruzione PartiQL (inclusa SELECT ogni 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. QLDB richiede 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 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, 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 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 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 OCC di inserimento

I conflitti OCC 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 SELECT istruzioni e all'interno di una singola transazione. INSERT 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. Quindi, Bob prova a confermare la transazione, ma QLDB la 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.

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

Redazione: conflitti OCC

QLDB impedisce 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 del documento che vengono salvate sullo stesso blocco di un registro. 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'

QLDB respinge la richiesta di Bob con OccConflictException un 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 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 conflitto OCC 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. 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 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. QLDB supporta 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 driver QLDB gestisce le sessioni durante l'esecuzione di transazioni di dati, vedere. Gestione delle sessioni con il driver Per le best practice per configurare un pool di sessioni nella tua applicazione utilizzando il driver QLDB, consulta i consigli sui driver Configurazione dell'oggetto QldbDriver Amazon QLDB.