Livelli di isolamento della transazione in Neptune

Amazon Neptune implementa diversi livelli di isolamento della transazione per query di sola lettura e query di mutazione. SPARQLe le interrogazioni Gremlin sono classificate come di sola lettura o di mutazione in base ai seguenti criteri:

• InSPARQL, esiste una chiara distinzione tra le query di lettura (SELECT, ASKCONSTRUCT, e DESCRIBE come definite nella specifica SPARQL1.1 Query Language) e le query di mutazione (INSERTe come definite nella specifica 1.1 Update). DELETE SPARQL

  Tenere presente che Neptune tratta più query di mutazione inviate insieme (ad esempio, in un messaggio POST separato da punto e virgola) come una singola transazione. Sono garantite per avere successo o fallire come unità atomica e, in caso di errore, le modifiche parziali vengono ripristinate.

• Tuttavia, in Gremlin, Neptune classifica una query come di sola lettura o di mutazione a seconda che contenga eventuali passaggi del percorso di query, ad esempio addE(), addV(), property() o drop() che manipola i dati. Se la query contiene una tale fase di percorso, viene classificata ed eseguita come query di mutazione.

In Gremlin è anche possibile utilizzare sessioni di standing. Per ulteriori informazioni, consulta Sessioni basate su script Gremlin. In queste sessioni, tutte le query, incluse le query di sola lettura, vengono eseguite con lo stesso isolamento delle query di mutazione sull'endpoint di scrittura.

Utilizzando le sessioni di lettura-scrittura bolt inopenCypher, tutte le query, incluse le query di sola lettura, vengono eseguite con lo stesso isolamento delle query di mutazione, sull'endpoint writer.

Isolamento delle query di sola lettura in Neptune

Neptune valuta le query di sola lettura nella semantica di isolamento degli snapshot. Ciò significa che una query di sola lettura opera logicamente su uno snapshot coerente del database acquisito all'inizio della valutazione della query. Neptune può quindi garantire che nessuno dei seguenti fenomeni si verificherà:

• Dirty reads: le query di sola lettura in Neptune non vedranno mai i dati non vincolati di una transazione simultanea.

• Non-repeatable reads: una transazione di sola lettura che legge gli stessi dati più di una volta restituirà sempre gli stessi valori.

• Phantom reads: una transazione di sola lettura non leggerà mai i dati aggiunti dopo l'inizio della transazione.

Poiché l'isolamento delle istantanee si ottiene utilizzando multiversion concurrency control (MVCC), le query di sola lettura non hanno bisogno di bloccare i dati e quindi non bloccano le query di mutazione.

Le repliche di lettura accettano solo query di sola lettura, pertanto tutte le query sulle repliche di lettura vengono eseguite nella semantica di isolamento SNAPSHOT.

L'unica considerazione aggiuntiva quando si esegue una query su una replica di lettura è che può verificarsi un piccolo ritardo di replica tra le repliche di scrittura e di lettura. Ciò significa che un aggiornamento effettuato su una replica di scrittura potrebbe richiedere poco tempo per essere propagato alla replica di lettura da cui si sta leggendo. Il tempo di replica effettivo dipende dal carico di scrittura sull'istanza primaria. L'architettura Neptune supporta la replica a bassa latenza e il ritardo di replica è strumentato in un parametro Amazon. CloudWatch

Tuttavia, a causa del livello di isolamento SNAPSHOT, le query di lettura visualizzano sempre uno stato coerente del database, anche se non è il più recente.

Nei casi in cui è richiesta una forte garanzia che una query osservi il risultato di un aggiornamento precedente, invia la query all'endpoint di scrittura stesso anziché a una replica di lettura.

Isolamento delle query di mutazione in Neptune

Le letture effettuate come parte delle query di mutazione vengono eseguite sotto l'isolamento della transazione READ COMMITTED, il che esclude la possibilità di letture modificate. Superando le normali garanzie fornite per l'isolamento della transazione READ COMMITTED, Neptune fornisce la garanzia solida che né le letture NON-REPEATABLE né le letture PHANTOM possono verificarsi.

Queste garanzie solide si ottengono bloccando record e intervalli di record durante la lettura dei dati. Questo impedisce alle transazioni simultanee di effettuare inserzioni o eliminazioni negli intervalli di indice dopo che sono state lette, garantendo così letture ripetibili.

