MaxCompute garantit l'atomicité, la cohérence, l'isolation et la durabilité (ACID) pour les tâches d'écriture concurrentes. Les garanties varient selon que vous utilisez des tables standard ou des tables transactionnelles.
Concepts clés
| Terme | Définition |
|---|---|
| Opération | Une seule tâche soumise dans MaxCompute. |
| Objet de données | Objet stockant des données, tel qu'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 :
Opération DYNAMIC INSERT OVERWRITE sur plus de 10 000 partitions.
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 aboutit : l'exécution partielle et la 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 table. 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 errorLa 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 conservé.
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. L'opération 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. | L'opération MERGE de petits fichiers ultérieure signale une erreur. |
| INSERT INTO | Les deux réussissent. Les données OVERWRITE ultérieures écrasent le résultat de l'opération INSERT INTO antérieure. | Les deux réussissent. L'opération INSERT INTO ultérieure ajoute ses données au résultat antérieur. | L'opération UPDATE ou DELETE ultérieure signale une erreur. | L'opération MERGE de petits fichiers ultérieure 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. L'opération INSERT INTO ultérieure ajoute ses données au résultat antérieur. | L'opération UPDATE ou DELETE ultérieure signale une erreur. | L'opération MERGE de petits fichiers ultérieure signale une erreur. |
| MERGE de petits fichiers | Les deux réussissent. Les données OVERWRITE ultérieures écrasent le résultat de l'opération MERGE antérieure. | Les deux réussissent. L'opération INSERT INTO ultérieure ajoute ses données au résultat antérieur. | L'opération UPDATE ou DELETE ultérieure signale une erreur. | L'opération MERGE de petits fichiers ultérieure 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, quel que soit l'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.