SQL per DynamoDB e i limiti di PartiQL

DynamoDB è un archivio di valori-chiave NoSQL, ma risponde più a domande a forma di SQL di quanto le persone si aspettano – e molto meno di quanto sperano. Questa è la mappa onesta: cosa SQL-on-DynamoDB esci effettivamente dalla scatola, dove si ferma e in pochi modi per eseguire le query JOIN/GROUP BY/aggregate la superficie nativa non può esprimere.

Puoi interrogare DynamoDB con SQL?

In parte. DynamoDB viene fornito con PartiQL, un linguaggio compatibile con SQL per SELECT/INSERT/UPDATE/DELETE tramite tasto, quindi SELECT * FROM "Ordini" DOVE OrderID = 100 funziona. Ma è una superficie compatibile con SQL rispetto a DynamoDB API, non un motore SQL: AWS supporta solo un subset, quindi JOIN, GROUP BY e Sono uscite le COUNT(*). Per quelli è necessario un motore sovrapposto.

AWS descrive PartiQL come "un linguaggio di query compatibile con SQL, per selezionare, inserire, aggiornare ed eliminare i dati Amazon DynamoDB", ma è altrettanto esplicito che "Amazon DynamoDB supporta un sottoinsieme dell'PartiQL linguaggio di interrogazione." Nel momento in cui prendi un JOIN, un GROUP BY o un COUNT(*), sei fuori da ciò che può fare PartiQL: vedi PartiQL vs SQL per tutte le funzionalità, funzionalità per funzionalità confronto.

PartiQL: una superficie compatibile con SQL, non un motore SQL

PartiQL mappa le istruzioni simili a SQL sulle stesse operazioni del piano dati dell'SDK espone. Un SELECT con un'uguaglianza partition-key viene compilato in un Query; un SELECT senza uno viene compilato in un Scan. Secondo il Riferimento AWS SELECT:

L'utilizzo dell'istruzione SELECT può comportare una scansione completa della tabella se un'uguaglianza o La condizione IN con una chiave di partizione non è fornita nella clausola WHERE.

Quindi si applicano ancora le stesse regole del modello di accesso che governano Query e Scan: PartiQL li nasconde semplicemente dietro una sintassi familiare. Non aggiunge alcun pianificatore di query, no join e nessuna aggregazione basata su set. Ogni affermazione si riduce a un nativo operazione:

Un SELECT senza uguaglianza della chiave di partizione viene compilato in un Scan a tabella completa. Dentro us-east-1 on-demand che fattura 0,5 RCU per 4 KB, eventualmente coerenti per ogni elemento esaminato: una tabella da 500 MB di righe da 2 KB equivale a circa 125.000 RCU prima di qualsiasi filtro WHERE restringe il set di risultati. Linea-rate a forma di PartiQL si legge nel calcolatore dei prezzi.

Se un'operazione non si riduce a un singolo Get/Query/Scan/Put/Update/Delete, PartiQL semplicemente non riesce a esprimerlo. Tutto quello che segue è una conseguenza di quello fatto.

Cosa copre PartiQL

PartiQL di DynamoDB supporta quattro istruzioni DML/query:

• SELECT: leggi gli elementi (compila su Query o Scan)
• INSERISCI: aggiungi un articolo (PutItem)
• AGGIORNAMENTO: modifica un elemento (UpdateItem)
• ELIMINA: rimuovi un elemento (DeleteItem)

Supporta anche transazioni e operazioni batch. Obiettivi di lettura ben formati la chiave di partizione con uguaglianza o IN:

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

ORDER BY è consentito, ma il riferimento AWS limita la chiave di ordinazione a "a chiave hash o chiave di ordinamento" — la partizione o [[sort-key|sort key]], non colonne arbitrarie. Questo è il limite massimo accettato dall'SELECT` di PartiQL. Per il copia-incolla istruzioni, vedere Esempi PartiQL.

Cosa non può fare PartiQL

Queste sono le cose che gli sviluppatori si aspettano più spesso da "SQL" e PartiQL non ne supporta nessuno:

• No JOIN. Il Sintassi PartiQL SELECT è un singolo FROM XTK0X[.XTK1X]: una tabella o un indice, mai due tabelle correlate su una chiave. Questo è il design a tabella singola compromesso: modello per cui i tuoi modelli di accesso in anticipo perché il livello di query non può rimodellare i dati dopo.
• No GROUP BY. Non è nella grammatica; non esiste alcuna clausola per raggruppare le righe.
• Nessuna funzione aggregata. The Riferimento funzioni PartiQL elenca esattamente una funzione in "Funzioni aggregate": SIZE, che restituisce la dimensione di un attributo in byte per un singolo elemento. Non c'è COUNT, SUM, AVG, MIN o MAX su righe. AWS afferma chiaramente: "Qualsiasi SQL le funzioni che non sono incluse in questo elenco non sono attualmente supportate DynamoDB."
• Nessuna LIKE, nessuna sottoquery, nessuna UNION, nessuna funzione finestra. Corrispondenza di modelli utilizza contains/begins_with; il resto non ha alcun equivalente.

Quindi "entrate totali per cliente il mese scorso": un GROUP BY a una riga in qualsiasi database relazionale: non può essere espresso in PartiQL. Scansioneresti i dati e aggregarlo nel codice dell'applicazione.

