DynamoDB prend-il en charge les requêtes géospatiales ?

Pas nativement. DynamoDB n'a aucun type de données géospatial ni aucun opérateur de distance ou de rectangle englobant. Les requêtes géospatiales sont un motif de modélisation : tu stockes un geohash ou un identifiant de cellule S2 dans la clé pour que les points voisins se trient ensemble, tu interroges les cellules couvrant ta zone de recherche, puis tu affines par distance exacte dans ton application.

Le motif geohash

Un geohash (ou un identifiant de cellule S2, comme dans la Geo Library for DynamoDB d'AWS) encode une latitude/longitude en une chaîne ou un nombre dont le préfixe identifie une cellule de la grille — et, point crucial, les points voisins partagent des préfixes. Stocké comme clé de partition ou de tri, cela transforme « les points près de moi » en requêtes de plage de clé ordinaires :

• Requête rectangulaire — calcule les cellules couvrant un rectangle, fais un Query sur chacune, fusionne les résultats.
• Requête par rayon — pareil, sur les cellules couvrant un cercle, puis filtre par distance exacte côté client.

La résolution compte : choisis une taille de cellule où la plupart des recherches ne touchent que la cellule cible et ses voisines.

Comment la précision change le nombre de requêtes

Prends la tour Eiffel, 48.8584, 2.2945. Son geohash est u09tunquc. Le Trocadéro, à 640 m de là, à 48.8619, 2.2876, donne u09tup1c0. Ils partagent u09tu : à la précision 5, ils sont dans la même cellule. À la précision 6, non. Deux monuments visibles l'un de l'autre, dans des cellules différentes — et c'est pourquoi une requête de cellule doit toujours inclure les huit voisines en plus de la tienne.

Chaque caractère resserre le rectangle. À cette latitude :

Chaque ligne est une plage parce que le compte dépend de la position du cercle par rapport à la grille, pas seulement de sa taille. Les cellules s'élargissent aussi vers l'équateur, où un degré de longitude couvre plus de terrain. La même cellule de précision 5 fait 4,9 km de large à l'équateur et 3,2 km de large à Paris.

Cette troisième colonne, c'est la décision de conception. La précision 6 transforme un « restaurants dans un rayon de 5 km » en environ 190 appels Query. La précision 4 en fait un ou deux appels qui te rendent tout ce qui se trouve dans un rectangle de 500 km² à écarter côté client.

Ce n'est pas l'argent qui mord. Ces 190 requêtes, renvoyant chacune moins de 4 Ko en cohérence à terme, reviennent à 95 unités de lecture, soit environ 0,000012 $ par recherche au tarif à la demande d'us-east-1, ou 11,88 $ pour un million de recherches. Les allers-retours sont le vrai coût. Émets-les en parallèle et plafonne le fan-out, sinon le p99 de ton endpoint de recherche sera celui de la requête de cellule la plus lente.

Bibliothèques et outillage

AWS a publié la Geo Library for Amazon DynamoDB (Java) qui illustre le motif basé sur S2, et des portages communautaires existent pour d'autres langages (par exemple dynamodb-geo pour Node.js). Vérifie l'état de maintenance avant d'en adopter un — le motif lui-même est assez simple pour être implémenté directement.

Quand utiliser plutôt un moteur de recherche

Pour des prédicats géo riches (polygones, tri par distance, combinaison du géo et du plein texte), réplique la table dans un index dédié — la même intégration zero-ETL avec OpenSearch qui gère la recherche plein texte te donne aussi un moteur de recherche avec des requêtes géospatiales natives.

Aller plus loin

Le motif est au fond une astuce de clé de tri — le guide des stratégies de clé de tri couvre la boîte à outils, l'expression builder génère les conditions begins_with/BETWEEN qu'utilisent les requêtes de cellule, et DynoTable te permet d'inspecter les clés encodées sur tes vrais éléments.

Références

• Geo Library for Amazon DynamoDB – Part 1: Table Structure — AWS Mobile Blog
• Implementing geohashing at scale in serverless web applications — AWS Compute Blog
• Supported data types and naming rules in Amazon DynamoDB — Amazon DynamoDB Developer Guide

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Geohashes, dimensions de cellule et comptes de couverture calculés le 2026-07-28 avec un encodeur geohash base32 standard, à la latitude 48.8584. Vérifie u09tunquc avec n'importe quel outil de geohash. Le coût par recherche utilise le tarif de lecture à la demande d'us-east-1 de notre table de tarifs synchronisée (publication de l'API de tarification AWS du 2026-07-22).