Niveles de aislamiento de transacciones en Neptune

Amazon Neptune implementa diferentes niveles de aislamiento de transacciones para consultas de solo lectura y para consultas de mutación. SPARQLy las consultas de Gremlin se clasifican como de solo lectura o con mutaciones según los siguientes criterios:

• EnSPARQL, existe una distinción clara entre las consultas de lectura (SELECT, ASKCONSTRUCT, y tal DESCRIBE como se definen en la especificación del lenguaje de consultas SPARQL 1.1) y las consultas de mutación (INSERTy tal DELETE como se definen en la especificación de la actualización SPARQL1.1).

  Tenga en cuenta que Neptune trata varias consultas de mutación que se envían juntas (por ejemplo, en un mensaje POST, separadas por punto y coma) como una sola transacción. Se garantiza que se efectúan de forma correcta o incorrecta como una unidad atómica y, en caso de fallo, se revierten los cambios parciales.

• Sin embargo, en Gremlin, Neptune considera una consulta como de solo lectura o de mutación en función de si contiene algún paso de ruta de consulta como addE(), addV(), property() o drop() que manipula los datos. Si la consulta contiene este paso de ruta, se clasifica y ejecuta como una consulta de mutación.

También es posible utilizar sesiones activas en Gremlin. Para obtener más información, consulte Sesiones basadas en scripts de Gremlin. En estas sesiones, todas las consultas, incluidas las de solo lectura, se ejecutan con el mismo aislamiento que las consultas de mutación en el punto de conexión del escritor.

Al utilizar sesiones de lectura-escritura tipo boltopenCypher, todas las consultas, incluidas las de solo lectura, se ejecutan con el mismo aislamiento que las consultas de mutación, en el punto final del escritor.

Aislamiento de consultas de solo lectura en Neptune

Neptune evalúa las consultas de solo lectura con semántica de aislamiento de instantáneas. Esto significa que una consulta de solo lectura opera de forma lógica en una instantánea coherente de la base de datos realizada cuando comienza la evaluación de la consulta. Neptune puede garantizar entonces que no se produzcan los siguientes fenómenos:

• Dirty reads: las consultas de solo lectura en Neptune nunca tendrán datos no confirmados de una transacción simultánea.

• Non-repeatable reads: una transacción de solo lectura que lea los mismos datos más de una vez siempre obtendrá los mismos valores.

• Phantom reads: una transacción de solo lectura nunca leerá los datos que se hayan añadido después del inicio de la transacción.

Como el aislamiento de las instantáneas se logra mediante el control de simultaneidad multiversión (MVCC), las consultas de solo lectura no necesitan bloquear los datos y, por lo tanto, no bloquean las consultas de mutación.

Las réplicas de lectura solo aceptan consultas de solo lectura, por lo que todas las consultas de réplicas de lectura se ejecutan bajo semántica de aislamiento SNAPSHOT.

La única consideración adicional a la hora de consultar una réplica de lectura es que puede haber un pequeño retraso de replicación entre el escritor y las réplicas de lectura. Esto significa que una actualización realizada en el escritor puede tardar poco tiempo en propagarse a la réplica de lectura desde la que está leyendo. El tiempo de replicación real depende de la carga de escritura en la instancia principal. La arquitectura Neptune admite la replicación de baja latencia y el retraso de la replicación se instrumenta en una métrica de Amazon. CloudWatch

Sin embargo, debido al nivel de aislamiento de SNAPSHOT, las consultas de lectura siempre ven un estado coherente de la base de datos, incluso si no es el más reciente.

En los casos en los que necesite una garantía sólida de que una consulta observe el resultado de una actualización anterior, envíe la consulta al propio punto de enlace de escritor en lugar de a una réplica de lectura.

Aislamiento de consultas de mutación en Neptune

Las lecturas realizadas como parte de las consultas de mutación se ejecutan con aislamiento de transacciones READ COMMITTED, lo que descarta la posibilidad de lecturas sucias. Al ir más allá de las garantías habituales proporcionadas para el aislamiento de transacciones READ COMMITTED, Neptune proporciona la garantía sólida de que no pueden producirse lecturas NON-REPEATABLE ni PHANTOM.

