DynoTable
Débutant3 min de lecture

PartiQL pour DynamoDB par l'exemple

est un langage de requête compatible SQL pour DynamoDB. Il est plus accueillant que l'API brute pour le travail ad hoc — mais il tourne sur le même moteur, donc les mêmes règles de clé (et les mêmes coûts) s'appliquent sous la syntaxe familière.

Comment écrire des requêtes PartiQL pour DynamoDB ?

PartiQL donne à DynamoDB quatre instructions façon SQL — SELECT, INSERT, UPDATE, et DELETE — exécutées via ExecuteStatement. Chacune se compile en une opération native sous-jacente, donc filtrer sur la reste un Query tandis que l'omettre devient un Scan de table entière. Les écritures ciblent toujours un item par sa ; il n'y a pas de JOIN, de GROUP BY, ni d'agrégat relationnels.

SELECT

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

Filtre sur la et c'est un Query. Omets la clé de partition et PartiQL exécute silencieusement un Scan de table entière — même piège, juste caché derrière SELECT *.

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'

Interroger un index

Utilise le nom de l'index dans la clause FROM :

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

WHERE prend aussi en charge IN, contains() et begins_with() :

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

Instructions paramétrées

Utilise des placeholders ? au lieu d'inliner les valeurs — ça contourne les problèmes de guillemets/injection et laisse le SDK marshaller les types pour toi :

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

Passe Parameters: [{ S: 'CUSTOMER#42' }, { S: 'ORDER#' }] à ExecuteStatement.

Batch et transactions

  • BatchExecuteStatement — jusqu'à 25 instructions en un aller-retour. Plus rapide, mais aucune atomicité inter-items (chacune réussit ou échoue de son côté).
  • ExecuteTransaction — jusqu'à 100 instructions, tout ou rien. Utilise-le quand plusieurs écritures doivent être validées ensemble.

Le piège de PartiQL

PartiQL ressemble à du SQL mais tourne sur le moteur DynamoDB, donc les habitudes SQL se retournent contre toi :

  • Un seul UPDATE/DELETE doit cibler un item par sa complète — il n'y a pas de mise à jour de masse UPDATE … WHERE status = 'x' (boucle avec un batch à la place).
  • Pas de JOIN, pas de GROUP BY, pas d'agrégats (COUNT/SUM/AVG). Vois PartiQL vs SQL.
  • Omettre la clé de partition transforme n'importe quel SELECT en un Scan de table entière — borné seulement par ta facture.

Quand tu as réellement besoin d'un JOIN, d'un GROUP BY ou d'un agrégat, le SQL Workbench de DynoTable les exécute côté client sur les lignes que tu as tirées — le SQL que PartiQL ne sait pas parler, dans le respect des règles de modèle d'accès de DynamoDB.

PartiQL ne change pas les types de données sous-jacents — les valeurs transitent toujours sur le réseau au format DynamoDB-JSON, que tu peux inspecter avec le convertisseur.

Essaie DynoTable pour exécuter des instructions PartiQL avec une autocomplétion consciente du schéma et parcourir les résultats dans une vue table triable.

Mis à jour