Comment voir, parcourir et éditer des données DynamoDB

Chaque « look at » ou « change » que tu fais à un table DynamoDB mappe à l'une d'un petit set d'opérations API — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem. Il n'y a pas de table viewer relationnel en dessous : « browse un table » est littéralement un Scan, et « éditer une ligne » est un UpdateItem contre une . Savoir quelle opération chaque clic mappe est la différence entre une lecture bon marché et un scan full-table que tu ne voulais pas lancer.

DynoTable est un GUI par-dessus exactement ces opérations — il te montre laquelle tu es sur le point de lancer, et le coût, avant que ça touche le wire.

Comment parcourir un table DynamoDB

Ouvrir un table pour « voir ce qu'il y a dedans » est un Scan — il lit chaque item du table ou de l'index (AWS : « A Scan operation in Amazon DynamoDB reads every item in a table or a secondary index. »). Fine pour les petits tables ; sur un grand c'est le footgun de coût classique couvert dans query vs scan.

Un seul Scan renvoie au plus 1 MB de données, puis te tend une LastEvaluatedKey pour fetch la page suivante — donc « browse tout le table » est vraiment une boucle de pagination (AWS : « A single Scan request can retrieve a maximum of 1 MB of data » et « the LastEvaluatedKey from a Scan response should be used as the ExclusiveStartKey for the next Scan request »). Vois pagination pour comment le curseur marche et pourquoi les numéros de page style offset n'existent pas ici.

Comment filter / scanner des données DynamoDB

Un ne te sauve pas un scan. DynamoDB applique le filter après que la lecture complete, donc tu paies pour chaque item scanné — pas seulement les lignes que tu gardes.

A filter expression is applied after a Scan finishes but before the results are returned. Therefore, a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present. — documentation AWS du Scan

La réponse rend ça visible : ScannedCount est « the number of items evaluated, before any ScanFilter is applied » tandis que Count est ce qui a survécu au filter (AWS). Un haut ScannedCount avec un minuscule Count est la signature d'un scan inefficace.

Comment query un table DynamoDB

Un Query est la lecture cheap, ciblée — mais il requiert une partition key. Per AWS : « You must provide the name of the partition key attribute and a single value for that attribute. Query returns all items with that partition key value. Optionally, you can provide a sort key attribute and use a comparison operator to refine the search results. »

Donc un Query ne lit que les items sous une partition key, optionnellement restreints par une condition de sort key — jamais tout le table. Pas de partition key, pas de Query : tu es de retour à un Scan. Ce choix est la décision de coût la plus importante dans DynamoDB ; le breakdown complet est dans query vs scan.

En on-demand us-east-1, ouvrir un table pour le « browse » lance un Scan paginé qui facture 0.5 RCU par 4 KB eventually-consistent par item examiné — un scroll GUI à travers un table de 10 GB de lignes de 1 KB est de l'ordre de 2.5 millions de RCU si tu charges tout. Un Query ciblé sur une partition key ne lit que cette item collection. Estime browse vs query dans le calculateur de pricing.

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

Comment éditer un item dans DynamoDB

Éditer un item est un UpdateItem contre sa primary key complète. Tu ne réécris pas tout l'item — tu fournis un nommant seulement les attributs que tu changes :

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

Deux faits qui piègent les gens, tous deux depuis les AWS items docs :

Tu dois spécifier la primary key entière, pas juste une partie. Sur un table c'est partition key et sort key. Tu ne peux pas « éditer une ligne » par un attribut arbitraire — ça a besoin d'un scan pour trouver la clé d'abord.
UpdateItem est un upsert. « If an item with the specified key does not exist, UpdateItem creates a new item. Otherwise, it modifies an existing item's attributes. » Une typo dans la clé crée silencieusement un nouvel item au lieu d'error.

Comment supprimer un item

Un DeleteItem, encore keyed par la primary key complète : « DeleteItem deletes the item with the specified key » (AWS). Même règle que l'édition — tu as besoin de toute la clé, donc supprimer « toutes les lignes où status = 'open' » n'est pas un appel ; tu scan/query pour trouver les clés, puis delete chacune. BatchWriteItem bundle jusqu'à 25 requêtes put/delete (AWS : « The BatchWriteItem operation can contain up to 25 individual PutItem and DeleteItem requests »), mais chacune cible encore une clé — il n'y a pas de DELETE … WHERE.

Comment voir des données nested / JSON

Les items DynamoDB sont stockés dans un format wire type-tagged (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 AWS data types docs). Le JSON plain n'a pas de type set, donc un array round-trip comme list (L), jamais string set (SS) — une vraie limitation de conversion, pas un bug d'affichage. La map de types complète est dans types de données DynamoDB ; pour convertir un blob DynamoDB-JSON vers plain JSON et retour, utilise le convertisseur JSON DynamoDB.

Au-delà de browse-and-edit : querying que DynamoDB ne peut pas

Scan/Query/UpdateItem couvrent view et edit, mais ils ne peuvent pas analyser — DynamoDB n'a ni JOIN, ni GROUP BY, ni fonctions d'agrégat comme COUNT/SUM, et PartiQL ne les ajoute pas non plus : sa grammaire SELECT est juste SELECT … FROM table [WHERE …] [ORDER BY …], sans clause join ou grouping (référence AWS du SELECT PartiQL), donc chaque instruction mappe à un seul Get/Query/Scan/Put/Update/Delete. Le SQL Workbench de DynoTable comble ce gap en matérialisant tes tables via le vrai runtime de query DynamoDB et en lançant du SQL par-dessus — SQL dans les règles des modèles d'accès DynamoDB — mais pour le browse-and-edit du quotidien, les opérations ci-dessus sont toute la toolbox.

FAQ

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

Comment éditer un item DynamoDB ? Émets un UpdateItem contre la primary key complète de l'item avec un update expression SET nommant seulement les attributs que tu changes. Dans un GUI, inline-édite la cellule — ça compile vers cet UpdateItem pour toi.

Pourquoi filter coûte encore un full scan ? Parce que DynamoDB applique le filter après que le scan lit les items. Les items filtrés-out sont encore lus et mesurés. Pour couper le coût, query par une partition key (ou un GSI) au lieu de scanner.

Puis-je update beaucoup d'items à la fois ? Il n'y a pas de UPDATE … WHERE — chaque UpdateItem/DeleteItem cible une seule primary key. Pour changer plusieurs items dans une requête atomique, TransactWriteItems applique jusqu'à 100 write actions (incluant Update) qui réussissent toutes ou rollback toutes. Sinon tu scan/query pour collecter les clés, puis écris chacune (jusqu'à 25 par BatchWriteItem).

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

Envie de browse, filter et inline-éditer des tables DynamoDB — et lancer le SQL que PartiQL ne peut pas ? Télécharge DynoTable.