Location based horizontal scalable dating app database model

Question

I am assessing backend for location base dating app similar to Tinder.

• App feature is showing nearby online users (with sex, and age filter)
• Some database engines in mind are Redis, Cassandra, MySQL Cluster
• The app should scale horizontally by adding node at high traffic time

After researching, I am very confused whether there is a common "best practice" data model, algorithm for this. My approach is using Redis Cluster:

// Store all online users in same location (city) to a Set. In this case, store user:1 to New York set
SADD location:NewYork 1

// Store all users age to Sorted Set. In this case, user:1 has age 30
ZADD age 30 "1"

// Retrieve users in NewYork age from 20 to 40
ZINTERSTORE tmpkey 2 location:NewYork age AGGREGATE MAX
ZRANGEBYSCORE tmpkey 20 40

I am inexperienced and can not foresee potential problem if scaling happen for million of concurrent users.

Hope any veteran could shed some light.

Answer 1

For your use case, mongodb would be a good choice.

1. You can store each user in single document, along with their current location.

2. Create indexes on fields you want to do queries on, e.g. age, gender, location

3. Mongodb has inbuilt support for geospatial queries, hence it is easy to find users within 1 km radius of another user.

Answer 2

Most noSQL Geo/proximity index features rely on the GeoHash Algorithm

http://www.bigfastblog.com/geohash-intro

It's a good thing to understand how it works, and it's really quite fascinating. This technique can also be used to create highly efficient indexes on a relational database.

Redis does have native support for this, but if you're using ElastiCache, that version of Redis does not, and you'll need to mange this in your API.

Any Relational Database will give you the most flexibility and simplest solution. The problem you may face is query times. If you're optimizing for searches on your DB instance (possibly have a 'search db' separate to profile/content data), then it's possible to have the entire index in memory for fast results.

I can also talk a bit about Redis: The sorted set operations are blazingly fast, but you need to filter. Either you have to scan through your nearby result and lookup meta information to filter, or maintain separate sets for every combination of filter you may need. The first will have more performance overhead. The second requires you to mange the indexes yourself. EG: What if someone removes one of their 'likes'? What if they move around?

It's not flash or fancy, but in most cases where you need to search a range of data, relational databases win due to their simplicity and support. Think of your search as a replica of your master source, and you can always migrate to another solution, or re-shard/scale if you need to in the future.

Answer 3

You may be interested in the Redis Geo API.

The Geo API consists of a set of new commands that add support for storing and querying pairs of longitude/latitude coordinates into Redis keys. GeoSet is the name of the data structure holding a set of (x,y) coordinates. Actually, there isn’t any new data structure under the hood: a GeoSet is simply a Redis SortedSet.

Redis Geo Tutorial

Answer 4

I will also support MongoDB on the basis of requirements with the development of MongoDB compass you can also visualize your geospatial data.The link of mongodb compass documentation is "https://docs.mongodb.com/compass/getting-started/".