DynamoDB GROUP BY: come aggregare senza una clausola GROUP BY

Non esiste un GROUP BY in DynamoDB. Non esiste nemmeno un COUNT, SUM o AVG — né nell'API nativa, né in PartiQL. DynamoDB è uno store chiave-valore / documentale, non un motore analitico, quindi l'aggregazione è qualcosa che tu costruisci, non qualcosa che il query planner fa per te.

Si può fare GROUP BY in DynamoDB?

No. DynamoDB non ha GROUP BY, HAVING né funzioni di aggregazione come COUNT, SUM e AVG — né nell'API nativa, né in PartiQL, il cui SELECT accetta solo WHERE e ORDER BY. Aggreghi precomputando i totali man mano che i dati cambiano (contatori atomici o rollup con Streams + Lambda) oppure raggruppando lato app dopo la lettura.

• La grammatica SELECT di PartiQL di DynamoDB è SELECT … FROM … [WHERE …] [ORDER BY …] — e questo è l'intero elenco. Niente GROUP BY, niente HAVING, nessuna funzione di aggregazione, nessun JOIN (riferimento SELECT PartiQL di AWS).
• Poiché DynamoDB "non supporta nativamente operazioni di aggregazione come SUM o COUNT tra gli item", la stessa guida di AWS consiglia di precomputare gli aggregati man mano che i dati cambiano e di memorizzare i risultati come item ordinari (AWS: aggregazione materializzata).
• L'alternativa — leggere ogni item e poi aggregare nella tua app — funziona, ma paghi per leggere l'intera tabella a ogni query.
• Per l'esplorazione una tantum, il SQL Workbench di DynoTable esegue GROUP BY / COUNT / SUM / AVG direttamente su una tabella live — l'SQL che l'endpoint PartiQL di DynamoDB rifiuta.

Perché l'aggregazione è difficile in DynamoDB

DynamoDB non ha un motore di aggregazione in fase di scan. Query e Scan restituiscono item; non li ripiegano. Uno Scan legge l'intera tabella 1 MB alla volta, e la capacità che consuma si basa sugli item che legge, non sulle righe che tieni — una FilterExpression viene applicata dopo lo scan ma prima che i risultati ritornino, quindi restringe il set di risultati senza abbassare il conto (riferimento API Scan di AWS: un filtro "non consuma unità di capacità di lettura aggiuntive"; la capacità si basa sulla dimensione degli item scansionati, non restituiti). Non c'è proprio un hook GROUP-BY a cui appendere una somma o un conteggio.

PartiQL non cambia questo. PartiQL è un dialetto SQL-compatibile sullo stesso motore, quindi eredita gli stessi limiti — è una superficie sintattica, non un nuovo modello di esecuzione. La grammatica SELECT documentata semplicemente non ha un token GROUP BY. Per la lacuna completa tra PartiQL e l'SQL reale, vedi PartiQL vs SQL.

Quindi la domanda non è "come scrivo un GROUP BY" — è "dove vive il mio aggregato, e quando viene calcolato?" Ci sono tre risposte.

Pattern 1: aggregare in scrittura (contatori atomici)

Se conosci i gruppi in anticipo — conteggio per status, totale per cliente, download per mese — tieni un item contatore e aggiornalo a ogni scrittura.