L'unico modo per ottenere un comportamento reale di JOIN/GROUP BY/aggregato rispetto a DynamoDB data è uno strumento su cui viene eseguito un vero motore SQL. Per interattivo, query ad hoc ce ne sono due: il connettore federato di Amazon Athena e SQL Workbench di DynoTable. (Per l'analisi pianificata, zero-ETL di DynamoDB l'integrazione con Amazon Redshift esegue anche join e aggregazioni SQL.)

Come interrogare DynamoDB con SQL reale tramite Amazon Athena

La risposta di AWS al "vero SQL su DynamoDB" è la Connettore Amazon Athena DynamoDB, che "consente ad Amazon Athena di comunicare con DynamoDB in modo da poter eseguire query i tuoi tavoli con SQL." Dato che Athena è un motore SQL completo, questo ti conquista JOIN e aggregati: la procedura dettagliata di AWS è intitolata "Accedi, interroga e unisci tabelle Amazon DynamoDB utilizzando Athena."

Il problema è l'impostazione e il costo:

• È un connettore federato basato su Lambda che distribuisci nel tuo account (tramite la console Athena o il Serverless Application Repository), cablato tramite AWS Glue per lo schema e la distribuzione dei risultati in un bucket S3 (documentazione connettore).
• Sotto il cofano utilizza ancora le operazioni Query e Scan API di DynamoDB. AWS avverte che "le query che utilizzano le scansioni possono consumare un gran numero di read unità di capacità (RCU)", così una query analitica su una grande tabella recita — e metri: molti articoli (costi del connettore). Usa il calcolatore delle dimensioni dell'articolo per valutare cosa a una query di scansione pesante avrà un costo.
• Le operazioni di scrittura come INSERT INTO non sono supportate tramite il connettore.

Athena è lo strumento giusto per analisi pianificate e dashboard BI. È pesante per il caso quotidiano "Devo solo unire due tabelle e osservare il risultato" — questa è la lacuna che verrà colmata dalla sezione successiva.

DynoTable SQL Workbench: SQL all'interno delle regole del modello di accesso di DynamoDB

SQL Workbench di DynoTable funziona con SQL reale: JOIN, GROUP BY, COUNT/SUM/AVG: rispetto ai tuoi tavoli DynamoDB live da un client desktop, senza Lambda, colla o S3 per resistere. Si materializza le righe attraverso Il vero runtime Query/Scan di DynamoDB, quindi esegue un singolo SELECT su di essi localmente sul tuo desktop:

-- 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 parte "entro le regole del modello di accesso di DynamoDB" è importante. L'Workbench no fingi che DynamoDB sia Postgres: legge ancora Query/Scan sotto cappuccio, quindi rimani consapevole di quanto costa ciascuna query e applica DynamoDB modello di accesso anziché nasconderlo:

• Solo INNER JOIN e LEFT JOIN: l'attributo di destinazione ON deve essere a chiave di partizione o chiave di partizione GSI. Nessun RIGHT/FULL/CROSS/unione con virgola.
• Ancora nessun self-join, nessuna sottoquery, nessuna tabella derivata, nessuna funzione finestra.
• Join e proiezioni operano su attributi scalari.

Se hai solo bisogno di comporre le condizioni e le espressioni chiave per l'API grezzo — non una dichiarazione completa sull'SQL: il DynamoDB Expression Builder genera il file corretto FilterExpression / KeyConditionExpression senza la superficie PartiQL affatto.

Se il tuo obiettivo è un client DynamoDB SQL per l'esplorazione, il debug e l'analisi tavoli, l'Workbench colma questa lacuna e il resto dell'DynoTable è completo DynamoDB GUI attorno ad esso.

Prova DynoTable per eseguire il vero SQL sui tuoi tavoli.

FAQ

È possibile eseguire SQL su DynamoDB? È possibile eseguire PartiQL, un sottoinsieme compatibile con SQL (SELECT/INSERT/UPDATE/DELETE tramite chiave). Per JOIN, GROUP BY e aggregati è necessario un motore SQL in più: l'Amazon Connettore Athena DynamoDB o SQL Workbench di DynoTable: un singolo dialetto SELECT con INNER/LEFT JOIN, senza CTE, unioni o sottoquery.

DynamoDB PartiQL supporta JOIN? No. La sintassi PartiQL SELECT ha una singola tabella o indice FROM e nessun join grammatica. I join richiedono un motore sovrapposto a DynamoDB.

PartiQL supporta GRUPPO PER o aggregati come COUNT e SUM? No. Non esiste alcuna clausola GROUP BY e l'unica funzione "aggregata" è SIZE (la dimensione in byte di un attributo per un elemento). COUNT, SUM, AVG, MIN e MAX su righe non sono supportate.

DynamoDB è SQL o NoSQL? NoSQL: un archivio di valori-chiave e documenti. PartiQL aggiunge una query compatibile con SQL linguaggio in primo piano, ma DynamoDB non ha motore relazionale, join o aggregati.

PartiQL è adatto per query ad hoc? Per le ricerche basate su chiavi, sì. Per query analitiche ad hoc (conteggi, rollup, join), no: PartiQL non può esprimerli e SELECT non vincolati in modo silenzioso diventano scansioni complete della tabella.

Esiste un client DynamoDB SQL che gestisce JOIN e GROUP BY? Sì: SQL Workbench di DynoTable esegue JOIN/GROUP BY/aggregates rispetto a live tabelle dal desktop e Amazon Athena lo fa tramite un connettore federato you distribuire nel tuo account AWS.