Estas sólidas garantías se logran bloqueando registros y rangos de registros al leer datos. Esto impide que las transacciones simultáneas realicen inserciones o eliminaciones en rangos de índice después de leerlos, lo que garantiza lecturas repetibles.

nota

Sin embargo, podría comenzar una transacción de mutación simultánea Tx2 después del inicio de la transacción Tx1 de mutación, y podría confirmar un cambio antes de que Tx1 hubiera bloqueado los datos para leerlos. En ese caso, Tx1 vería el cambio de Tx2 como si Tx2 se hubiera completado antes de que se iniciara Tx1. Puesto que esto solo se aplica a los cambios confirmados, no se podría producir nunca dirty read.

Para comprender el mecanismo de bloqueo que utiliza Neptune para las consultas de mutación, primero es útil comprender los detalles de Modelo de datos de gráficos y Estrategia de indexación de Neptune. Neptune administra los datos mediante tres índices: SPOG, POGS y GPSO.

Para conseguir lecturas repetibles para el nivel de transacción READ COMMITTED, Neptune toma bloqueos de rango en el índice que se está utilizando. Por ejemplo, si una consulta de mutación lee todas las propiedades y los bordes salientes de un vértice denominado person1, el nodo bloquearía todo el rango definido por el prefijo S=person1 en el índice SPOG antes de leer los datos.

Se aplica el mismo mecanismo cuando se utilizan otros índices. Por ejemplo, cuando una transacción de mutación busca todos los pares de vértices de origen-destino para una determinada etiqueta de borde mediante el índice POGS, el rango de la etiqueta de borde en la posición P se bloquearía. Cualquier transacción simultánea, independientemente de si se trata de una consulta de solo lectura o de mutación, podría realizar lecturas dentro del rango bloqueado. Sin embargo, cualquier mutación que implique la inserción o eliminación de registros nuevos en el rango de prefijos bloqueados requeriría un bloqueo exclusivo y se evitaría.

En otras palabras, cuando una transacción de mutación ha leído un rango del índice, existe una gran garantía de que este rango no se modificará mediante ninguna transacción simultánea hasta el final de la transacción de lectura. Esto garantiza que no se producirá non-repeatable reads.

Resolución de conflictos mediante tiempos de espera de bloqueo

Si una segunda transacción intenta modificar un registro en un rango que ha bloqueado una primera transacción, Neptune detecta el conflicto inmediatamente y bloquea la segunda transacción.

Si no se detecta un interbloqueo de dependencias, Neptune aplica automáticamente un mecanismo de tiempo de espera de bloqueo, en el que la transacción bloqueada espera hasta 60 segundos a que la transacción que contiene el bloqueo finalice y libere el bloqueo.

• Si el tiempo de espera de bloqueo vence antes de que se libere el bloqueo, la transacción bloqueada se revisa.

• Si el bloqueo se libera dentro del tiempo de espera del bloqueo, la segunda transacción se desbloquea y puede finalizar correctamente sin necesidad de reintentarlo.

Sin embargo, si Neptune detecta un interbloqueo de dependencia entre las dos transacciones, no es posible que se produzca una conciliación automática del conflicto. En este caso, Neptune cancela y revierte inmediatamente una de las dos transacciones sin iniciar un tiempo de espera de bloqueo. Neptune hace todo lo posible para revertir la transacción que tiene el menor número de registros insertados o eliminados.

Bloqueos de rango y conflictos falsos

Neptune toma bloqueos de alcance utilizando bloqueos de espacio. Un bloqueo de espacio consiste en bloquear un espacio entre los registros del índice o bloquear el espacio antes del primer registro de índice o después del último.

Neptune usa lo que se denomina una tabla de diccionario para asociar valores de identificadores numéricos con literales de cadena específicos. Aquí tenemos un ejemplo del estado de una tabla de diccionario de Neptune:

Cadena	ID
type	1
default_graph	2
person_3	3
person_1	5
knows	6
person_2	7
age	8
edge_1	9
lives_in	10
Nueva York	11
Persona	12
Place	13
edge_2	14

