DynamoDB 支援地理空間查詢嗎？
原生不支援。DynamoDB 沒有地理空間資料型別，也沒有距離或邊界框運算子。地理空間查詢是一種建模模式：把 geohash 或 S2 儲存格 ID 存在鍵裡，讓鄰近的點排在一起，接著查詢覆蓋你搜尋範圍的那些儲存格，再在應用程式中依精確距離收斂結果。
geohash 模式
geohash（或 AWS 的 DynamoDB Geo Library 所用的 S2 儲存格 ID）會把緯度／經度編碼成一個字串或數字，而它的_前綴_標示了一個網格儲存格 — 關鍵在於，鄰近的點會共用前綴。把它存成分割區索引鍵或排序索引鍵，「我附近的點」就變成了普通的鍵範圍查詢：
- 邊界框查詢 — 算出覆蓋一個矩形的那些儲存格，對每個儲存格
Query，再把結果合併。 - 半徑查詢 — 一樣，只是改成覆蓋一個圓形的那些儲存格，然後在用戶端依精確距離過濾。
解析度很要緊：挑一個儲存格大小，讓大多數搜尋只會碰到目標儲存格與它的鄰居。
精度如何改變查詢次數
以艾菲爾鐵塔為例，48.8584, 2.2945。它的 geohash 是 u09tunquc。640 公尺外、位於 48.8619, 2.2876 的特羅卡德羅則是 u09tup1c0。它們共用 u09tu，所以在精度 5 時位於同一個儲存格。到了精度 6 就不是了。兩個彼此看得見的地標卻落在不同儲存格裡，這正是為什麼一次儲存格查詢除了自己那格之外，總得把八個鄰格也一起納入。
每多一個字元，框就縮得更小。在這個緯度上：
| 精度 | 儲存格大小 | 5 公里半徑碰到的儲存格數 |
|---|---|---|
| 4 | 25.7 × 19.6 km | 1 到 4 |
| 5 | 3.2 × 4.9 km | 10 到 12 |
| 6 | 0.81 × 0.61 km | 185 到 193 |
每一列給的是一個範圍，因為數量取決於那個圓落在網格上的位置，而不只取決於它有多大。儲存格也會愈靠近赤道愈寬，因為那裡一度經度涵蓋的地面更多。同樣是精度 5 的儲存格，在赤道寬 4.9 公里，在巴黎則是 3.2 公里。
第三欄才是那個設計決策。精度 6 會把一次「5 公里內的餐廳」變成大約 190 次 Query 呼叫。精度 4 則讓它變成一兩次呼叫，交還一個 500 平方公里框裡的所有東西，讓你在用戶端丟掉大半。
真正咬人的不是錢。那 190 次查詢，每次以最終一致方式回傳不到 4 KB，合計 95 個讀取單位，以 us-east-1 的隨需費率算，每次搜尋約 0.000012 美元，一百萬次搜尋 11.88 美元。真正的成本是那些來回。請並行送出並限制扇出量，否則你搜尋端點的 p99 就會是那次剛好最慢的儲存格查詢。
函式庫與工具
AWS 發佈過 Geo Library for Amazon DynamoDB（Java），示範這個以 S2 為基礎的模式，社群也有其他語言的移植版（例如 Node.js 的 dynamodb-geo）。採用之前請先確認維護狀態 — 這個模式本身簡單到可以直接自己實作。
什麼時候該改用搜尋引擎
若你需要豐富的地理述詞（多邊形、依距離排序、把地理條件與全文檢索結合），請把資料表複寫到一個專用索引 — 處理全文檢索的那個零 ETL OpenSearch 整合，同時也給你一個原生支援地理空間查詢的搜尋引擎。
深入了解
這個模式本質上是排序索引鍵的把戲 — 排序索引鍵策略指南介紹了整個工具箱，運算式建構器能產生儲存格查詢所用的 begins_with／BETWEEN 條件，而 DynoTable 讓你在真實項目上檢視編碼後的鍵。
參考資料
- 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
最後驗證於 2026-07-13，對照上方連結的 AWS 官方文件。
geohash、儲存格尺寸與覆蓋數量於 2026-07-28 以標準的 base32 geohash 編碼器在緯度 48.8584 上計算。你可以拿任何 geohash 工具核對 u09tunquc。每次搜尋的成本使用我們同步的定價表中 us-east-1 的隨需讀取費率（AWS 定價 API 發佈於 2026-07-22）。