Principiante6 min di lettura

Come interrogare DynamoDB con l'AI (linguaggio naturale)

"Mostrami gli ordini falliti della settimana scorsa" è una riga nella tua testa e una KeyConditionExpression con mappe di placeholder sul filo. Colmare quel divario è ciò che "interrogare DynamoDB con l'AI" significa davvero — perché l'API di DynamoDB stessa non ha alcun endpoint in linguaggio naturale. Ogni richiesta è comunque expression o ; l'AI sta nel livello di tooling, traducendo la tua intenzione in esse.

Quella traduzione può essere genuinamente ottima o silenziosamente pericolosa, a seconda di una cosa sola: se il modello può vedere il tuo schema reale. Questa guida copre le tre configurazioni funzionanti e dove ognuna si rompe.

Come interrogo DynamoDB usando il linguaggio naturale?

Tre opzioni reali: chiedere a un LLM generico di abbozzare PartiQL ed eseguirlo tu stesso (veloce, ma il modello sta indovinando i nomi dei tuoi attributi), connettere un agente AI a DynamoDB tramite un server MCP così che possa ispezionare e interrogare per davvero, oppure usare un client DynamoDB con un assistente schema-aware integrato — la chat AI di DynoTable trasforma il linguaggio naturale in PartiQL o SQL contro il tuo schema indicizzato reale, calcola aggregati esatti sull'intera tabella e mette ogni scrittura in staging per la tua revisione.

Opzione 1: PartiQL abbozzato da un LLM, eseguito da te

La versione a zero setup: descrivi la query a un modello capace, ricevi PartiQL, eseguilo nell'editor PartiQL della console o via CLI:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

