Comment voir, parcourir et modifier des données DynamoDB

Chaque « regarder » ou « changer » que tu fais sur une table DynamoDB se mappe à l'une d'un petit jeu d'opérations API — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem. Il n'y a pas de visualiseur de table relationnelle en dessous : « parcourir une table » est littéralement un Scan, et « modifier une ligne » est un UpdateItem contre une clé primaire. Savoir à quelle opération chaque clic se mappe fait la différence entre une lecture bon marché et un scan complet de table que tu n'avais pas l'intention de lancer.

DynoTable est un GUI au-dessus de ces opérations exactement — il te montre laquelle tu es sur le point de lancer, et le coût, avant qu'elle n'atteigne le fil.

Comment parcourir une table DynamoDB

Ouvrir une table pour « voir ce qu'il y a dedans » est un Scan — il lit chaque item de la table ou de l'index (AWS : « Une opération Scan dans Amazon DynamoDB lit chaque item d'une table ou d'un index secondaire. »). Bien pour les petites tables ; sur une grande, c'est le classique piège de coût couvert dans query vs scan.

Un seul Scan renvoie au plus 1 Mo de données, puis te remet un LastEvaluatedKey pour récupérer la page suivante — donc « parcourir la table entière » est en réalité une boucle de pagination (AWS : « Une seule requête Scan peut récupérer un maximum de 1 Mo de données » et « le LastEvaluatedKey d'une réponse Scan doit être utilisé comme ExclusiveStartKey pour la requête Scan suivante »). Voir pagination pour comprendre comment fonctionne le curseur et pourquoi les numéros de page de style offset n'existent pas ici.

Comment filtrer / scanner des données DynamoDB

Le piège : une expression de filtre ne t'évite pas un scan. DynamoDB applique le filtre après la fin de la lecture, donc tu paies pour chaque item scanné — pas seulement les lignes que tu gardes.

Une expression de filtre est appliquée après la fin d'un Scan mais avant que les résultats ne soient renvoyés. Par conséquent, un Scan consomme la même quantité de capacité de lecture, qu'une expression de filtre soit présente ou non. — docs Scan d'AWS

La réponse le rend visible : ScannedCount est « le nombre d'items évalués, avant l'application de tout ScanFilter » tandis que Count est ce qui a survécu au filtre (AWS). Un ScannedCount élevé avec un Count minuscule est la signature d'un scan inefficace.

Comment interroger une table DynamoDB

Un Query est la lecture bon marché et ciblée — mais il requiert une clé de partition. Selon AWS : « Tu dois fournir le nom de l'attribut de clé de partition et une valeur unique pour cet attribut. Query renvoie tous les items ayant cette valeur de clé de partition. En option, tu peux fournir un attribut de clé de tri et utiliser un opérateur de comparaison pour affiner les résultats de recherche. »

Donc un Query lit seulement les items sous une clé de partition, éventuellement réduits par une condition de clé de tri — jamais la table entière. Pas de clé de partition, pas de Query : tu reviens à un Scan. Ce choix est la décision de coût la plus importante de DynamoDB ; le détail complet est dans query vs scan.

Pour assembler la KeyConditionExpression / FilterExpression sans écrire à la main la syntaxe des placeholders, utilise le Expression Builder DynamoDB — il émet les maps exactes de noms/valeurs que l'API attend.

Comment modifier un item dans DynamoDB

Modifier un item est un UpdateItem contre sa clé primaire complète. Tu ne réécris pas l'item entier — tu fournis une expression de mise à jour nommant seulement les attributs que tu changes :

UpdateItem
  Key:              { "PK": "USER#42", "SK": "PROFILE" }
  UpdateExpression: SET email = :e, updatedAt = :t

Deux faits qui font trébucher, tous deux issus des docs items d'AWS :

Tu dois spécifier la clé primaire entière, pas juste une partie. Sur une table à clé composite, c'est clé de partition et clé de tri. Tu ne peux pas « modifier une ligne » par un attribut arbitraire — ça nécessite un scan pour trouver d'abord la clé.
UpdateItem est un upsert. « Si un item avec la clé spécifiée n'existe pas, UpdateItem crée un nouvel item. Sinon, il modifie les attributs d'un item existant. » Une faute de frappe dans la clé crée silencieusement un nouvel item au lieu de lever une erreur.

Comment supprimer un item

Un DeleteItem, là encore clavé par la clé primaire complète : « DeleteItem supprime l'item avec la clé spécifiée » (AWS). Même règle que la modification — tu as besoin de la clé entière, donc supprimer « toutes les lignes où status = 'open' » n'est pas un appel ; tu scannes/interroges pour trouver les clés, puis supprimes chacune. BatchWriteItem regroupe jusqu'à 25 requêtes put/delete (AWS : « L'opération BatchWriteItem peut contenir jusqu'à 25 requêtes individuelles PutItem et DeleteItem »), mais chacune cible toujours une clé — il n'y a pas de DELETE … WHERE.

Comment voir les données imbriquées / JSON

Les items DynamoDB sont stockés dans un format de fil typé (DynamoDB-JSON), où chaque valeur porte un descripteur de type d'une ou deux lettres (S, N, M, L, SS… — la liste complète des descripteurs est dans les docs types de données d'AWS). Le JSON ordinaire n'a pas de type set, donc un tableau fait un aller-retour en tant que liste (L), jamais un set de chaînes (SS) — une vraie limitation de conversion, pas un bug d'affichage. La carte complète des types est dans types de données DynamoDB ; pour convertir un blob DynamoDB-JSON en JSON ordinaire et inversement, utilise le convertisseur JSON DynamoDB.

