SQL für DynamoDB und die Grenzen von PartiQL

DynamoDB ist ein NoSQL-Key-Value-Store, beantwortet SQL-förmige Fragen aber häufiger, als man erwartet — und weit seltener, als man hofft. Hier die ehrliche Landkarte: welches SQL-auf-DynamoDB du ab Werk wirklich bekommst, wo es aufhört, und die wenigen Wege, die JOIN-/GROUP BY-/Aggregat-Abfragen zu fahren, die die native Oberfläche nicht ausdrücken kann.

Kann man DynamoDB mit SQL abfragen?

Teilweise. DynamoDB bringt PartiQL mit, eine SQL-kompatible Sprache für SELECT/INSERT/UPDATE/DELETE über den Key — SELECT * FROM "Orders" WHERE OrderID = 100 funktioniert also. Aber es ist eine SQL-kompatible Oberfläche über dem DynamoDB-API, keine SQL-Engine — AWS unterstützt nur eine Teilmenge, JOIN, GROUP BY und COUNT(*) fallen also weg. Dafür brauchst du eine Engine darüber.

AWS beschreibt PartiQL als "a SQL-compatible query language, to select, insert, update, and delete data in Amazon DynamoDB", sagt aber genauso deutlich: "Amazon DynamoDB supports a subset of the PartiQL query language." In dem Moment, in dem du zu einem JOIN, einem GROUP BY oder COUNT(*) greifst, bist du außerhalb dessen, was PartiQL kann — den vollständigen Vergleich Feature für Feature findest du in PartiQL vs. SQL.

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

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

Using the SELECT statement can result in a full table scan if an equality or IN condition with a partition key is not provided in the WHERE clause.

Es gelten also weiterhin dieselben Zugriffsmuster-Regeln wie für Query und Scan — PartiQL versteckt sie nur hinter vertrauter Syntax. Es ergänzt keinen Query-Planner, keine Joins und keine mengenbasierte Aggregation. Jedes Statement fällt auf eine native Operation zusammen:

Ein SELECT ohne Gleichheit auf den Partition Key kompiliert zu einem Full-Table-Scan. In us-east-1 On-Demand kostet das 0,5 RCU pro 4 KB letztendlich konsistent für jedes geprüfte Item — eine 500 MB große Tabelle aus 2 KB großen Zeilen sind grob 125.000 RCU, noch bevor ein WHERE-Filter das Result Set eingrenzt. Rechne PartiQL-förmige Lesevorgänge im Preisrechner durch.

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

Was PartiQL abdeckt

Das PartiQL von DynamoDB unterstützt vier DML-/Abfrage-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 Lesevorgang trifft den Partition Key mit einer Gleichheit oder einem IN:

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 Ordnungs-Key auf "a hash key or a sort key" — den Partition Key oder Sort Key, nicht beliebige Spalten. Das ist die Decke dessen, was SELECT in PartiQL akzeptiert. Statements zum Kopieren und Einfügen findest du in den PartiQL-Beispielen.

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 Key verbundene Tabellen. Das ist der Tradeoff von Single-Table-Design: Du modellierst vorab für deine Zugriffsmuster, weil die Query-Schicht die Daten hinterher nicht umformen kann.
• Kein GROUP BY. Es steht nicht in der Grammatik; es gibt keine Klausel, um Zeilen zu gruppieren.
• Keine Aggregatfunktionen. Die PartiQL-Funktionsreferenz führt unter "Aggregate functions" genau eine Funktion auf: SIZE, die die Größe eines Attributs in Bytes für ein einzelnes Item zurückgibt. Es gibt kein COUNT, SUM, AVG, MIN und kein MAX über Zeilen hinweg. AWS sagt es klar: "Any SQL functions that are not included in this list are not currently supported in DynamoDB."
• Kein LIKE, keine Subqueries, kein UNION, keine Fensterfunktionen. Mustervergleiche laufen über contains / begins_with; für den Rest gibt es überhaupt keine Entsprechung.

„Gesamtumsatz je Kunde im letzten Monat“ — ein einzeiliges GROUP BY in jeder relationalen Datenbank — lässt sich in PartiQL also nicht ausdrücken. Du würdest die Daten herausscannen und im Anwendungscode aggregieren.

Echtes JOIN-/GROUP BY-/Aggregat-Verhalten über DynamoDB-Daten bekommst du nur mit einem Werkzeug, das eine echte SQL-Engine darüber betreibt. Für interaktive Ad-hoc-Abfragen gibt es zwei: den Federated Connector von Amazon Athena und den SQL Workbench von DynoTable. (Für geplante Analytik führt auch die Zero-ETL-Integration von DynamoDB nach Amazon Redshift SQL-Joins und -Aggregate aus.)

Wie du DynamoDB mit echtem SQL über Amazon Athena abfragst

