So betrachtest, durchsuchst und bearbeitest du DynamoDB-Daten

Jedes „Ansehen" oder „Ändern", das du an einer DynamoDB-Tabelle vornimmst, bildet auf eine aus einem kleinen Satz von API-Operationen ab — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem. Darunter liegt kein relationaler Tabellen-Viewer: „eine Tabelle durchsuchen" 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 Read und einem vollständigen Tabellen-Scan, den du nicht beabsichtigt hast.

DynoTable ist eine GUI über genau diese Operationen — es zeigt dir, welche du gleich ausführst, und die Kosten, bevor es das Netz erreicht.

So durchsuchst du eine DynamoDB-Tabelle

Eine Tabelle zu öffnen, um „zu sehen, was drin ist", ist ein Scan — es liest jedes Item der Tabelle oder des Index (AWS: „Eine Scan-Operation in Amazon DynamoDB liest jedes Item einer Tabelle oder eines Secondary Index."). Gut für kleine Tabellen; bei einer großen ist es der klassische Kosten-Footgun, der in Query vs Scan behandelt wird.

Ein einzelner Scan liefert höchstens 1 MB Daten zurück und reicht dir dann einen LastEvaluatedKey, um die nächste Seite abzurufen — also ist „die ganze Tabelle durchsuchen" eigentlich eine Paginierungsschleife (AWS: „Eine einzelne Scan-Anfrage kann maximal 1 MB an Daten abrufen" und „der LastEvaluatedKey aus einer Scan-Antwort sollte als ExclusiveStartKey für die nächste Scan-Anfrage verwendet werden"). Siehe Paginierung, wie der Cursor funktioniert und warum es hier keine offset-artigen Seitenzahlen gibt.

So filterst / scannst du DynamoDB-Daten

Die Falle: Ein Filter-Ausdruck erspart dir keinen Scan. DynamoDB wendet den Filter nachdem der Read abgeschlossen ist an, also zahlst du für jedes gescannte Item — nicht nur für die Zeilen, die du behältst.

Ein Filter-Ausdruck wird angewendet, nachdem ein Scan abgeschlossen ist, aber bevor die Ergebnisse zurückgegeben werden. Daher verbraucht ein Scan dieselbe Menge an Lesekapazität, unabhängig davon, ob ein Filter-Ausdruck vorhanden ist. — AWS Scan docs

Die Antwort macht das sichtbar: ScannedCount ist „die Anzahl der ausgewerteten Items, bevor irgendein ScanFilter angewendet wird", während Count das ist, was den Filter überlebt hat (AWS). Ein hoher ScannedCount mit einem winzigen Count ist die Signatur eines ineffizienten Scans.

So fragst du eine DynamoDB-Tabelle ab

Eine Query ist der günstige, gezielte Read — aber sie erfordert einen Partition Key. Laut AWS: „Du musst den Namen des Partition-Key-Attributs und einen einzelnen Wert für dieses Attribut angeben. Query gibt alle Items mit diesem Partition-Key-Wert zurück. Optional kannst du ein Sort-Key-Attribut angeben und einen Vergleichsoperator verwenden, um die Suchergebnisse einzugrenzen."

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: Du bist zurück bei einem Scan. Diese Wahl ist die wichtigste Kostenentscheidung in DynamoDB; die vollständige Aufschlüsselung steht in Query vs Scan.

Um die KeyConditionExpression / FilterExpression zusammenzusetzen, ohne die Platzhalter-Syntax von Hand zu schreiben, nutze den DynamoDB Expression Builder — er gibt die exakten Names-/Values-Maps aus, die die API erwartet.

So bearbeitest du ein Item in DynamoDB

Ein Item zu bearbeiten ist ein UpdateItem gegen seinen vollständigen Primary Key. Du schreibst nicht das ganze Item neu — du lieferst einen Update-Ausdruck, der nur die Attribute benennt, die du änderst:

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

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

Du musst den gesamten Primary Key angeben, nicht nur einen Teil davon. Bei einer Tabelle mit zusammengesetztem Schlüssel ist das Partition Key und Sort Key. Du kannst eine „Zeile" nicht über ein beliebiges Attribut bearbeiten — das braucht zuerst einen Scan, um den Schlüssel zu finden.
UpdateItem ist ein Upsert. „Wenn ein Item mit dem angegebenen Schlüssel nicht existiert, erstellt UpdateItem ein neues Item. Andernfalls ändert es die Attribute eines bestehenden Items." Ein Tippfehler im Schlüssel erzeugt stillschweigend ein neues Item, statt zu fehlen.

