DynamoDB-Daten ansehen, durchstöbern und bearbeiten

Jedes „Ansehen“ und jedes „Ändern“ an einer DynamoDB-Tabelle bildet auf eine kleine Menge von API-Operationen ab — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem. Darunter liegt kein relationaler Tabellen-Viewer: „eine Tabelle durchstöbern“ ist buchstäblich ein Scan, und „eine Zeile bearbeiten“ ist ein UpdateItem gegen einen Primary Key. Zu wissen, auf welche Operation jeder Klick abbildet, ist der Unterschied zwischen einem günstigen Lesevorgang und einem Full-Table-Scan, den du gar nicht ausführen wolltest.

DynoTable ist eine GUI über genau diesen Operationen — es zeigt dir, welche du gleich ausführst, und was sie kostet, bevor sie auf die Leitung geht.

Wie du eine DynamoDB-Tabelle durchstöberst

Eine Tabelle zu öffnen, um „zu sehen, was drin ist“, ist ein Scan — er liest jedes Item in der Tabelle oder im Index (AWS: "A Scan operation in Amazon DynamoDB reads every item in a table or a secondary index."). Bei kleinen Tabellen kein Problem; bei einer großen ist es das klassische Kostenfootgun, das Query vs. Scan behandelt.

Ein einzelner Scan gibt höchstens 1 MB Daten zurück und reicht dir dann einen LastEvaluatedKey, um die nächste Seite zu holen — „die ganze Tabelle durchstöbern“ ist also in Wahrheit eine Paginierungsschleife (AWS: "A single Scan request can retrieve a maximum of 1 MB of data" und "the LastEvaluatedKey from a Scan response should be used as the ExclusiveStartKey for the next Scan request"). Wie der Cursor funktioniert und warum es hier keine Seitenzahlen im Offset-Stil gibt, steht in Paginierung.

Wie du DynamoDB-Daten filterst / scannst

Eine Filter Expression spart dir keinen Scan. DynamoDB wendet den Filter nach dem Lesevorgang an, du zahlst also für jedes gescannte Item — nicht nur für die Zeilen, die du behältst.

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. — AWS Scan docs

Die Antwort macht das sichtbar: ScannedCount ist "the number of items evaluated, before any ScanFilter is applied", während Count das ist, was den Filter überlebt hat (AWS). Ein hoher ScannedCount bei winzigem Count ist die Signatur eines ineffizienten Scans.

Wie du eine DynamoDB-Tabelle abfragst

Eine Query ist der günstige, gezielte Lesevorgang — sie verlangt aber einen Partition Key. Laut 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."

Eine Query liest also nur die Items unter einem Partition Key, optional eingegrenzt durch eine Sort-Key-Bedingung — nie die ganze Tabelle. Kein Partition Key, keine Query: Dann bist du wieder bei einem Scan. Diese Wahl ist die wichtigste Kostenentscheidung in DynamoDB; die vollständige Aufschlüsselung steht in Query vs. Scan.

Bei On-Demand in us-east-1 läuft beim Öffnen einer Tabelle zum „Durchstöbern“ ein seitenweiser Scan, der 0,5 RCU pro 4 KB letztendlich konsistent je geprüftem Item berechnet — ein GUI-Scroll durch eine 10 GB große Tabelle aus 1 KB großen Zeilen liegt in der Größenordnung von 2,5 Millionen RCU, wenn du alles lädst. Eine gezielte Query auf einen Partition Key liest nur diese Item Collection. Schätze Durchstöbern gegen Abfragen im Preisrechner.

Um die KeyConditionExpression / FilterExpression zusammenzusetzen, ohne die Platzhalter-Syntax von Hand zu schreiben, nimm den DynamoDB Expression Builder — er gibt genau die Namens-/Wert-Maps aus, die das API erwartet.

Wie du ein Item in DynamoDB bearbeitest

Ein Item zu bearbeiten ist ein UpdateItem gegen seinen vollständigen Primary Key. Du schreibst nicht das ganze Item neu — du lieferst eine Update Expression, die nur die Attribute nennt, die du änderst:

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

Zwei Punkte, über die Leute stolpern, beide aus der AWS-Doku zu Items:

• Du musst den vollständigen Primary Key angeben, nicht nur einen Teil davon. Auf einer Tabelle mit zusammengesetztem Schlüssel sind das Partition Key und Sort Key. Du kannst eine „Zeile“ nicht über ein beliebiges Attribut bearbeiten — dafür bräuchte es erst einen Scan, um den Key zu finden.
• UpdateItem ist ein Upsert. "If an item with the specified key does not exist, UpdateItem creates a new item. Otherwise, it modifies an existing item's attributes." Ein Tippfehler im Key legt still ein neues Item an, statt einen Fehler zu werfen.

