DynamoDB supporta la ricerca full-text?
No, non in modo nativo. DynamoDB non ha ricerca full-text: niente ranking di rilevanza, niente stemming e niente fuzzy matching — gli strumenti integrati sulle stringhe sono confronti esatti, begins_with sulle chiavi di ordinamento e filtri di sottostringa contains. La risposta di AWS è l'integrazione zero-ETL con Amazon OpenSearch Service, che replica una tabella in un indice di ricerca per ricerca full-text, vettoriale e semantica.
Cosa puoi fare in modo nativo
begins_withsu una chiave di ordinamento — matching efficiente per prefisso all'interno di una singola partizione; la spina dorsale dei modelli con chiavi di ordinamento gerarchiche.containsin una filter expression — matching di sottostringa, ma i filtri girano dopo la lettura, quindi su uno Scan paghi comunque per leggere ogni Item esaminato. Vedi la guida alle strategie di filtraggio per capire quando è accettabile.
Nessuno dei due ordina i risultati per rilevanza, tollera i refusi o capisce i confini delle parole — sono predicati su stringhe, non ricerca.
La stessa query, in quattro modi, misurata
Abbiamo caricato 100 Item (84 KB) con titoli di prodotto e fatto lo scan della tabella quattro volte, cambiando solo il termine di ricerca:
| Filtro | Count | ScannedCount | Unità di lettura | Corrispondenze |
|---|---|---|---|---|
contains(title, "run") | 3 | 100 | 11 | Shoes for runs · Trail running shoe · Sneaker, runner grade |
contains(title, "Run") | 2 | 100 | 11 | Running shoes · Rungs for a ladder |
contains(title, "running") | 1 | 100 | 11 | Trail running shoe |
contains(title, "runing") | 0 | 100 | 11 | nulla |
Leggi quelle righe come le leggerebbe un utente che digita in una casella. "run" manca Running shoes e RUNNING SHORTS, perché il confronto è case-sensitive. "Run" recupera Running shoes, continua a mancare RUNNING SHORTS e si tira dietro Rungs for a ladder, perché una sottostringa non ha idea di dove inizi una parola. Nessuna combinazione di maiuscole e minuscole di quella query li trova tutti e tre. Salta una lettera e non ottieni proprio nulla, dato che non c'è alcun fallback fuzzy a cui degradare.
L'ultima colonna è la parte che costa. Ogni scan ha consumato 11 unità di lettura, incluso quello che non ha trovato nulla, perché il filtro gira dopo la lettura. AWS lo dice chiaramente: "A filter expression is applied after a Scan finishes but before the results are returned. Therefore, a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present." E questa è la loro diagnosi della forma qui sopra: "A high ScannedCount value with few, or no, Count results indicates an inefficient Scan operation."
Quindi il prezzo di una ricerca segue la dimensione del catalogo, mai la specificità della query. Collega questo a una casella con ricerca mentre si digita e "running shoes" fattura l'intera tabella tredici volte, una per battuta, per restituire un solo Item.
La risposta nativa AWS: zero-ETL verso OpenSearch
Il plugin DynamoDB per OpenSearch Ingestion sincronizza una tabella in uno o più indici OpenSearch: uno snapshot iniziale viene caricato tramite l'export su S3 di DynamoDB (richiede il PITR), poi DynamoDB Streams replica le modifiche quasi in tempo reale. La pipeline non consuma nulla del throughput di lettura o scrittura della tua tabella, quindi è sicura accanto al traffico di produzione — e AWS afferma che l'integrazione abilita la ricerca full-text, vettoriale e semantica sui tuoi dati DynamoDB.
Approfondisci
Se la tua «ricerca» è in realtà un lookup noto, sistema piuttosto il modello — le guide sulle strategie di filtraggio e sulle strategie per la chiave di ordinamento mostrano cosa possono fare le chiavi. Prototipa le condizioni begins_with/contains nell'expression builder, e scarica DynoTable per filtrare i dati di una tabella live mentre esplori.
Riferimenti
- DynamoDB zero-ETL integration with Amazon OpenSearch Service — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Comparison operator and function reference — Amazon DynamoDB Developer Guide
- Scanning tables in DynamoDB — Amazon DynamoDB Developer Guide
Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.
I quattro scan sono stati eseguiti il 2026-07-28 su DynamoDB Local 3.3.0 con @aws-sdk/client-dynamodb 3.1095.0 su Node v24.18.0. Count, ScannedCount e le unità di lettura sono i numeri del motore stesso.