DynamoDB prend-il en charge la recherche plein texte ?
Non, pas nativement. DynamoDB n'a pas de recherche plein texte : pas de classement par pertinence, pas de racinisation, pas de correspondance floue — les outils de chaînes intégrés sont des comparaisons exactes, begins_with sur les clés de tri, et des filtres de sous-chaîne contains. La réponse d'AWS, c'est l'intégration zero-ETL avec Amazon OpenSearch Service, qui réplique une table dans un index de recherche pour la recherche plein texte, vectorielle et sémantique.
Ce que tu peux faire nativement
begins_withsur une clé de tri — correspondance de préfixe efficace à l'intérieur d'une partition ; la colonne vertébrale des modèles de clés de tri hiérarchiques.containsdans une expression de filtre — correspondance de sous-chaîne, mais les filtres s'exécutent après la lecture : sur un Scan, tu paies donc quand même la lecture de chaque élément examiné. Voir le guide des stratégies de filtrage pour savoir quand c'est acceptable.
Ni l'un ni l'autre ne classe les résultats, ne tolère les fautes de frappe ou ne comprend les limites de mots — ce sont des prédicats de chaînes, pas de la recherche.
La même requête, quatre façons, mesurées
Nous avons chargé 100 éléments (84 KB) avec des titres de produits et scanné la table quatre fois, en ne changeant que le terme recherché :
| Filtre | Count | ScannedCount | Unités de lecture | Correspondances |
|---|---|---|---|---|
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 | rien |
Lis ces lignes comme le ferait quelqu'un qui tape dans un champ de recherche. "run" rate Running shoes et RUNNING SHORTS, parce que la comparaison est sensible à la casse. "Run" récupère Running shoes, rate toujours RUNNING SHORTS, et ramène Rungs for a ladder, parce qu'une sous-chaîne n'a aucune idée de l'endroit où commence un mot. Aucune casse de cette requête ne trouve les trois. Enlève une lettre et tu n'obtiens plus rien du tout, puisqu'il n'y a aucun repli flou vers lequel dégrader.
La dernière colonne est la partie qui coûte de l'argent. Chaque scan a consommé 11 unités de lecture, y compris celui qui n'a rien trouvé, parce que le filtre s'exécute après la lecture. AWS le dit clairement : "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." Et voici leur propre diagnostic de la forme ci-dessus : "A high ScannedCount value with few, or no, Count results indicates an inefficient Scan operation."
Le prix d'une recherche suit donc la taille du catalogue, jamais la spécificité de la requête. Branche ça sur un champ de recherche instantanée et « running shoes » facture la table entière treize fois, une par frappe, pour renvoyer un seul élément.
La réponse native d'AWS : zero-ETL vers OpenSearch
Le plugin DynamoDB pour OpenSearch Ingestion synchronise une table vers un ou plusieurs index OpenSearch : un instantané initial est chargé via l'export S3 de DynamoDB (PITR requis), puis DynamoDB Streams réplique les changements en quasi temps réel. Le pipeline ne consomme aucun débit de lecture ou d'écriture de ta table : il est donc sans danger à côté du trafic de production — et AWS indique que l'intégration permet la recherche plein texte, vectorielle et sémantique sur tes données DynamoDB.
Aller plus loin
Si ta « recherche » est en réalité une lecture ciblée connue, corrige plutôt le modèle — les guides sur les stratégies de filtrage et les stratégies de clés de tri montrent ce que les clés savent faire. Prototype des conditions begins_with/contains dans l'expression builder, et télécharge DynoTable pour filtrer les données d'une table en direct pendant que tu explores.
Références
- 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
Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.
Les quatre scans ont été exécutés le 2026-07-28 sur DynamoDB Local 3.3.0 avec @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0. Count, ScannedCount et les unités de lecture sont les chiffres du moteur lui-même.