Wie du ein Item löschst

Ein DeleteItem, wieder über den vollständigen Primary Key: "DeleteItem deletes the item with the specified key" (AWS). Dieselbe Regel wie beim Bearbeiten — du brauchst den ganzen Key, „alle Zeilen mit status = 'open' löschen“ ist also kein einzelner Aufruf; du scannst oder fragst ab, um die Keys zu finden, und löschst dann jeden einzeln. BatchWriteItem bündelt bis zu 25 Put-/Delete-Anfragen (AWS: "The BatchWriteItem operation can contain up to 25 individual PutItem and DeleteItem requests"), aber jede trifft weiterhin einen Key — ein DELETE … WHERE gibt es nicht.

Wie du verschachtelte Daten / JSON ansiehst

DynamoDB-Items werden in einem typmarkierten Wire-Format gespeichert (DynamoDB-JSON), in dem jeder Wert einen ein- oder zweibuchstabigen Typdeskriptor trägt (S, N, M, L, SS… — die vollständige Deskriptorliste steht in der AWS-Doku zu Datentypen). Reines JSON kennt keinen Set-Typ, ein Array kommt also als Liste (L) zurück, nie als String-Set (SS) — eine echte Konvertierungsgrenze, kein Anzeigefehler. Die vollständige Typtabelle steht in DynamoDB-Datentypen; um einen DynamoDB-JSON-Blob in reines JSON und zurück zu wandeln, nimm den DynamoDB-JSON-Konverter.

Jenseits von Ansehen und Bearbeiten: Abfragen, die DynamoDB nicht kann

Scan/Query/UpdateItem decken Ansehen und Bearbeiten ab, aber sie können nicht analysieren — DynamoDB hat kein JOIN, kein GROUP BY und keine Aggregatfunktionen wie COUNT/SUM, und PartiQL ergänzt sie ebenfalls nicht: Seine SELECT-Grammatik ist nur SELECT … FROM table [WHERE …] [ORDER BY …], ohne Join- und ohne Gruppierungsklausel (AWS-PartiQL-SELECT-Referenz), jedes Statement bildet also auf ein einzelnes Get/Query/Scan/Put/Update/Delete ab. Der SQL Workbench von DynoTable füllt diese Lücke, indem er deine Tabellen über die echte Query-Runtime von DynamoDB materialisiert und darüber SQL ausführt — SQL innerhalb der Zugriffsmuster-Regeln von DynamoDB —, aber für das tägliche Ansehen und Bearbeiten sind die Operationen oben der ganze Werkzeugkasten.

FAQ

Wie sehe ich DynamoDB-Daten ohne die AWS-Konsole an? Nimm eine Desktop-GUI, die dieselben Scan/Query-Aufrufe absetzt. Die AWS-Konsole durchstöbert Tabellen über seitenweise Scans; ein dedizierter Client wie DynoTable tut dasselbe, zeigt aber die verbrauchte Kapazität und die Operation an, die du gerade ausführst.

Wie bearbeite ich ein DynamoDB-Item? Setz ein UpdateItem gegen den vollständigen Primary Key des Items ab, mit einer SET-Update-Expression, die nur die Attribute nennt, die du änderst. In einer GUI bearbeitest du die Zelle inline — das kompiliert für dich zu genau diesem UpdateItem.

Warum kostet Filtern trotzdem einen vollen Scan? Weil DynamoDB den Filter nach dem Lesen der Items anwendet. Herausgefilterte Items werden trotzdem gelesen und gemessen. Um Kosten zu senken, frage über einen Partition Key (oder eine GSI) ab, statt zu scannen.

Kann ich viele Items auf einmal aktualisieren? Ein UPDATE … WHERE gibt es nicht — jedes UpdateItem/DeleteItem trifft einen einzelnen Primary Key. Um mehrere Items in einer atomaren Anfrage zu ändern, wendet TransactWriteItems bis zu 100 Schreibaktionen an (inklusive Update), die alle gelingen oder alle zurückgerollt werden. Andernfalls scannst oder fragst du ab, um die Keys zu sammeln, und schreibst dann jeden einzeln (bis zu 25 je BatchWriteItem).

Kann ich eine DynamoDB-Local-Tabelle genauso durchstöbern? Ja — richte dieselbe GUI auf den lokalen Endpoint. Siehe DynamoDB Local.

Du willst DynamoDB-Tabellen durchstöbern, filtern und inline bearbeiten — und das SQL fahren, das PartiQL nicht kann? Lade DynoTable herunter.