SQL pour DynamoDB et les limites de PartiQL

DynamoDB est un magasin clé-valeur NoSQL, mais il répond à des questions façon SQL plus que les gens ne le pensent — et bien moins qu'ils ne l'espèrent. Voici la carte honnête : le SQL-sur-DynamoDB que tu obtiens vraiment d'entrée de jeu, où il s'arrête, et les quelques moyens d'exécuter les requêtes JOIN / GROUP BY / agrégats que la surface native ne peut pas exprimer.

Peut-on interroger DynamoDB avec du SQL ?

En partie. DynamoDB embarque , un langage compatible SQL pour SELECT/INSERT/UPDATE/DELETE par clé, donc SELECT * FROM "Orders" WHERE OrderID = 100 fonctionne. Mais c'est une surface compatible SQL au-dessus de l'API DynamoDB, pas un moteur SQL — AWS ne prend en charge qu'un sous-ensemble, donc JOIN, GROUP BY et COUNT(*) sont exclus. Pour ceux-là, il te faut un moteur posé par-dessus.

AWS décrit PartiQL comme « un langage de requête compatible SQL, pour sélectionner, insérer, mettre à jour et supprimer des données dans Amazon DynamoDB », mais est tout aussi explicite : « Amazon DynamoDB prend en charge un sous-ensemble du langage de requête PartiQL. » Dès que tu tends la main vers un JOIN, un GROUP BY ou COUNT(*), tu es en dehors de ce que PartiQL peut faire — voir PartiQL vs SQL pour la comparaison complète, fonctionnalité par fonctionnalité.

PartiQL : une surface compatible SQL, pas un moteur SQL

PartiQL mappe des instructions à l'allure SQL sur les mêmes opérations du plan de données que le SDK expose. Un SELECT avec une égalité sur la se compile en Query ; un SELECT sans clé se compile en Scan. Selon la référence AWS du SELECT :

L'utilisation de l'instruction SELECT peut entraîner un scan de table entière si une condition d'égalité ou IN avec une clé de partition n'est pas fournie dans la clause WHERE.

Donc les mêmes règles de mode d'accès qui gouvernent Query et Scan s'appliquent toujours — PartiQL les cache simplement derrière une syntaxe familière. Il n'ajoute aucun planificateur de requêtes, aucune jointure, aucune agrégation ensembliste. Chaque instruction se réduit à une seule opération native :

Un SELECT sans égalité sur la clé de partition se compile en un Scan de toute la table. En on-demand dans us-east-1, cela facture 0,5 RCU par 4 Ko en cohérence à terme pour chaque élément examiné — une table de 500 Mo faite de lignes de 2 Ko, c'est environ 125 000 RCU avant qu'un WHERE ne restreigne le résultat. Chiffre les lectures d'allure PartiQL dans le calculateur de tarifs.

Tu écris	DynamoDB exécute
`SELECT … WHERE PK = …`	`GetItem` ou `Query`
`SELECT …` (sans PK)	`Scan` (lit la table entière)
`INSERT INTO …`	`PutItem`
`UPDATE … WHERE PK=… AND SK=…`	`UpdateItem` (un item)
`DELETE … WHERE PK=… AND SK=…`	`DeleteItem` (un item)

Si une opération ne se réduit pas à un seul Get/Query/Scan/Put/Update/Delete, PartiQL ne peut tout simplement pas l'exprimer. Tout ce qui suit est une conséquence de ce seul fait.

Ce que PartiQL couvre

Le PartiQL de DynamoDB prend en charge quatre instructions DML/de requête :

SELECT — lire des items (se compile en Query ou Scan)
INSERT — ajouter un item (PutItem)
UPDATE — modifier un item (UpdateItem)
DELETE — supprimer un item (DeleteItem)

Il prend aussi en charge les transactions et opérations par lot. Une lecture bien formée cible la clé de partition avec une égalité ou un IN :

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

ORDER BY est autorisé, mais la référence AWS restreint la clé d'ordonnancement à « une hash key ou une sort key » — la clé de partition ou la , pas des colonnes arbitraires. C'est le plafond de ce que le SELECT de PartiQL accepte. Pour des instructions prêtes à copier-coller, voir les exemples PartiQL.

Ce que PartiQL ne peut pas faire

Voici ce que les développeurs attendent le plus souvent du « SQL », et PartiQL n'en prend en charge aucun :

Pas de JOIN. La syntaxe du SELECT PartiQL est un unique FROM {{table}}[.{{index}}] — une table ou un index, jamais deux tables reliées sur une clé. C'est le compromis de la conception à table unique : tu modélises pour tes modèles d'accès en amont parce que la couche de requête ne peut pas remodeler les données après coup.
Pas de GROUP BY. Ce n'est pas dans la grammaire ; il n'y a aucune clause pour grouper des lignes.
Pas de fonctions d'agrégation. La référence des fonctions PartiQL liste exactement une fonction sous « Fonctions d'agrégation » : SIZE, qui renvoie la taille d'un attribut en octets pour un seul item. Il n'y a pas de COUNT, SUM, AVG, MIN ni MAX à travers les lignes. AWS l'énonce clairement : « Toute fonction SQL qui n'est pas incluse dans cette liste n'est pas actuellement prise en charge dans DynamoDB. »
Pas de LIKE, pas de sous-requêtes, pas d'UNION, pas de fonctions de fenêtrage. La correspondance de motifs utilise contains / begins_with ; le reste n'a aucun équivalent.

Ainsi « chiffre d'affaires total par client le mois dernier » — un GROUP BY d'une ligne dans n'importe quelle base relationnelle — ne peut pas être exprimé en PartiQL. Tu scannerais les données puis les agrégerais en code applicatif.

