SQL für DynamoDB: Was geht, was nicht, und die Workbench

DynamoDB ist ein NoSQL-Key-Value-Store, aber es beantwortet SQL-förmige Fragen mehr, als man erwartet — und weit weniger, als man hofft. Das ist die ehrliche Landkarte: welches SQL-auf-DynamoDB du tatsächlich out of the box bekommst, wo es aufhört, und die wenigen Wege, die JOIN / GROUP BY / Aggregat-Abfragen auszuführen, die die native Oberfläche nicht ausdrücken kann.

Kann man DynamoDB mit SQL abfragen? Die kurze Antwort

Teilweise. DynamoDB liefert PartiQL, das die AWS-Doku als „eine SQL-kompatible Abfragesprache, um Daten in Amazon DynamoDB auszuwählen, einzufügen, zu aktualisieren und zu löschen" beschreibt. Du kannst also SELECT * FROM "Orders" WHERE OrderID = 100 schreiben, und es funktioniert.

Aber PartiQL ist eine SQL-kompatible Oberfläche über die DynamoDB-API, keine SQL-Engine. Es spricht die Syntax; es fügt keine relationale Abfragemacht hinzu. AWS ist explizit, dass „Amazon DynamoDB eine Teilmenge der PartiQL-Abfragesprache unterstützt" (Referenz). In dem Moment, in dem du nach einem JOIN, einem GROUP BY oder COUNT(*) greifst, bist du außerhalb dessen, was PartiQL kann — siehe PartiQL vs SQL für den vollständigen Feature-für-Feature-Vergleich.

PartiQL: eine SQL-kompatible Oberfläche, keine SQL-Engine

PartiQL bildet SQL-aussehende Statements auf dieselben Data-Plane-Operationen ab, die das SDK offenlegt. Ein SELECT mit Partition-Key-Gleichheit kompiliert zu einer Query; ein SELECT ohne kompiliert zu einem Scan. Laut der AWS-SELECT-Referenz:

Die Verwendung des SELECT-Statements kann zu einem vollständigen Tabellen-Scan führen, wenn keine Gleichheits- oder IN-Bedingung mit einem Partition Key in der WHERE-Klausel angegeben ist.

Also gelten dieselben Zugriffsmuster-Regeln, die Query und Scan regieren, weiterhin — PartiQL versteckt sie nur hinter vertrauter Syntax. Es fügt keinen Query-Planner, keine Joins und keine mengenbasierte Aggregation hinzu. Jedes Statement kollabiert zu einer nativen Operation:

Wenn eine Operation sich nicht auf ein einzelnes Get/Query/Scan/Put/Update/Delete reduziert, kann PartiQL sie schlicht nicht ausdrücken. Alles unten ist eine Folge dieser einen Tatsache.

Was PartiQL abdeckt

DynamoDBs PartiQL unterstützt vier DML/Query-Statements:

• SELECT — Items lesen (kompiliert zu Query oder Scan)
• INSERT — ein Item hinzufügen (PutItem)
• UPDATE — ein Item ändern (UpdateItem)
• DELETE — ein Item entfernen (DeleteItem)

Es unterstützt außerdem Transaktionen und Batch-Operationen. Ein wohlgeformter Read zielt mit einer Gleichheit oder IN auf den Partition Key:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY ist erlaubt, aber die AWS-Referenz beschränkt den Ordnungsschlüssel auf „a hash key or a sort key" — den Partition oder Sort Key, nicht beliebige Spalten. Das ist die Obergrenze dessen, was PartiQLs SELECT akzeptiert. Für copy-paste-fertige Statements siehe PartiQL-Beispiele.

Was PartiQL nicht kann

Das sind die Dinge, die Entwickler am häufigsten von „SQL" erwarten, und PartiQL unterstützt keines davon:

• Kein JOIN. Die PartiQL-SELECT-Syntax ist ein einzelnes FROM {{table}}[.{{index}}] — eine Tabelle oder ein Index, nie zwei über einen Schlüssel verbundene Tabellen. Das ist der Single-Table-Design-Trade-off: Du modellierst vorab für deine Zugriffsmuster, weil die Abfrageschicht Daten nachträglich nicht umformen kann.
• Kein GROUP BY. Es ist nicht in der Grammatik; es gibt keine Klausel zum Gruppieren von Zeilen.
• Keine Aggregatfunktionen. Die PartiQL-Funktionsreferenz listet genau eine Funktion unter „Aggregate functions": SIZE, das die Größe eines Attributs in Bytes für ein einzelnes Item zurückgibt. Es gibt kein COUNT, SUM, AVG, MIN oder MAX über Zeilen. AWS sagt klar: „Alle SQL-Funktionen, die nicht in dieser Liste enthalten sind, werden in DynamoDB derzeit nicht unterstützt."
• Kein LIKE, keine Subqueries, kein UNION, keine Window-Funktionen. Pattern Matching nutzt contains / begins_with; der Rest hat überhaupt kein Äquivalent.

Also „Gesamtumsatz pro Kunde letzten Monat" — ein einzeiliges GROUP BY in jeder relationalen Datenbank — kann in PartiQL nicht ausgedrückt werden. Du würdest die Daten herausscannen und im Anwendungscode aggregieren.

Der einzige Weg, echtes JOIN / GROUP BY / Aggregat-Verhalten über DynamoDB-Daten zu bekommen, ist ein Tool, das eine tatsächliche SQL-Engine obendrauf ausführt. Es gibt zwei: Amazon Athenas föderierten Connector und DynoTables SQL Workbench.

So fragst du DynamoDB mit echtem SQL über Amazon Athena ab