Funziona — e fallisce in tre modi prevedibili:

  • Il modello non può vedere la tua tabella. Inventerà con sicurezza nomi di attributi e forme di chiave (orderId quando la tua è PK = ORDER#<id>). Finisci a debuggare schema allucinato invece di scrivere la query.
  • I limiti di PartiQL si applicano comunque. Un SELECT legge esattamente una tabella, e un WHERE che non blocca una chiave diventa un full table scan — silenziosamente costoso, esattamente come se l'avessi scritto tu. Il modello raramente ti avverte; PartiQL vs SQL spiega cosa la superficie SQL compra e cosa no.
  • Incollare schema o dati in un chatbot è una decisione di data governance. Item di esempio in un prompt sono dati di produzione che escono dal tuo perimetro.

Buono per query una tantum su uno schema che puoi incollare a memoria; fragile come workflow.

Opzione 2: un agente AI connesso via MCP

La soluzione strutturale a "il modello non può vedere la tua tabella" è dare all'agente tool invece di uno schema incollato nel prompt. Il Model Context Protocol (MCP) fa esattamente questo: un server MCP espone le operazioni DynamoDB come tool tipizzati, e qualsiasi agente MCP-capable (Claude, assistenti IDE, agenti custom) può elencare tabelle, ispezionare chiavi ed eseguire query con risultati reali che rientrano nella conversazione.

Copriamo il setup completo — e le domande su consenso, scoping e sicurezza delle scritture che arrivano con il lasciare un agente toccare un database — in Usare DynamoDB con un server MCP. DynoTable stesso ne include uno: può esporre tool gated e solo-loopback ad agenti esterni, con consenso e scope per connessione.

È l'architettura giusta quando l'agente è il prodotto — un bot di supporto, un assistente Slack interno. Per il lavoro interattivo quotidiano, ti lascia comunque ad assemblare agente, server e credenziali da solo.

Opzione 3: un assistente schema-aware nel tuo client DynamoDB

L'assistente integrato di DynoTable è la versione integrata: vive accanto alle tue tabelle (⌘;) e legge il tuo schema indicizzato — le tabelle sotto il profilo attivo, le loro chiavi e indici, i percorsi e i tipi degli attributi scoperti dall'indicizzazione della tabella, persino valori di esempio — così "filtra questo alla settimana scorsa" si risolve contro i tuoi nomi di attributi reali, non un'ipotesi. Digita @ per riferirti esplicitamente a una @table, @column o @gsi.

La chat AI di DynoTable agganciata accanto a un tab tabella: una domanda in linguaggio naturale, la query generata e il risultato che si apre come vista.
La chat AI di DynoTable agganciata accanto a un tab tabella: una domanda in linguaggio naturale, la query generata e il risultato che si apre come vista.

Cosa fa con una domanda, secondo il catalogo delle capacità:

  • Scrive la query per te — PartiQL in sola lettura, o SQL del Workbench quando la domanda richiede JOIN / GROUP BY / aggregate (l'analitica che l'API di DynamoDB non ha) — e propone il risultato come una chip che clicchi per aprirlo come un vero tab.
  • Calcola risposte esatte sull'intera tabella. Chiedi un conteggio, una somma, una media o una suddivisione per gruppo e legge ogni item corrispondente, non una pagina campionata — "quanti ordini il mese scorso?" riflette la tabella reale. Può rimodellare lo stesso passaggio in un file di export trasformato.
  • Mette in staging ogni scrittura. Chiedigli di correggere una riga e la modifica atterra nell'area di staging come diff revisionabile — l'assistente non può scrivere su DynamoDB direttamente, fare batch-delete di una tabella o alterare la struttura della tabella, in nessuna modalità di permessi. Tu rivedi, tu committi.
  • Chiede prima di spendere i tuoi soldi. Le letture che colpiscono AWS e costano capacità sono dietro un permesso (Manual / Auto / Full Auto, per profilo), e ogni decisione gated finisce in un audit log locale sempre attivo.

Il modello di fiducia conta quanto le funzionalità: l'assistente gira sulle tue credenziali AWS Bedrock, parlando direttamente con Bedrock nel tuo account — prompt, schema e dati delle tabelle non passano mai dai server di DynoTable, e l'inferenza ti viene fatturata alle tariffe di Bedrock senza alcun ricarico. I risultati dei tool sono trattati come dati non fidati, quindi una riga contenente "ignore previous instructions" non può dirottare l'agente.

Cosa l'AI NON cambia di DynamoDB

Qualsiasi livello AI onesto eredita la fisica del database:

  • Gli access pattern comandano ancora. "Where status = X" su un attributo non-chiave è uno scan filtrato non importa chi lo scrive — il modello digita solo più in fretta la query costosa. Se una domanda continua a forzare scan, la soluzione è la modellazione (un GSI, una migliore sort key), non un prompt migliore.
  • Le letture costano capacità reale. Un aggregato esatto sull'intera tabella è una lettura dell'intera tabella. I buoni strumenti la mettono dietro un permesso e lo dicono; il calcolatore di prezzi ti dice quanto costa un passaggio completo prima che tu lo approvi.
  • Il determinismo ha il suo posto. Per una query che eseguirai per sempre in produzione, costruisci a mano l'expression una volta nell'Expression Builder e spedisci le esatte mappe di nomi/valori — l'AI è per l'esplorazione, il builder è per il codice che committi.

FAQ

Posso interrogare DynamoDB in linguaggio naturale? Non contro l'API stessa — DynamoDB parla solo expression e PartiQL. Ma un livello AI può tradurre: un LLM che abbozza PartiQL, un agente connesso via MCP, o un assistente schema-aware come quello di DynoTable che genera ed esegue la query contro il tuo schema reale.

DynamoDB ha una funzione AI di query integrata? L'API di DynamoDB non ha alcun endpoint in linguaggio naturale. Qualunque interrogazione AI ottieni viene dal livello di tooling sopra — motivo per cui il modello di sicurezza di quel tooling (letture gated, scritture in staging, credenziali tue) è la cosa da valutare.

È sicuro lasciare l'AI vicino a dati di produzione? È una questione di permessi. Cerca: letture dietro approvazione esplicita, scritture che atterrano in un'area di staging revisionabile invece di essere eseguite direttamente, un audit log, e inferenza su credenziali che controlli tu. L'assistente di DynoTable soddisfa tutti e quattro; un chatbot con i tuoi dati incollati nessuno.

L'AI può fare join tra tabelle o GROUP BY? Non via API DynamoDB — non esiste alcun motore per farlo. L'assistente di DynoTable risponde a quelle domande tramite il suo SQL del Workbench in sola lettura (veri JOIN, GROUP BY e aggregate dentro le regole di access pattern di DynamoDB), che è anche dove atterrano le domande di count/sum/average.

Quanto costa? Due contatori: la read capacity di DynamoDB per ciò che le query toccano (l'assistente chiede prima delle letture gated), e l'inferenza Bedrock fatturata al tuo account AWS — DynoTable non aggiunge ricarichi e non fa da proxy a nulla.

Fai la tua prossima domanda in linguaggio naturale — scarica DynoTable, punta l'AI al tuo Bedrock e tieni ogni scrittura dietro una revisione.

Aggiornato