Nota

Tuttavia, una transazione di mutazione simultanea Tx2 potrebbe iniziare dopo l'avvio della transazione di mutazione Tx1 e potrebbe eseguire il commit di una modifica prima che Tx1 abbia bloccato i dati per leggerli. In questo caso, Tx1 vedrebbe la modifica di Tx2 come se Tx2 fosse stata completata prima dell'avvio di Tx1. Poiché ciò si applica solo alle modifiche di cui è stato eseguito il commit, un dirty read non può mai verificarsi.

Per comprendere il meccanismo di blocco utilizzato da Neptune per le query di mutazione, è utile innanzitutto comprendere i dettagli di Neptune Il modello di dati Graph e Strategia di indicizzazione. Neptune gestisce i dati utilizzando tre indici, vale a dire, SPOG, POGS e GPSO.

Per ottenere letture ripetibili per il livello di transazione READ COMMITTED, Neptune accetta blocchi di intervalli nell'indice utilizzato. Ad esempio, se una query di mutazione legge tutte le proprietà e gli edge in uscita di un vertice denominato person1, il nodo blocca l'intero intervallo definito dal prefisso S=person1 nell'indice SPOG prima di leggere i dati.

Lo stesso meccanismo si applica quando si utilizzano altri indici. Ad esempio, quando una transazione di mutazione cerca tutte le coppie di vertici origine-destinazione per una determinata etichetta edge utilizzando l'indice POGS, l'intervallo per l'etichetta edge nella posizione P sarebbe bloccato. Qualsiasi transazione simultanea, a prescindere che sia una query di sola lettura o di mutazione, può comunque eseguire letture all'interno dell'intervallo bloccato. Tuttavia, qualsiasi mutazione che implichi l'inserimento o l'eliminazione di nuovi record nell'intervallo di prefissi bloccato richiederebbe un blocco esclusivo e verrebbe impedita.

In altre parole, quando un intervallo dell'indice è stato letto da una transazione di mutazione, c'è una forte garanzia che questo intervallo non verrà modificato da qualsiasi transazione simultanea fino al termine della transazione di lettura. Ciò garantisce che non si verificherà alcuna operazione non-repeatable reads.

Risoluzione dei conflitti tramite timeout di attesa di blocco

Se una seconda transazione cerca di modificare un record in un intervallo bloccato da una prima transazione, Neptune rileva immediatamente il conflitto e blocca la seconda transazione.

Se non viene rilevato alcun deadlock delle dipendenze, Neptune applica automaticamente un meccanismo di timeout di attesa del blocco, in cui la transazione bloccata attende la transazione che contiene il blocco fino a 60 secondi per terminare e rilasciare il blocco.

• Se il timeout di attesa del blocco scade prima che il blocco venga rilasciato, viene eseguito il rollback della transazione bloccata.

• Se il blocco viene rilasciato entro il timeout di attesa del blocco, la seconda transazione viene sbloccata e può terminare senza che sia necessario riprovare.

Tuttavia, se Neptune rileva un deadlock delle dipendenze tra le due transazioni, non è possibile eseguire la riconciliazione automatica del conflitto. In questo caso, Neptune annulla immediatamente ed esegue il rollback di una delle due transazioni senza avviare un timeout di attesa del blocco. Neptune fa il massimo sforzo per eseguire il rollback della transazione con il minor numero di record inseriti o eliminati.

Blocchi di intervalli e falsi conflitti

Neptune accetta i blocchi di intervalli usando i blocchi gap. Un blocco gap è un blocco su un gap tra i record dell'indice o un blocco sul gap prima del primo o dopo l'ultimo record dell'indice.

Neptune utilizza una cosiddetta tabella di dizionari per associare valori ID numerici a valori letterali di stringa specifici. Ecco un esempio di stato di un dizionario Neptune: tabella:

Stringa	ID
tipo	1
default_graph	2
person_3	3
person_1	5
knows	6
person_2	7
age	8
edge_1	9
lives_in	10
New York	11
Person	12
Place	13
edge_2	14