Las cadenas anteriores pertenecen a un modelo de gráficos de propiedades, pero los conceptos se aplican por igual a todos los RDF modelos gráficos.

El estado correspondiente del índice SPOG (Subject-Predicate-Object_Graph) se muestra abajo, a la izquierda. A la derecha, se muestran las cadenas correspondientes para ayudar a entender el significado de los datos del índice.

S (ID)	P (ID)	O (ID)	G (ID)		S (cadena)	P (cadena)	O (cadena)	G (cadena)
3	1	12	2		person_3	type	Persona	default_graph
5	1	12	2		person_1	type	Persona	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	Nueva York	edge_2
7	1	12	2		person_2	type	Persona	default_graph
11	1	13	2		Nueva York	type	Place	default_graph

Ahora, si una consulta de mutación lee todas las propiedades y los bordes salientes de un vértice denominadoperson_1, el nodo bloqueará todo el rango definido por el prefijo del índice antes de leer los datos. S=person_1 SPOG El bloqueo de rango colocaría bloqueos de espacio en todos los registros coincidentes y en el primer registro que no coincida. Los registros coincidentes se bloquearían y los no coincidentes no se bloquearían. Neptune colocaría los espacios de la siguiente manera:

• 5 1 12 2 (espacio 1)

• 5 6 3 9 (espacio 2)

• 5 8 40 2 (espacio 3)

• 5 10 11 14 (espacio 4)

• 7 1 12 2 (espacio 5)

Esto bloquea los siguientes registros:

• 5 1 12 2

• 5 6 3 9

• 5 8 40 2

• 5 10 11 14

En este estado, las siguientes operaciones se bloquean legítimamente:

• Inserción de una nueva propiedad o borde para S=person_1. Una nueva propiedad que no sea type o un borde nuevo tendrían que ir en el espacio 2, el espacio 3, el espacio 4 o el espacio 5, todos los cuales están bloqueados.

• Eliminación de cualquiera de los registros existentes.

Al mismo tiempo, algunas operaciones simultáneas se bloquearían falsamente (lo que generaría conflictos falsos):

• Todas las inserciones de propiedades o bordes de S=person_3 se bloquean porque deberían estar en el espacio 1.

• Cualquier inserción de un nuevo vértice a la que se le asigne un identificador entre 3 y 5 se bloqueará porque tendría que ir en el espacio 1.

• Cualquier inserción de un nuevo vértice a la que se le asigne un identificador entre 5 y 7 se bloqueará porque tendría que ir en el espacio 5.

Los bloqueos de espacios no son lo suficientemente precisos como para bloquear el espacio de un predicado específico (por ejemplo, para bloquear el espacio 5 para el predicado S=5).

Los bloqueos de rango solo se colocan en el índice donde se produce la lectura. En el caso anterior, los registros se bloquean solo en el SPOG índice, no en POGS o. GPSO Las lecturas de una consulta se pueden realizar en todos los índices en función de los patrones de acceso, que se pueden enumerar utilizando explain APIs (para Sparql y Gremlin).

nota

También se pueden utilizar bloqueos de espacios para garantizar la seguridad de las actualizaciones simultáneas de los índices subyacentes, lo que también puede provocar conflictos falsos. Estos bloqueos de espacios se colocan independientemente del nivel de aislamiento o de las operaciones de lectura realizadas por la transacción.

Los conflictos falsos pueden producirse no solo cuando las transacciones simultáneas colisionan debido a bloqueos de espacios, sino también, en algunos casos, cuando se vuelve a intentar realizar una transacción tras algún tipo de error. Si la reversión provocada por el error sigue en curso y los bloqueos previamente realizados para la transacción aún no se han liberado por completo, al reintentarlo se detectará un conflicto falso y se producirá un error.

Con una carga elevada, normalmente se produce un error en el 3-4 % de las consultas de escritura debido a conflictos falsos. En el caso de un cliente externo, estos conflictos falsos son difíciles de predecir y deben solucionarse mediante reintentos.