So löschst du ein Item

Ein DeleteItem, wieder über den vollständigen Primary Key: „DeleteItem löscht das Item mit dem angegebenen Schlüssel" (AWS). Gleiche Regel wie beim Bearbeiten — du brauchst den ganzen Schlüssel, also ist „alle Zeilen löschen, wo status = 'open'" kein einzelner Aufruf; du scannst/fragst ab, um die Schlüssel zu finden, dann löschst du jeden einzeln. BatchWriteItem bündelt bis zu 25 Put/Delete-Requests (AWS: „Die BatchWriteItem-Operation kann bis zu 25 einzelne PutItem- und DeleteItem-Anfragen enthalten"), aber jeder zielt weiterhin auf einen Schlüssel — es gibt kein DELETE … WHERE.

So betrachtest du verschachtelte / JSON-Daten

DynamoDB-Items werden in einem typ-getaggten Wire-Format (DynamoDB-JSON) gespeichert, wo jeder Wert einen ein- oder zweibuchstabigen Typ-Deskriptor trägt (S, N, M, L, SS… — die vollständige Deskriptorliste steht in der AWS-Datentypen-Doku). Schlichtes JSON hat keinen Set-Typ, also macht ein Array einen Round-Trip als Liste (L), nie als String-Set (SS) — eine echte Konvertierungs-Beschränkung, kein Anzeigefehler. Die vollständige Typ-Map steht in DynamoDB-Datentypen; um einen DynamoDB-JSON-Blob nach schlichtem JSON und zurück zu konvertieren, nutze den DynamoDB-JSON-Konverter.

Jenseits von Browse-and-Edit: Abfragen, die DynamoDB nicht kann

Scan/Query/UpdateItem decken Ansehen und Bearbeiten ab, aber sie können nicht analysieren — DynamoDB hat kein JOIN, GROUP BY oder Aggregatfunktionen wie COUNT/SUM, und PartiQL fügt sie auch nicht hinzu: Seine SELECT-Grammatik ist nur SELECT … FROM table [WHERE …] [ORDER BY …], ohne Join- oder Gruppierungsklausel (AWS-PartiQL-SELECT-Referenz), also bildet jedes Statement auf ein einzelnes Get/Query/Scan/Put/Update/Delete ab. DynoTables SQL Workbench füllt diese Lücke, indem sie deine Tabellen durch DynamoDBs echte Query-Runtime materialisiert und SQL obendrauf ausführt — SQL innerhalb von DynamoDBs Zugriffsmuster-Regeln — aber für das tägliche Browse-and-Edit sind die obigen Operationen der gesamte Werkzeugkasten.

FAQ

Wie betrachte ich DynamoDB-Daten ohne die AWS-Konsole? Nutze eine Desktop-GUI, die dieselben Scan/Query-Aufrufe absetzt. Die AWS-Konsole durchsucht Tabellen über paginierte Scans; ein dedizierter Client wie DynoTable tut dasselbe, zeigt aber die verbrauchte Kapazität und die Operation, die du ausführst.

Wie bearbeite ich ein DynamoDB-Item? Setze ein UpdateItem gegen den vollständigen Primary Key des Items mit einem SET-Update-Ausdruck ab, der nur die Attribute benennt, die du änderst. In einer GUI bearbeite die Zelle inline — es kompiliert für dich zu diesem UpdateItem.

Warum kostet Filtern weiterhin einen vollständigen Scan? Weil DynamoDB den Filter nachdem der Scan die Items gelesen hat anwendet. Herausgefilterte Items werden trotzdem gelesen und gemessen. Um Kosten zu senken, frage nach einem Partition Key (oder einem GSI) ab, statt zu scannen.

Kann ich viele Items auf einmal aktualisieren? Nicht in einem Aufruf. UpdateItem/DeleteItem zielen jeweils auf einen einzelnen Primary Key; es gibt kein UPDATE … WHERE. Du scannst/fragst ab, um die Schlüssel zu sammeln, dann schreibst du jeden (bis zu 25 pro BatchWriteItem).

Kann ich eine DynamoDB-Local-Tabelle auf dieselbe Weise durchsuchen? Ja — richte dieselbe GUI auf den lokalen Endpoint. Siehe DynamoDB Local.

Willst du DynamoDB-Tabellen durchsuchen, filtern und inline bearbeiten — und das SQL ausführen, das PartiQL nicht kann? Lade DynoTable herunter.