Comment supprimer plusieurs items dans DynamoDB

Il n'y a pas de DELETE FROM table WHERE … dans DynamoDB. Chaque suppression cible un item par sa clé primaire complète — l'API n'a pas d'opération de suppression en masse, pas de truncate, et l'instruction DELETE de PartiQL supprime exactement un item par instruction. Donc « supprimer plusieurs items » est toujours un travail en deux étapes : trouver les clés, puis émettre une suppression par clé, regroupées en lots pour le débit.

Ce guide couvre les options de traitement par lots, la variante transactionnelle tout-ou-rien, le cas « tout supprimer », et comment faire la même chose avec une sélection et deux frappes de clavier dans une GUI.

Comment supprimer plusieurs items dans DynamoDB ?

Collecte les clés primaires des items dont tu veux te débarrasser (via Query ou Scan), puis supprime-les par lots : BatchWriteItem accepte jusqu'à 25 DeleteRequest par appel, TransactWriteItems supprime jusqu'à 100 items de façon atomique, et les instructions PartiQL DELETE peuvent être regroupées par 25 avec BatchExecuteStatement. Dans DynoTable, tu sélectionnes les lignes et appuies sur ⌘⌫ pour mettre les suppressions en attente, puis tu revois et valides.

• En masse, au mieux : BatchWriteItem — 25 suppressions par appel, réessaie les restes.
• Tout-ou-rien : TransactWriteItems — jusqu'à 100 actions qui réussissent ou échouent ensemble.
• Syntaxe façon SQL : PartiQL DELETE + BatchExecuteStatement — même règle par clé, orthographe familière.
• Tout ce que contient la table : stratégies de truncate — souvent moins cher de supprimer et recréer la table.
• Une sélection visuelle : suppressions mises en attente dans DynoTable — sélectionne les lignes, mets en attente, revois les diffs rouges, valide.

Étape 0 : collecter les clés

Une suppression exige la clé primaire entière — sur une table à clé composite, c'est la clé de partition et la clé de tri (AWS : « Pour chaque clé primaire, tu dois fournir tous les attributs de clé »). Tu ne peux pas supprimer par un attribut arbitraire, donc « supprimer chaque item où status = 'archived' » commence par une lecture :

• Si la condition porte sur une clé (ou une clé de GSI), un Query ciblé collecte les clés à peu de frais.
• Sinon, c'est un Scan avec un filtre — qui lit (et facture) toute la table, filtre ou pas ; voir query vs scan.

Utilise une ProjectionExpression qui ne renvoie que les attributs de clé, et suis LastEvaluatedKey jusqu'au bout (la pagination) — sinon tu ne supprimeras silencieusement que le contenu de la première page de 1 Mo.

Méthode 1 : BatchWriteItem (jusqu'à 25 suppressions par appel)

BatchWriteItem regroupe jusqu'à 25 requêtes put/delete ou 16 Mo par appel (référence de l'API AWS : « Un seul appel à BatchWriteItem peut transmettre jusqu'à 16 Mo de données sur le réseau, comprenant jusqu'à 25 opérations put ou delete d'items »).

aws dynamodb batch-write-item --request-items '{
  "Orders": [
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1001"}, "SK": {"S": "META"}}}},
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1002"}, "SK": {"S": "META"}}}},
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1003"}, "SK": {"S": "META"}}}}
  ]
}'

Trois propriétés du lot font trébucher les gens — toutes tirées directement de la référence de l'API :

• Ce n'est pas atomique. « Les opérations individuelles PutItem et DeleteItem spécifiées dans BatchWriteItem sont atomiques ; cependant BatchWriteItem dans son ensemble ne l'est pas. » Certaines suppressions peuvent aboutir pendant que d'autres échouent.
• Tu dois réessayer les UnprocessedItems. Les requêtes throttlées reviennent dans la map de réponse UnprocessedItems, dans la même forme que la requête — « Typiquement, tu appellerais BatchWriteItem en boucle », et AWS « recommande fortement d'utiliser un algorithme de backoff exponentiel » entre les réessais.
• Pas de conditions. « Tu ne peux pas spécifier de conditions sur les requêtes put et delete individuelles » — une suppression conditionnelle doit passer par DeleteItem ou une transaction. Un lot rejette aussi deux opérations sur la même clé dans un même appel.

La forme de la boucle — découper par 25, envoyer, remettre les restes en file avec backoff — est la même que celle couverte dans les opérations par lots.

Méthode 2 : TransactWriteItems (suppressions atomiques)

