PartiQL für DynamoDB anhand von Beispielen

PartiQL ist eine SQL-kompatible Abfragesprache für DynamoDB. Sie ist für Ad-hoc-Arbeit freundlicher als die rohe API — läuft aber auf derselben Engine, also gelten unter der vertrauten Syntax dieselben Schlüsselregeln (und dieselben Kosten).

Wie schreibt man PartiQL-Abfragen für DynamoDB?

PartiQL gibt DynamoDB vier SQL-förmige Statements — SELECT, INSERT, UPDATE und DELETE — die über ExecuteStatement laufen. Jedes kompiliert darunter zu einer nativen Operation, sodass ein Filtern auf den Partition Key eine Query bleibt, während sein Weglassen zu einem Full-Table-Scan wird. Schreibvorgänge zielen weiterhin auf ein Item anhand seines Primary Keys; es gibt keinen relationalen JOIN, kein GROUP BY und keine Aggregate.

SELECT

SELECT * FROM "AppData"
WHERE "PK" = 'CUSTOMER#42' AND begins_with("SK", 'ORDER#')

Filtere auf den Partition Key, und dies ist eine Query. Lass den Partition Key weg, und PartiQL führt stillschweigend einen Full-Table-Scan aus — dieselbe Fußangel, nur hinter SELECT * versteckt.

INSERT

INSERT INTO "AppData" VALUE {'PK': 'CUSTOMER#42', 'SK': 'PROFILE', 'plan': 'pro'}

UPDATE

UPDATE "AppData" SET "plan" = 'enterprise'
WHERE "PK" = 'CUSTOMER#42' AND "SK" = 'PROFILE'

DELETE

DELETE FROM "AppData"
WHERE "PK" = 'CUSTOMER#42' AND "SK" = 'ORDER#2026-001'

Einen Index abfragen

Verwende den Indexnamen in der FROM-Klausel:

SELECT * FROM "AppData"."GSI1" WHERE "GSI1PK" = 'STATUS#OPEN'

WHERE unterstützt außerdem IN, contains() und begins_with():

SELECT * FROM "AppData"
WHERE "PK" = 'CUSTOMER#42' AND "SK" IN ['ORDER#1', 'ORDER#2']

Parametrisierte Statements

Verwende ?-Platzhalter, statt Werte inline einzusetzen — das umgeht Quoting-/Injection-Probleme und lässt das SDK die Typen für dich marshallen:

SELECT * FROM "AppData" WHERE "PK" = ? AND begins_with("SK", ?)

Übergib Parameters: [{ S: 'CUSTOMER#42' }, { S: 'ORDER#' }] an ExecuteStatement.

Batch und Transaktionen

• BatchExecuteStatement — bis zu 25 Statements in einem Roundtrip. Schneller, aber ohne itemübergreifende Atomarität (jedes gelingt oder scheitert für sich).
• ExecuteTransaction — bis zu 100 Statements, alles oder nichts. Verwende es, wenn mehrere Schreibvorgänge zusammen committen müssen.

Die PartiQL-Fußangel

PartiQL sieht aus wie SQL, läuft aber auf der DynamoDB-Engine, sodass SQL-Gewohnheiten nach hinten losgehen:

• Ein einzelnes UPDATE/DELETE muss ein Item anhand seines vollständigen Primary Keys treffen — es gibt kein UPDATE … WHERE status = 'x' als Massenaktualisierung (schleife stattdessen mit einem Batch).
• Kein JOIN, kein GROUP BY, keine Aggregate (COUNT/SUM/AVG). Siehe PartiQL vs SQL.
• Den Partition Key wegzulassen macht aus jedem SELECT einen Full-Table-Scan — begrenzt nur durch deine Rechnung.

Wenn du wirklich einen JOIN, ein GROUP BY oder ein Aggregat brauchst, führt die SQL-Workbench von DynoTable sie client-seitig über den Zeilen aus, die du geholt hast — das SQL, das PartiQL nicht sprechen kann, innerhalb der Zugriffsmuster-Regeln von DynamoDB.

PartiQL ändert die zugrundeliegenden Datentypen nicht — Werte gehen weiterhin als DynamoDB-JSON über die Leitung, was du mit dem Konverter inspizieren kannst.

Probiere DynoTable aus, um PartiQL-Statements mit schema-bewusster Autovervollständigung auszuführen und die Ergebnisse in einer sortierbaren Tabellenansicht zu durchstöbern.