MaxCompute ofrece garantías de atomicidad, consistencia, aislamiento y durabilidad (ACID) para los trabajos de escritura concurrentes. Las garantías específicas dependen de si utiliza tablas estándar o tablas transaccionales.
Conceptos clave
|
Término |
Definición |
|
Operación |
Un solo trabajo enviado en MaxCompute. |
|
Objeto de datos |
Un objeto que almacena datos, como una tabla no particionada o una partición. |
|
Trabajo INTO |
Un trabajo SQL que contiene la palabra clave INTO, como INSERT INTO o DYNAMIC INSERT INTO. |
|
Trabajo OVERWRITE |
Un trabajo SQL que contiene la palabra clave OVERWRITE, como INSERT OVERWRITE o DYNAMIC INSERT OVERWRITE. |
|
Carga de datos mediante Tunnel |
Un trabajo INTO u OVERWRITE. |
Garantías ACID
Atomicidad
Tablas estándar
Si varios trabajos entran en conflicto, MaxCompute garantiza que solo uno se ejecute correctamente.
Se garantiza la atomicidad para las operaciones CREATE, OVERWRITE y DROP en una sola tabla o partición.
No se garantiza la atomicidad para operaciones entre varias tablas, como MULTI-INSERT.
-
Tampoco se garantiza la atomicidad en los siguientes casos extremos:
Una operación DYNAMIC INSERT OVERWRITE sobre más de 10,000 particiones.
Una operación INTO. Si ocurre una reversión de transacción, la limpieza de datos podría fallar. Los datos originales no se pierden, pero podrían quedar datos residuales del trabajo con errores.
Tablas transaccionales (garantía adicional)
Se garantiza la atomicidad para las operaciones UPDATE, DELETE y MERGE de archivos pequeños en una tabla no particionada o en una partición. Por ejemplo, si dos operaciones UPDATE se ejecutan al mismo tiempo sobre la misma partición, exactamente una se completa correctamente; la ejecución parcial y el éxito de ambas son imposibles.
Consistencia
Tablas estándar
Se garantiza la consistencia para los trabajos OVERWRITE.
Si un trabajo INTO falla por un conflicto, podrían quedar datos del trabajo con errores.
Tablas transaccionales (garantía adicional)
Si un trabajo INTO falla por un conflicto, no quedan datos del trabajo con errores.
Aislamiento
Tablas estándar
Para las operaciones que no son INTO, MaxCompute garantiza que las operaciones de lectura se envíen.
En las operaciones INTO, es posible que algunas operaciones de lectura no se envíen.
Tablas transaccionales (garantía adicional)
Operaciones INTO: MaxCompute garantiza que las operaciones de lectura se envíen.
Durabilidad
MaxCompute garantiza la durabilidad de los datos para todos los tipos de tablas. Una vez que una operación termina, los datos modificados se conservan de forma permanente y no se pierden, incluso si ocurre un error del sistema.
Cómo se resuelven los conflictos
Cuando varios trabajos se ejecutan de forma concurrente sobre la misma tabla o partición de destino, puede surgir un conflicto. La regla de resolución es a continuación:
El trabajo que termina primero se completa correctamente. El trabajo que termina después puede fallar.
Ejemplo
A continuación se muestra un escenario que ilustra dos operaciones UPDATE sobre la misma partición:
t0: job_A starts (UPDATE on partition p1)
t1: job_B starts (UPDATE on partition p1)
t2: job_A commits — succeeds, partition p1 is updated
t3: job_B attempts to commit — detects that p1 changed since job_B started reading → reports a conflict errorEl trabajo B reporta un error porque los datos que leyó ya están desactualizados. El resultado del trabajo A se conserva.
Matriz de resultados de conflictos
La siguiente tabla muestra los resultados cuando se envían dos trabajos al mismo tiempo sobre la misma tabla no particionada o partición. Los términos "anterior" y "posterior" indican cuál trabajo termina primero.
|
Trabajo que termina antes |
INSERT OVERWRITE o TRUNCATE que termina después |
INSERT INTO que termina después |
UPDATE o DELETE que termina después |
MERGE de archivos pequeños que termina después |
|
INSERT OVERWRITE o TRUNCATE |
Ambos se completan correctamente. Los datos del trabajo posterior sobrescriben los del trabajo anterior. |
Ambos se completan correctamente. El INSERT INTO posterior anexa sus datos al resultado del trabajo anterior. |
El UPDATE o DELETE posterior reporta un error. |
El MERGE de archivos pequeños posterior reporta un error. |
|
INSERT INTO |
Ambos se completan correctamente. Los datos OVERWRITE posteriores sobrescriben el resultado del INSERT INTO anterior. |
Ambos se completan correctamente. El INSERT INTO posterior anexa sus datos al resultado anterior. |
El UPDATE o DELETE posterior reporta un error. |
El MERGE de archivos pequeños posterior reporta un error. |
|
UPDATE o DELETE |
Ambos se completan correctamente. Los datos OVERWRITE posteriores sobrescriben el resultado del UPDATE o DELETE anterior. |
Ambos se completan correctamente. El INSERT INTO posterior anexa sus datos al resultado anterior. |
El UPDATE o DELETE posterior reporta un error. |
El MERGE de archivos pequeños posterior reporta un error. |
|
MERGE de archivos pequeños |
Ambos se completan correctamente. Los datos OVERWRITE posteriores sobrescriben el resultado del MERGE anterior. |
Ambos se completan correctamente. El INSERT INTO posterior anexa sus datos al resultado anterior. |
El UPDATE o DELETE posterior reporta un error. |
El MERGE de archivos pequeños posterior reporta un error. |
Resumen de reglas
Las operaciones INSERT (OVERWRITE e INTO) nunca entran en conflicto entre sí. Dos trabajos INSERT siempre se completan correctamente, sin importar el orden.
UPDATE, DELETE y MERGE de archivos pequeños fallan cuando los datos de destino cambiaron. Si un trabajo anterior modificó la tabla no particionada o la partición de destino, el UPDATE, DELETE o MERGE de archivos pequeños posterior reporta un error de conflicto.
En casos extremos donde varios trabajos se ejecutan de forma concurrente mientras se actualizan los metadatos, también pueden reportarse errores de conflicto provocados por dichos cambios.