Die eigene Antwort von AWS auf „echtes SQL über DynamoDB“ ist der Amazon-Athena-DynamoDB-Connector, der "enables Amazon Athena to communicate with DynamoDB so that you can query your tables with SQL." Weil Athena eine vollwertige SQL-Engine ist, bekommst du damit tatsächlich JOIN und Aggregate — die Anleitung von AWS heißt "Access, query, and join Amazon DynamoDB tables using Athena."

Der Haken sind Einrichtung und Kosten:

• Es ist ein Lambda-basierter Federated Connector, den du in deinem Konto ausrollst (über die Athena-Konsole oder das Serverless Application Repository), über AWS Glue für das Schema verdrahtet und mit Ergebnisüberlauf in einen S3-Bucket (Connector-Doku).
• Unter der Haube nutzt er weiterhin die API-Operationen Query und Scan von DynamoDB. AWS warnt: "queries that use scans can consume a large number of read capacity units (RCUs)," eine analytische Abfrage über eine große Tabelle liest — und misst — also viele Items (Connector-Kosten). Nutze den Item-Size-Rechner, um abzuschätzen, was eine scan-lastige Abfrage kostet.
• Schreiboperationen wie INSERT INTO werden über den Connector nicht unterstützt.

Athena ist das richtige Werkzeug für geplante Analytik und BI-Dashboards. Für den Alltagsfall „ich will nur zwei Tabellen joinen und das Ergebnis ansehen“ ist es schwerfällig — und genau diese Lücke füllt der nächste Abschnitt.

DynoTable SQL Workbench: SQL innerhalb der Zugriffsmuster-Regeln von DynamoDB

Der SQL Workbench von DynoTable führt echtes SQL aus — JOIN, GROUP BY, COUNT/SUM/AVG — gegen deine laufenden DynamoDB-Tabellen aus einem Desktop-Client, ohne dass du Lambda, Glue oder S3 aufsetzen musst. Er materialisiert die Zeilen über die echte Query/Scan-Runtime von DynamoDB und führt darüber lokal auf deinem Desktop ein einzelnes SELECT aus:

-- Runs in the DynoTable Workbench (NOT 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 Teil „innerhalb der Zugriffsmuster-Regeln von DynamoDB“ ist wichtig. Der Workbench tut nicht so, als wäre DynamoDB Postgres — er liest unter der Haube weiterhin über Query/Scan, du behältst also im Blick, was jede Abfrage kostet, und er setzt das Zugriffsmodell von DynamoDB durch, statt es zu verstecken:

• Nur INNER JOIN und LEFT JOIN — das Zielattribut im ON 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 Fensterfunktionen.
• Joins und Projektionen arbeiten auf skalaren Attributen.

Wenn du nur die Bedingungen und Key-Ausdrücke für das rohe API zusammensetzen willst — kein vollständiges SQL-Statement —, erzeugt der DynamoDB Expression Builder die korrekte FilterExpression / KeyConditionExpression ganz ohne die PartiQL-Oberfläche.

Ist dein Ziel ein SQL-Client für DynamoDB, um Tabellen zu erkunden, zu debuggen und zu analysieren, füllt der Workbench diese Lücke — und der Rest von DynoTable ist eine vollständige DynamoDB-GUI drum herum.

Probier DynoTable aus, um echtes SQL gegen deine eigenen Tabellen laufen zu lassen.

FAQ

Kann man SQL auf DynamoDB ausführen? Du kannst PartiQL ausführen, eine SQL-kompatible Teilmenge (SELECT/INSERT/UPDATE/DELETE über den Key). Für JOIN, GROUP BY und Aggregate brauchst du eine SQL-Engine darüber: den Amazon-Athena-DynamoDB-Connector oder den SQL Workbench von DynoTable — ein einzelner SELECT-Dialekt mit INNER/LEFT JOIN, ohne CTEs, Unions oder Subqueries.

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

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 hinweg werden nicht unterstützt.

Ist DynamoDB SQL oder NoSQL? NoSQL — ein Key-Value- und Dokumenten-Store. PartiQL legt eine SQL-kompatible Abfragesprache darüber, aber DynamoDB hat keine relationale Engine, keine Joins und keine Aggregate.

Eignet sich PartiQL für Ad-hoc-Abfragen? Für Key-basierte Lookups ja. Für analytische Ad-hoc-Abfragen (Zählungen, Aggregationen, Joins) nein — PartiQL kann sie nicht ausdrücken, und unbeschränkte SELECTs werden still zu Full-Table-Scans.

Gibt es einen DynamoDB-SQL-Client, der JOIN und GROUP BY beherrscht? Ja — der SQL Workbench von DynoTable führt JOIN/GROUP BY/Aggregate gegen laufende Tabellen vom Desktop aus, und Amazon Athena schafft das über einen Federated Connector, den du in deinem AWS-Konto ausrollst.