geo
Store Locator
Which stores are nearby?
Finding what is nearby, using a geohash as a sort key.
Two dimensions do not fit in one sort key, so a geohash flattens them into one: nearby places share a leading prefix. A proximity search becomes a prefix read, which DynamoDB is very good at, with none of the machinery a spatial index would need.
The model
Place
A store, with its position encoded as a geohash.
- pk
- PLACE#<placeId>
Attributes: name (S), lat (N), lon (N), geohash (S), openUntil (S), GSI1PK (S), GSI1SK (S)
Access patterns
- Query · GSI1Places in a cell
Everything inside one geohash cell, which is everything roughly nearby.
- GetItemRead one place
A single store by id.
Design notes
A geohash turns two dimensions into onewhy
Latitude and longitude cannot both be a sort key. A geohash interleaves them into a single string where a shared prefix means physical proximity, so the ordering DynamoDB already gives you becomes a spatial ordering. Nothing here is a spatial index; it is a string index used carefully.
Prefix length is the radiuswhy
Each character narrows the cell, alternating between the two axes. At this latitude four characters is about 23 km by 20 km, six is roughly 700 m by 600 m, and eight is around 23 m by 19 m - street level, not pinpoint. Shortening the prefix widens the search, so the radius is chosen by how much of the hash you key on. The table holds three cells. Central Leeds and central York are about 30 km apart and share only 'gc': two characters, a cell some 740 km across, which is most of western Europe. Holbeck is the interesting one, 1.3 km from Briggate and still in a cell of its own.
The edge case is the whole difficultytrade-off
A place fifty metres away but across a cell boundary is not in your cell, and no amount of prefixing will find it. Real implementations query the surrounding cells too - eight neighbours plus the centre - and filter by true distance afterwards. That is the honest cost of this technique: cheap reads, and an application that has to know about cell geometry.
Cells are not evenly populatedtrade-off
A cell over a city centre holds thousands of places and a cell over moorland holds none, so keying the index by cell means the partitions are as uneven as the world is. Somewhere busy enough becomes a hot partition on read, and the fix is the same as anywhere else: a finer prefix, which is to say more partitions and a smaller radius.
Read it against
- Geospatial Nearest Neighbour
The same seven places and the same question, answered twice: a geohash prefix on a sort key, and a nearest-neighbour search over the projected coordinates.
Taught in the course
- A different key for a different question - A secondary index re-keys your items so you can Query them on a new axis.
Everything inside one geohash cell, which is everything roughly nearby.
Choose an access pattern above, or build your own request. See what comes back and what it costs.
Write transactions, streams, tags and TTL are among the operations this browser build leaves out. dynoxide's native build has them.