ACID semantics - MaxCompute - Centre de documentation Alibaba Cloud

MaxCompute offre des garanties d'atomicité, de cohérence, d'isolation et de durabilité (ACID) pour les tâches d'écriture concurrentes. Ces garanties varient selon que vous utilisiez des tables standard ou des tables transactionnelles.

Concepts clés

Terme	Définition
Opération	Une tâche unique envoyée dans MaxCompute.
Objet de données	Objet stockant des données, comme une table non partitionnée ou une partition.
Tâche INTO	Tâche SQL contenant le mot-clé INTO, telle que INSERT INTO ou DYNAMIC INSERT INTO.
Tâche OVERWRITE	Tâche SQL contenant le mot-clé OVERWRITE, telle que INSERT OVERWRITE ou DYNAMIC INSERT OVERWRITE.
Chargement de données via Tunnel	Tâche INTO ou OVERWRITE.

Garanties ACID

Atomicité

Tables standard

En cas de conflit entre plusieurs tâches, MaxCompute garantit la réussite d'une seule d'entre elles.
L'atomicité est garantie pour les opérations CREATE, OVERWRITE et DROP sur une table ou une partition unique.
L'atomicité n'est pas garantie pour les opérations inter-tables telles que MULTI-INSERT.
L'atomicité peut également ne pas être garantie dans les cas limites suivants :
- Une opération DYNAMIC INSERT OVERWRITE sur plus de 10 000 partitions.
- Une opération INTO. En cas de restauration de transaction, le nettoyage des données peut échouer. Les données d'origine ne sont pas perdues, mais des données résiduelles issues de la tâche ayant échoué peuvent subsister.

Tables transactionnelles (garantie supplémentaire)

L'atomicité est garantie pour les opérations UPDATE, DELETE et MERGE de petits fichiers sur une table non partitionnée ou une partition. Par exemple, si deux opérations UPDATE s'exécutent simultanément sur la même partition, une seule réussit : une exécution partielle ou une double réussite sont impossibles.

Cohérence

Tables standard

La cohérence est garantie pour les tâches OVERWRITE.
Si une tâche INTO échoue en raison d'un conflit, les données de la tâche ayant échoué peuvent subsister.

Tables transactionnelles (garantie supplémentaire)

Si une tâche INTO échoue en raison d'un conflit, les données de la tâche ayant échoué ne subsistent pas.

Isolation

Tables standard

Pour les opérations autres que INTO, MaxCompute garantit la soumission des opérations de lecture.

Pour les opérations INTO, certaines opérations de lecture peuvent ne pas être soumises.

Tables transactionnelles (garantie supplémentaire)

Opérations INTO : MaxCompute garantit la soumission des opérations de lecture.

Durabilité

MaxCompute garantit la durabilité des données pour tous les types de tables. Une fois l'opération terminée, les données modifiées sont persistées de manière permanente et ne sont pas perdues, même en cas de défaillance du système.

Résolution des conflits

Lorsque des tâches s'exécutent simultanément sur la même table ou partition de destination, un conflit peut survenir. La règle de résolution est la suivante :

La tâche qui se termine en premier réussit. La tâche qui se termine plus tard peut échouer.

Exemple

Le scénario suivant illustre deux opérations UPDATE sur la même partition :

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 error

La tâche B signale une erreur car les données qu'elle a lues sont désormais obsolètes. Le résultat de la tâche A est préservé.

Matrice des résultats de conflit

Le tableau suivant présente les résultats lorsque deux tâches sont soumises simultanément sur la même table non partitionnée ou la même partition. « Plus tôt » et « plus tard » font référence à la tâche qui se termine en premier.

Tâche se terminant plus tôt	INSERT OVERWRITE ou TRUNCATE se terminant plus tard	INSERT INTO se terminant plus tard	UPDATE ou DELETE se terminant plus tard	MERGE de petits fichiers se terminant plus tard
INSERT OVERWRITE ou TRUNCATE	Les deux réussissent. Les données de la tâche ultérieure écrasent celles de la tâche antérieure.	Les deux réussissent. La tâche INSERT INTO ultérieure ajoute ses données au résultat de la tâche antérieure.	L'opération UPDATE ou DELETE ultérieure signale une erreur.	Le MERGE de petits fichiers ultérieur signale une erreur.
INSERT INTO	Les deux réussissent. Les données OVERWRITE ultérieures écrasent le résultat de la tâche INSERT INTO antérieure.	Les deux réussissent. La tâche INSERT INTO ultérieure ajoute ses données au résultat antérieur.	L'opération UPDATE ou DELETE ultérieure signale une erreur.	Le MERGE de petits fichiers ultérieur signale une erreur.
UPDATE ou DELETE	Les deux réussissent. Les données OVERWRITE ultérieures écrasent le résultat de l'opération UPDATE ou DELETE antérieure.	Les deux réussissent. La tâche INSERT INTO ultérieure ajoute ses données au résultat antérieur.	L'opération UPDATE ou DELETE ultérieure signale une erreur.	Le MERGE de petits fichiers ultérieur signale une erreur.
MERGE de petits fichiers	Les deux réussissent. Les données OVERWRITE ultérieures écrasent le résultat du MERGE antérieur.	Les deux réussissent. La tâche INSERT INTO ultérieure ajoute ses données au résultat antérieur.	L'opération UPDATE ou DELETE ultérieure signale une erreur.	Le MERGE de petits fichiers ultérieur signale une erreur.

Règles récapitulatives

Les opérations INSERT (OVERWRITE et INTO) n'entrent jamais en conflit entre elles. Deux tâches INSERT réussissent toujours, indépendamment de leur ordre.
Les opérations UPDATE, DELETE et MERGE de petits fichiers échouent lorsque les données cibles ont changé. Si la table non partitionnée ou la partition de destination a été modifiée par une tâche antérieure, l'opération UPDATE, DELETE ou MERGE de petits fichiers ultérieure signale une erreur de conflit.

Dans les cas limites où plusieurs tâches s'exécutent simultanément pendant la mise à jour des métadonnées, les tâches peuvent également signaler des erreurs de conflit causées par des modifications des métadonnées.