Le seul moyen d'obtenir un vrai comportement JOIN / GROUP BY / agrégat sur des données DynamoDB est un outil qui exécute un vrai moteur SQL par-dessus. Pour des requêtes interactives et ad hoc, il y en a deux : le connecteur fédéré d'Amazon Athena, et le SQL Workbench de DynoTable. (Pour de l'analytique planifiée, l'intégration zéro-ETL de DynamoDB vers Amazon Redshift exécute aussi des jointures et agrégats SQL.)

Comment interroger DynamoDB avec du vrai SQL via Amazon Athena

La réponse propre d'AWS à « du vrai SQL sur DynamoDB » est le connecteur DynamoDB d'Amazon Athena, qui « permet à Amazon Athena de communiquer avec DynamoDB pour que tu puisses interroger tes tables avec du SQL ». Parce qu'Athena est un moteur SQL complet, cela te donne bien JOIN et agrégats — le pas-à-pas d'AWS s'intitule « Access, query, and join Amazon DynamoDB tables using Athena ».

Le hic, c'est la mise en place et le coût :

C'est un connecteur fédéré basé sur Lambda que tu déploies dans ton compte (via la console Athena ou le Serverless Application Repository), câblé à travers AWS Glue pour le schéma et déversant les résultats dans un bucket S3 (doc du connecteur).
Sous le capot, il utilise toujours les opérations d'API Query et Scan de DynamoDB. AWS avertit que « les requêtes qui utilisent des scans peuvent consommer un grand nombre d'unités de capacité de lecture (RCU) », donc une requête analytique sur une grande table lit — et facture — beaucoup d'items (coûts du connecteur). Utilise le calculateur de taille d'item pour évaluer ce que coûtera une requête à forte charge de scan.
Les opérations d'écriture comme INSERT INTO ne sont pas prises en charge par le connecteur.

Athena est le bon outil pour l'analytique planifiée et les tableaux de bord BI. Il est lourd pour le cas quotidien « j'ai juste besoin de joindre deux tables et de jeter un œil au résultat » — c'est la lacune que comble la section suivante.

SQL Workbench de DynoTable : du SQL dans le respect des règles de mode d'accès de DynamoDB

Le SQL Workbench de DynoTable exécute du vrai SQL — JOIN, GROUP BY, COUNT/SUM/AVG — contre tes tables DynamoDB en direct depuis un client de bureau, sans Lambda, Glue ou S3 à mettre en place. Il matérialise les lignes à travers le vrai runtime Query/Scan de DynamoDB, puis exécute un seul SELECT par-dessus, localement sur ton poste :

-- 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

La partie « dans le respect des règles de mode d'accès de DynamoDB » compte. Le Workbench ne prétend pas que DynamoDB est Postgres — il lit toujours à travers Query/Scan sous le capot, donc tu restes conscient de ce que coûte chaque requête, et il applique le modèle d'accès de DynamoDB au lieu de le cacher :

INNER JOIN et LEFT JOIN uniquement — l'attribut-cible du ON doit être une clé de partition ou une clé de partition de GSI. Pas de RIGHT / FULL / CROSS / jointure virgule.
Pas encore d'auto-jointures, pas de sous-requêtes, pas de tables dérivées, pas de fonctions de fenêtrage.
Les jointures et projections opèrent sur des attributs scalaires.

Si tu as seulement besoin de composer les conditions et expressions de clé pour l'API brute — pas une instruction SQL complète — le DynamoDB Expression Builder génère la FilterExpression / KeyConditionExpression correcte sans passer par la surface PartiQL du tout.

Si ton objectif est un client SQL DynamoDB pour explorer, déboguer et analyser des tables, le Workbench comble cette lacune — et le reste de DynoTable est une GUI DynamoDB complète autour de lui.

Essaie DynoTable pour exécuter du vrai SQL contre tes propres tables.

FAQ

Peut-on exécuter du SQL sur DynamoDB ? Tu peux exécuter PartiQL, un sous-ensemble compatible SQL (SELECT/INSERT/UPDATE/DELETE par clé). Pour JOIN, GROUP BY et les agrégats, il te faut un moteur SQL par-dessus : le connecteur DynamoDB d'Amazon Athena, ou le SQL Workbench de DynoTable — un dialecte à un seul SELECT, avec INNER/LEFT JOIN, sans CTE, union ni sous-requête.

Le PartiQL de DynamoDB prend-il en charge JOIN ? Non. La syntaxe du SELECT PartiQL a une seule table ou un seul index en FROM et aucune grammaire de jointure. Les jointures exigent un moteur posé par-dessus DynamoDB.

PartiQL prend-il en charge GROUP BY ou des agrégats comme COUNT et SUM ? Non. Il n'y a pas de clause GROUP BY, et la seule fonction « d'agrégation » est SIZE (la taille en octets d'un attribut pour un item). COUNT, SUM, AVG, MIN et MAX à travers les lignes ne sont pas pris en charge.

DynamoDB est-il du SQL ou du NoSQL ? Du NoSQL — un magasin clé-valeur et document. PartiQL ajoute un langage de requête compatible SQL par-dessus, mais DynamoDB n'a ni moteur relationnel, ni jointures, ni agrégats.

PartiQL est-il bon pour les requêtes ad hoc ? Pour les recherches par clé, oui. Pour les requêtes ad hoc analytiques (comptages, regroupements, jointures), non — PartiQL ne peut pas les exprimer, et les SELECT sans contrainte deviennent silencieusement des scans de table entière.

Existe-t-il un client SQL DynamoDB qui gère JOIN et GROUP BY ? Oui — le SQL Workbench de DynoTable exécute JOIN/GROUP BY/agrégats contre des tables en direct depuis le bureau, et Amazon Athena le fait via un connecteur fédéré que tu déploies dans ton compte AWS.