Usa un'update expression ADD così che l'incremento sia atomico e sicuro rispetto alla concorrenza. ADD funziona su numeri e set, ed evita la race read-modify-write, quindi due writer che incrementano lo stesso contatore non si calpestano mai a vicenda (AWS nota che l'ADD atomico "evita le race condition read-modify-write"):

UpdateItem
Key                         { pk: "STATS#orders", sk: "status#shipped" }
UpdateExpression            "ADD orderCount :one"
ExpressionAttributeValues   { ":one": 1 }

Questo è il tuo SELECT COUNT(*) … GROUP BY status — solo che il conteggio è già lì come item, leggibile in un GetItem da pochi millisecondi a una cifra. Il compromesso: devi conoscere la chiave di raggruppamento in fase di scrittura, e accoppi l'aggiornamento del contatore al percorso di scrittura. Se l'app va in crash dopo la scrittura ma prima dell'aggiornamento del contatore, i due si disallineano — che è esattamente la modalità di fallimento che il prossimo pattern disaccoppia.

Pattern 2: rollup con DynamoDB Streams + Lambda

Quando non vuoi la logica di aggregazione sul percorso di scrittura — o la scrittura è un semplice PutItem che non puoi facilmente avvolgere — spostala a valle. Questo è il pattern raccomandato da AWS stessa, aggregazione materializzata (AWS: Usare i GSI per query di aggregazione materializzata):

1. L'app scrive l'item grezzo (un ordine, un download, un evento). Nessuna logica di aggregazione.
2. DynamoDB Streams cattura la scrittura come record di stream.
3. Una Lambda collegata allo stream legge il nuovo item, deriva il gruppo (status, mese, categoria…) e fa ADD all'item aggregato corrispondente con un UpdateItem atomico — che "evita le race condition read-modify-write" quando molte invocazioni toccano lo stesso contatore.
4. Interroghi l'aggregato precomputato — spesso attraverso un GSI sparso che indicizza solo gli item di rollup, così "top 10 di questo mese" è una sola Query con Limit 10.

Il trucco del GSI sparso: solo gli item aggregati portano l'attributo indicizzato (es. Month), quindi le righe degli eventi grezzi sono escluse automaticamente dall'indice — "una piccola frazione del totale degli item nella tabella", che mantiene l'indice economico e la lettura veloce.

Questo disaccoppia l'aggregazione dal percorso di scrittura e mantiene semplici le scritture, al costo della coerenza eventuale — AWS nota "un ritardo di pochi secondi tra la registrazione di un download e l'aggiornamento dell'aggregazione". Per dashboard, leaderboard e contatori di trend va bene.

Vale lo stesso avvertimento sui retry: un'invocazione Lambda ritentata riesegue l'ADD, quindi "un retry incrementerebbe il conteggio più di una volta", lasciando un valore approssimato. Per conteggi esatti, aggiungi idempotenza (es. una condition expression con chiave sull'id dell'item sorgente); altrimenti il piccolo margine va bene per analisi e leaderboard.

Pattern 3: raggruppamento lato app dopo Scan/Query

L'opzione a forza bruta: leggi gli item, raggruppali nel tuo codice.

groups = {}
for item in paginate(table.scan()):       # o query() per una partizione
    key = item["status"]
    groups[key] = groups.get(key, 0) + 1

Questo è corretto e a volte è la scelta giusta — ma sii onesto sul costo. Uno Scan legge ogni item nella tabella, e la capacità di lettura è la stessa che tu filtri o no. Quindi il raggruppamento lato app su uno Scan completo significa pagare per leggere l'intera tabella a ogni aggregazione, e la latenza cresce con la tabella. AWS elenca "scansionare e contare in fase di lettura" come "adatto solo a dataset molto piccoli in cui la latenza non è una preoccupazione" (AWS: Perché precomputare le aggregazioni).

Ristretto a una singola partizione via Query (es. contare gli ordini di un cliente), il raggruppamento lato app è perfettamente ragionevole — stai leggendo solo una collezione di item. Per la lacuna completa di costo tra i due, vedi Query vs Scan. Per stimare cosa leggerà una data scansione di aggregazione prima di eseguirla, dimensiona un item rappresentativo con il calcolatore delle dimensioni degli item — la capacità di lettura arrotonda per eccesso ogni 4 KB, quindi la dimensione dell'item guida il conto.

Per SQL analitico genuinamente ad-hoc su una tabella DynamoDB — il "GROUP BY status, contali" usa e getta che eseguiresti una volta sola — la risposta di AWS è puntarci un motore separato: il connettore Amazon Athena per DynamoDB ti permette di interrogare la tabella con vero SQL (GROUP BY, aggregati, persino JOIN ad altre sorgenti) via un connettore Lambda (AWS: connettore Amazon Athena per DynamoDB). Scansiona la tabella dietro le quinte, quindi è uno strumento di reporting/BI, non un percorso caldo.

Quale pattern uso?

Eseguire GROUP BY direttamente nel SQL Workbench di DynoTable

I pattern sopra sono il modo per servire gli aggregati in produzione. Ma quando stai esplorando una tabella — "quanti ordini per status, proprio ora?" — non vuoi provisionare una Lambda o tirare su Athena. Vuoi digitare la query.

È a questo che serve il SQL Workbench di DynoTable. Esegue vero SQL — GROUP BY, COUNT, SUM, AVG, HAVING, persino JOIN — direttamente sulle tue tabelle DynamoDB live, eseguendo l'aggregazione lato client sulle righe che legge. È l'SQL che l'endpoint PartiQL di DynamoDB rifiuta:

SELECT status, COUNT(*) AS orders, SUM(total) AS revenue
FROM "Orders"
GROUP BY status
HAVING SUM(total) > 1000
ORDER BY revenue DESC

L'inquadramento onesto: sotto il cofano DynoTable legge gli item come l'API consente (Query dove può, Scan dove deve), li materializza e fa il raggruppamento nel Workbench — la stessa meccanica "leggi poi aggrega" del Pattern 3, solo senza il loop, e nel rispetto delle regole di pattern di accesso di DynamoDB. È costruito per l'esplorazione e l'analisi ad-hoc, non per sostituire un rollup di produzione su un percorso di lettura caldo. Per quello, precomputa (Pattern 1 / 2).

Per il lato JOIN dello stesso cuneo — DynoTable esegue join cross-tabella che nemmeno PartiQL sa fare — vedi DynamoDB JOIN. Stai confrontando i client GUI proprio su questa capacità? Vedi il confronto delle GUI per DynamoDB.

FAQ

DynamoDB PartiQL supporta GROUP BY? No. Il SELECT PartiQL di DynamoDB supporta solo WHERE e ORDER BY — niente GROUP BY, HAVING, funzioni di aggregazione o JOIN. La grammatica è documentata come SELECT … FROM … [WHERE …] [ORDER BY …].

Posso fare COUNT(*) su un'intera tabella DynamoDB? Non come funzione di aggregazione — PartiQL non ne ha. L'API ti dà Select=COUNT su uno Scan/Query, che restituisce un conteggio degli item corrispondenti ma legge (e fattura) comunque ogni item che lo scan tocca (riferimento API Scan di AWS: la capacità si basa sugli item esaminati, non restituiti). Per un totale letto di frequente, tieni un item contatore (Pattern 1).

Posso fare GROUP BY sulla partition key? Non in DynamoDB o PartiQL. Se "per partition key" è un pattern di accesso noto, mantieni un item aggregato per chiave con un ADD atomico (Pattern 1), oppure aggregalo con Streams + Lambda (Pattern 2).

Come faccio SUM o AVG per gruppo? SUM: tieni un totale progressivo per gruppo e fai ADD ad esso in scrittura. AVG: memorizza sia la somma sia il conteggio e dividi in fase di lettura — non c'è una media nativa. Per un AVG esplorativo una tantum, eseguilo nel SQL Workbench di DynoTable o via il connettore Athena per DynamoDB.

Esiste un workaround per partiql group by? Nessuno lato PartiQL. O precomputi l'aggregato (contatori/Streams) e fai SELECT dell'item di rollup, oppure esegui il GROUP BY in un motore che ne ha uno — il Workbench di DynoTable per l'ad-hoc, Athena per il reporting ricorrente.

Vuoi eseguire GROUP BY sulle tue tabelle senza scrivere una Lambda? Prova DynoTable e punta il SQL Workbench a una tabella live.