Le stringhe di cui sopra appartengono a un modello di grafico di proprietà, ma i concetti si applicano allo stesso modo anche a tutti i modelli di grafi. RDF

Lo stato corrispondente dell'indice SPOG (Subject-Predicate-Object_Graph) è mostrato in basso a sinistra. A destra, vengono mostrate le stringhe corrispondenti, per aiutare a capire il significato dei dati dell'indice.

S (ID)	P (ID)	O (ID)	G (ID)		S (stringa)	P (stringa)	O (stringa)	G (stringa)
3	1	12	2		person_3	tipo	Person	default_graph
5	1	12	2		person_1	tipo	Person	default_graph
5	6	3	9		person_1	knows	person_3	edge_1
5	8	40	2		person_1	age	40	default_graph
5	10	11	14		person_1	lives_in	New York	edge_2
7	1	12	2		person_2	tipo	Person	default_graph
11	1	13	2		New York	tipo	Place	default_graph

Ora, se una query di mutazione legge tutte le proprietà e gli spigoli in uscita di un vertice denominatoperson_1, il nodo bloccherebbe l'intero intervallo definito dal prefisso nell'indice prima di leggere i dati. S=person_1 SPOG Il blocco dell'intervallo inserirà blocchi gap su tutti i record corrispondenti e sul primo record che non corrisponde. I record corrispondenti verranno bloccati, mentre quelli non corrispondenti non verranno bloccati. Neptune inserirà i blocchi gap come segue:

• 5 1 12 2 (gap 1)

• 5 6 3 9 (gap 2)

• 5 8 40 2 (gap 3)

• 5 10 11 14 (gap 4)

• 7 1 12 2 (gap 5)

In questo modo vengono bloccati i seguenti record:

• 5 1 12 2

• 5 6 3 9

• 5 8 40 2

• 5 10 11 14

In questo stato, le seguenti operazioni sono legittimamente bloccate:

• Inserimento di una nuova proprietà o arco per S=person_1. Una nuova proprietà diversa da type o un nuovo arco devono essere inseriti nel gap 2, nel gap 3, nel gap 4 o nel gap 5, che sono tutti bloccati.

• Eliminazione di qualsiasi record esistente.

Allo stesso tempo, alcune operazioni simultanee verranno bloccate in modo errato (generando falsi conflitti):

• Qualsiasi inserimento di proprietà o archi per S=person_3 viene bloccato perché deve essere inserito nel gap 1.

• Qualsiasi nuovo inserimento di vertici a cui viene assegnato un ID compreso tra 3 e 5 verrà bloccato perché deve essere inserito nel gap 1.

• Qualsiasi nuovo inserimento di vertici a cui viene assegnato un ID compreso tra 5 e 7 verrà bloccato perché deve essere inserito nel gap 5.

I blocchi gap non sono sufficientemente precisi per bloccare il gap per un predicato specifico (ad esempio, per bloccare gap5 per il predicato S=5).

I blocchi di intervallo vengono posizionati solo nell'indice in cui avviene la lettura. Nel caso precedente, i record sono bloccati solo nell'SPOGindice, non in o. POGS GPSO Le letture di una query possono essere eseguite su tutti gli indici a seconda dei modelli di accesso, che possono essere elencati utilizzando explain APIs (per Sparql e per Gremlin).

Nota

I blocchi gap possono anche essere utilizzati per aggiornamenti simultanei sicuri sugli indici sottostanti, il che può anche portare a falsi conflitti. Questi blocchi gap vengono posizionati indipendentemente dal livello di isolamento o dalle operazioni di lettura eseguite dalla transazione.

I falsi conflitti possono verificarsi non solo quando le transazioni simultanee entrano in conflitto a causa di blocchi gap, ma anche in alcuni casi quando una transazione viene ritentata dopo qualsiasi tipo di errore. Se il rollback attivato dall'errore è ancora in corso e i blocchi precedentemente utilizzati per la transazione non sono ancora stati completamente rilasciati, il nuovo tentativo genererà un falso conflitto e avrà esito negativo.

Con un carico elevato, in genere è possibile che il 3-4% delle query di scrittura non riesca a causa di falsi conflitti. Per un client esterno, tali falsi conflitti sono difficili da prevedere e devono essere gestiti mediante nuovi tentativi.