AWS' eigene Antwort auf „echtes SQL über DynamoDB" ist der Amazon-Athena-DynamoDB-Connector, der „es Amazon Athena ermöglicht, mit DynamoDB zu kommunizieren, sodass du deine Tabellen mit SQL abfragen kannst." Weil Athena eine vollständige SQL-Engine ist, bekommst du damit JOIN und Aggregate — AWS' Walkthrough trägt den Titel „Access, query, and join Amazon DynamoDB tables using Athena."

Der Haken sind Setup und Kosten:

• Es ist ein Lambda-basierter föderierter Connector, den du in dein Konto deployst (über die Athena-Konsole oder das Serverless Application Repository), verdrahtet über AWS Glue für Schema und Ergebnis-Spilling in einen S3-Bucket (Connector-Doku).
• Unter der Haube nutzt es weiterhin DynamoDBs Query- und Scan-API-Operationen. AWS warnt, dass „Abfragen, die Scans verwenden, eine große Anzahl von Read Capacity Units (RCUs) verbrauchen können", also liest — und misst — eine analytische Abfrage über eine große Tabelle viele Items (Connector-Kosten). Nutze den Item-Size-Rechner, um abzuschätzen, was eine scan-lastige Abfrage kosten wird.
• Schreiboperationen wie INSERT INTO werden über den Connector nicht unterstützt.

Athena ist das richtige Werkzeug für geplante Analytik und BI-Dashboards. Es ist schwergewichtig für den alltäglichen „Ich muss nur zwei Tabellen joinen und das Ergebnis ansehen"-Fall — das ist die Lücke, die der nächste Abschnitt füllt.

DynoTable SQL Workbench: SQL innerhalb von DynamoDBs Zugriffsmuster-Regeln

DynoTables SQL Workbench führt echtes SQL aus — JOIN, GROUP BY, COUNT/SUM/AVG — gegen deine Live-DynamoDB-Tabellen aus einem Desktop-Client, ohne Lambda, Glue oder S3 aufzubauen. Sie materialisiert die Zeilen durch DynamoDBs echte Query/Scan-Runtime und führt dann dein volles SQL in einer In-Memory-Engine obendrauf aus:

-- Läuft in der DynoTable Workbench (NICHT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

Der „innerhalb von DynamoDBs Zugriffsmuster-Regeln"-Teil ist wichtig. Die Workbench gibt nicht vor, DynamoDB sei Postgres — sie liest weiterhin unter der Haube über Query/Scan, also bleibst du dir bewusst, was jede Abfrage kostet, und sie setzt DynamoDBs Zugriffsmodell durch, statt es zu verstecken:

• Nur INNER JOIN und LEFT JOIN — das ON-Zielattribut muss ein Partition Key oder GSI-Partition Key sein. Kein RIGHT / FULL / CROSS / Komma-Join.
• Noch keine Self-Joins, keine Subqueries, keine abgeleiteten Tabellen, keine Window-Funktionen.
• Joins und Projektionen arbeiten auf skalaren Attributen.

Wenn du nur die Bedingungen und Schlüsselausdrücke für die rohe API zusammenstellen musst — kein volles SQL-Statement — generiert der DynamoDB Expression Builder die korrekte FilterExpression / KeyConditionExpression ganz ohne die PartiQL-Oberfläche.

Wenn dein Ziel ein DynamoDB-SQL-Client zum Erkunden, Debuggen und Analysieren von Tabellen ist, füllt die Workbench diese Lücke — und der Rest von DynoTable ist eine vollständige DynamoDB-GUI drumherum.

Probiere DynoTable, um echtes SQL gegen deine eigenen Tabellen auszuführen.

FAQ

Kann man SQL auf DynamoDB ausführen? Du kannst PartiQL ausführen, eine SQL-kompatible Teilmenge (SELECT/INSERT/UPDATE/DELETE per Schlüssel). Für volles SQL — JOIN, GROUP BY, Aggregate — brauchst du eine SQL-Engine obendrauf: den Amazon-Athena-DynamoDB-Connector oder DynoTables SQL Workbench.

Unterstützt DynamoDB-PartiQL JOIN? Nein. Die PartiQL-SELECT-Syntax hat eine einzelne FROM-Tabelle oder einen Index und keine Join-Grammatik. Joins erfordern eine Engine, die über DynamoDB geschichtet ist.

Unterstützt PartiQL GROUP BY oder Aggregate wie COUNT und SUM? Nein. Es gibt keine GROUP BY-Klausel, und die einzige „Aggregat"-Funktion ist SIZE (die Byte-Größe eines Attributs für ein Item). COUNT, SUM, AVG, MIN und MAX über Zeilen werden nicht unterstützt.

Ist DynamoDB SQL oder NoSQL? NoSQL — ein Key-Value- und Dokument-Store. PartiQL fügt obendrauf eine SQL-kompatible Abfragesprache hinzu, aber DynamoDB hat keine relationale Engine, keine Joins oder Aggregate.

Ist PartiQL gut für Ad-hoc-Abfragen? Für schlüsselbasierte Lookups ja. Für analytische Ad-hoc-Abfragen (Zählungen, Rollups, Joins) nein — PartiQL kann sie nicht ausdrücken, und unbeschränkte SELECTs werden stillschweigend zu vollständigen Tabellen-Scans.

Gibt es einen DynamoDB-SQL-Client, der JOIN und GROUP BY beherrscht? Ja — DynoTables SQL Workbench führt JOIN/GROUP BY/Aggregate gegen Live-Tabellen vom Desktop aus, und Amazon Athena tut es über einen föderierten Connector, den du in deinem AWS-Konto deployst.