Niveles de aislamiento (WriteSerializable y Serializable)

Delta Lake en Azure Databricks admite dos niveles de aislamiento que controlan cómo interactúan las operaciones simultáneas en una tabla determinada:

Nivel de aislamiento Descripción
Serializable Nivel de aislamiento más fuerte. Garantiza que las operaciones de escritura y todas las lecturas se pueden serializar. Las operaciones se permiten siempre y cuando haya una secuencia en serie que, cuando se ejecuta una a la vez, genera el mismo resultado que se ve en la tabla. Para las operaciones de escritura, esta secuencia serial es la misma que el orden que se observa en el historial de la tabla.
WriteSerializable (valor predeterminado) Un nivel de aislamiento más débil que Serializable. Garantiza que solo se pueden serializar las operaciones de escritura (no lecturas). Sigue siendo más fuerte que el aislamiento de instantáneas. Proporciona un buen equilibrio de coherencia y disponibilidad de los datos para las operaciones más comunes.

Cuándo cambiar el nivel de aislamiento

Mantén el nivel de aislamiento predeterminado de WriteSerializable para la mayoría de las cargas de trabajo.

Con WriteSerializable, un DELETE, UPDATE o MERGE que empieza antes de una inserción concurrente todavía puede hacer commit después de ella. Las filas de la inserción no se ven afectadas, aunque coincidan con la condición de la operación. El historial de la tabla sigue listando el inserto primero, así que el contenido de la tabla no coincide con el resultado de reproducir los commits en orden histórico. Véase Ejemplo: eliminación e inserción simultáneas.

Cambia una tabla a Serializable si tu carga de trabajo no puede aceptar este resultado. Por ejemplo, si debe DELETE eliminar todas las filas coincidentes que existen al hacer un commit, o si los procesos posteriores reconstruyen el contenido de la tabla a partir del orden de commits en el historial. Con Serializable, la operación posterior falla con un conflicto y debes intentarlo de nuevo.

Serializable reduce el rendimiento para escrituras concurrentes. Las inserciones que no leen la tabla nunca entran en conflicto bajo WriteSerializable, pero sí pueden entrar en conflicto bajo Serializable. Vea Concurrencia a nivel de fila.

Cómo afectan los niveles de aislamiento a las lecturas

Las operaciones de lectura siempre usan el aislamiento de instantáneas. El nivel de aislamiento de escritura determina si es posible que un lector vea una instantánea de una tabla que, según el historial, "nunca existió".

  • Serializable: un lector siempre ve solo las tablas que se ajustan al historial.
  • WriteSerializable: un lector puede ver un estado de tabla que no existe en el registro delta.

Ejemplo: Eliminación e inserción simultáneas

Considere un escenario en el que una transacción de borrado prolongada y una transacción de inserción se inician al mismo tiempo y leen la versión v0. La transacción de inserción se confirma primero y crea la versión v1. Después, la transacción de eliminación intenta confirmar v2:

t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)

En este escenario, deleteTxn no vio los datos insertados por insertTxn y no los eliminó:

  • Serializable: deleteTxn no está permitido confirmar, y se produce un conflicto
  • WriteSerializable: deleteTxn se permite la confirmación porque se pueden ordenar las transacciones. El estado de la tabla resultante es como si insertTxn se produjera después deleteTxnde , por lo que las filas insertadas forman parte de la tabla. Sin embargo, el historial de Delta muestra el orden de confirmación físico (insertTxn en v1 antes de deleteTxn en v2).

Establecimiento del nivel de aislamiento

Para establecer el nivel de aislamiento, utiliza el ALTER TABLE comando:

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

Donde <level-name> es Serializable o WriteSerializable.

Example:

-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

¿Cuándo se confirma Delta Lake sin leer la tabla?

Las operaciones Delta Lake INSERT o append no leen el estado de la tabla antes de hacer commit si se cumplen estas condiciones:

  1. La lógica se expresa mediante la lógica SQL o el INSERT modo de adición
  2. La lógica no contiene subconsultas ni condicionales que hacen referencia a la tabla dirigida por la operación de escritura.

Al igual que con otras confirmaciones, Delta Lake usa metadatos del registro de transacciones para validar y resolver versiones de tabla al confirmar, pero en realidad no se lee ninguna versión de la tabla.

Nota:

Muchos patrones comunes usan operaciones MERGE para insertar datos en función de las condiciones de la tabla. Aunque puede volver a escribir esta lógica mediante instrucciones INSERT, si alguna expresión condicional hace referencia a una columna de la tabla de destino, estas instrucciones tienen las mismas limitaciones de simultaneidad que MERGE.

Recursos adicionales

  • Se actualizó por última vez el