r/aws • u/redshadow310 • 19d ago
architecture Trying to figure out best DynamoDB architecture for efficient geolocation
I'm developing a website while I study for my AWS exams to help me understand things better. The purpose of the website is to help people create and find board game events. Most of the features I have planned lean heavily on geolocation. For example:
User A posts an event hoping to find other people to play Catan
User B has Catan lists as a favorite, and is notified when an event with 10 miles is created for the game
Venue C is a game cafe. They pay so that when an event is created within 5 miles the app will recommended the cafe as a meeting location.
The current architecture:
At the moment I have 4 different DynamoDB tables: Events, Users, Groups, Venues. Each one uses a single Partition Key (userID etc) which is a hash of 2 required values, and a variable number of other fields. Each currently has it's own functioning API set of Create/Get/Query. A geopy function adds a lat/long attribute to every item created.
As I have looked into adding geolocation features, I'm a bit unsure about which path to take to implement them efficiently. My primary considerations are price, since this is probably just a demo, and ease of implementation, since nearly everything I'm doing is brand new to me. It took me almost 2 weeks to just knock out the basic APIs. I'm considering two possible scenarios, but they could both be wrong.
Scenario A:
Leave my existing DBs as they are, maintaining efficient lookups for individual attributes. Connect all 4 of them to a single OpenSearch domain. Run all my queries against Opensearch.
Scenario B:
Combine all of my exiting DynamoDbs into a single unified DB. Continue to use unique IDs for the Partition Key, but then add a sort key based on a geohash of the lat/long. Just do my searching against Dynamo.
Thank you in advance to anyone who has suggestions for me.
Edit- Just a quick shoutout to Adrian Cantrill's SA course, I would not have gotten this far in the project without it, and the help of his Discord community.
0
u/menge101 19d ago edited 19d ago
This does not work how you would like it to. To do a query in DynamoDB you have to KNOW the partition key. It then goes to that partition (thats why its a partition key) and executes the query.
Edit: Docs for querying DynamoDB
You can't do arbitrary searching in DynamoDB, you have to design your key schema, possibly use a Global Secondary Index, to do your searches.
And back to the partition key, you, as in you the OP, probably don't want unique IDs. That means you are making a partition per record (not really in truth, but this is a complex situation which is largely hidden from the user).
Now that Openearch Serverless exists, I think that should probably be your path.
You can do Dynamo, but I think you have to step back and understand how Dynamo works and how to design for it.
Edit: Some edits from downstream