Au-delà du parcourir-et-modifier : les requêtes que DynamoDB ne peut pas

Scan/Query/UpdateItem couvrent la visualisation et la modification, mais ils ne peuvent pas analyser — DynamoDB n'a pas de JOIN, GROUP BY, ni de fonctions d'agrégation comme COUNT/SUM, et PartiQL ne les ajoute pas non plus : sa grammaire SELECT est juste SELECT … FROM table [WHERE …] [ORDER BY …], sans clause de jointure ni de groupement (référence SELECT PartiQL d'AWS), donc chaque instruction se mappe à un unique Get/Query/Scan/Put/Update/Delete. Le SQL Workbench de DynoTable comble cet écart en matérialisant tes tables à travers le runtime de requête réel de DynamoDB et en exécutant du SQL par-dessus — du SQL dans le cadre des règles d'access-pattern de DynamoDB — mais pour le parcourir-et-modifier du quotidien, les opérations ci-dessus sont toute la boîte à outils.

FAQ

Comment voir des données DynamoDB sans la console AWS ? Utilise un GUI de bureau qui émet les mêmes appels Scan/Query. La console AWS parcourt les tables via des scans paginés ; un client dédié comme DynoTable fait pareil mais montre la capacité consommée et l'opération que tu lances.

Comment modifier un item DynamoDB ? Émets un UpdateItem contre la clé primaire complète de l'item avec une expression de mise à jour SET nommant seulement les attributs que tu changes. Dans un GUI, modifie la cellule en ligne — ça se compile en ce UpdateItem pour toi.

Pourquoi filtrer coûte-t-il quand même un scan complet ? Parce que DynamoDB applique le filtre après que le scan a lu les items. Les items filtrés sont quand même lus et facturés. Pour réduire le coût, interroge par une clé de partition (ou un GSI) au lieu de scanner.

Puis-je mettre à jour plusieurs items à la fois ? Pas en un appel. UpdateItem/DeleteItem ciblent chacun une seule clé primaire ; il n'y a pas de UPDATE … WHERE. Tu scannes/interroges pour collecter les clés, puis écris chacune (jusqu'à 25 par BatchWriteItem).

Puis-je parcourir une table DynamoDB Local de la même façon ? Oui — pointe le même GUI sur l'endpoint local. Voir DynamoDB Local.

Tu veux parcourir, filtrer et modifier en ligne des tables DynamoDB — et exécuter le SQL que PartiQL ne peut pas ? Télécharge DynoTable.