Quand un ensemble de suppressions doit réussir ou échouer ensemble — supprimer un item parent et les enfants de sa collection d'items, par exemple — utilise TransactWriteItems : jusqu'à 100 actions (suppressions, puts, updates, vérifications de condition) appliquées de façon atomique, avec des expressions de condition par item autorisées. Le compromis : une écriture transactionnelle coûte le double de la capacité d'écriture d'une écriture simple. La mécanique complète (tokens d'idempotence, TransactionCanceledException, calcul du coût) est dans les transactions DynamoDB.

Méthode 3 : PartiQL DELETE, par lots

PartiQL ne lève pas la règle « une clé à la fois » — il la réécrit juste autrement. Le guide du développeur est explicite (PartiQL DELETE) : « Tu ne peux supprimer qu'un item à la fois. Tu ne peux pas émettre une seule instruction PartiQL DynamoDB qui supprime plusieurs items », et la condition WHERE « doit se résoudre en une seule valeur de clé primaire ».

Pour supprimer plusieurs items, tu regroupes des instructions mono-item — BatchExecuteStatement exécute jusqu'à 25 instructions par lot (toutes en lecture ou toutes en écriture, jamais mélangées) :

[
  {"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1001' AND SK = 'META'"},
  {"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1002' AND SK = 'META'"}
]

aws dynamodb batch-execute-statement --statements file://statements.json

Un WHERE qui ne fixe pas la clé complète échoue — il n'y a pas de DELETE FROM Orders WHERE status = 'archived'. Plus de patterns PartiQL (et les limites derrière) dans les exemples PartiQL et PartiQL vs SQL.

Supprimer TOUS les items (truncate)

DynamoDB n'a pas de truncate. Tes options, par ordre de préférence :

1. Supprimer et recréer la table. La suppression item par item d'une table entière facture une écriture par item ; DeleteTable + CreateTable évite toute la facture d'écriture. Le piège : les réglages de table — index, TTL, streams, mode de capacité, tags — ne reviennent pas tout seuls ; tu les redéclares à la création (l'infrastructure-as-code en fait un non-événement).
2. Faire expirer les items avec TTL. Si « supprimer tout ce qui est plus vieux que X » est vraiment ce que tu veux, le TTL supprime les items expirés en arrière-plan sans consommer de capacité d'écriture — une suppression en masse au ralenti qui ne coûte rien.
3. Scan + suppression par lots (Méthode 1) quand la table doit rester en service et que seul un sous-ensemble part — tu paies une lecture par item scanné plus une écriture par item supprimé.

Supprimer plusieurs items dans DynoTable

Le flux sélectionner-puis-supprimer ci-dessus — requêter, collecter les clés, découper, réessayer — est exactement la corvée qu'une GUI devrait prendre en charge. Dans DynoTable, c'est une sélection dans la grille :

1. Exécute ou filtre une requête pour que les lignes à supprimer soient à l'écran.
2. Sélectionne-les et appuie sur ⌘⌫ — chaque ligne sélectionnée devient une suppression mise en attente. Rien n'a encore touché DynamoDB : les lignes se teintent en rouge dans la grille et apparaissent comme des cartes révisables dans le panneau de mise en attente.
3. Revois, puis valide. Les validations partent sous forme de lots TransactWriteItems avec des conditions de verrouillage optimiste — une suppression mise en attente ne passe que si l'item existe toujours — et les gros lots sont automatiquement découpés pour rester dans les limites de transaction de DynamoDB. ⌘⇧⌫ saute la revue et supprime-et-valide la sélection en un seul raccourci.

Le périmètre est honnête : tu supprimes les lignes que tu as sélectionnées — une opération revue, récupérable jusqu'à la validation — pas un truncate aveugle de toute la table. Pour vider une table entière, supprime-la et recrée-la (ci-dessus).

Si une suppression a besoin d'une condition écrite à la main (attribute_exists, une vérification de version), construis l'exacte ConditionExpression + les maps de placeholders dans le DynamoDB Expression Builder et attache-la à un DeleteItem ou à une transaction.

FAQ

Puis-je supprimer plusieurs items en un seul appel DynamoDB ? Oui — jusqu'à 25 avec BatchWriteItem (au mieux, réessaie les UnprocessedItems) ou jusqu'à 100 de façon atomique avec TransactWriteItems. Les deux exigent une clé primaire complète par item ; aucun n'accepte de condition « where » pour sélectionner les items.

Y a-t-il un DELETE WHERE dans DynamoDB ? Non. Ni l'API bas niveau ni PartiQL ne peuvent supprimer par condition — le DELETE de PartiQL exige un WHERE qui « se résout en une seule valeur de clé primaire ». Tu requêtes ou scannes d'abord pour les clés, puis supprimes chacune.

Comment supprimer tous les items d'une table DynamoDB ? Pour un nettoyage complet, supprime et recrée la table — ça évite de payer une écriture par item. Pour un nettoyage basé sur l'âge, utilise le TTL, qui supprime les items expirés sans consommer de capacité d'écriture. Scan + suppression par lots est le plan de repli quand la table doit rester en service.

Pourquoi des items réapparaissent-ils après ma suppression par lots ? Presque toujours des UnprocessedItems non réessayés : un BatchWriteItem throttlé renvoie silencieusement les suppressions échouées dans la réponse, et un code qui ne boucle pas dessus « termine » avec des items encore dans la table. Réessaie avec un backoff exponentiel jusqu'à ce que la map revienne vide.

Combien coûte la suppression d'items ? Chaque suppression est une écriture standard (une WCU par tranche de 1 Ko, doublée dans une transaction), et trouver les clés coûte aussi des lectures. Estime les dégâts avec le calculateur de prix.

Tu préfères voir ce que tu supprimes d'abord ? Télécharge DynoTable — sélectionne les lignes, mets les suppressions en attente avec ⌘⌫, revois les diffs, et valide quand tu es sûr.