I'm writing a project for school - Tinder-like app. I thought of implementing database entirely in RDBMS (PostgreSQL). But now I think it's a good opportunity to get to know NoSQL systems a bit. I'm closest to using Redis (seems fast and friendly), but I'm also thinking about:
- MongoDB (very popular)
- ElasticSearch (seems to be interesting, it's said to handle complex searches)
- Neo4j (just because I like graphs)
The problem is that I don't know how shift from the queries I know, to using NoSQL-way.
What I thought of doing To have "core" database in Postgres - it's the information about user in multiple tables, maybe other structured info. The part in NoSQL should store current user location and his reaction to partner recommendation.
Location stores last geolocation data user sent (either updates user location or inserts new row with location)
Suggestion stores user reaction to seeing another users profile
So for preparing partner suggestions the SQL query would go like this (lets assume the query takes
input_location as bind parameters; it's just a prototype).
SELECT l.userid FROM location AS l WHERE ST_distance(l.location, input_location) < 1000 AND l.gender = input_gender_preference AND NOT EXISTS (SELECT 'x' FROM suggestion s WHERE (s.userid = l.userid AND s.suggested_userid = input_userid) OR (s.user_id = l.input_userid AND s.suggested_userid = l.userid AND s.approved = TRUE))
Ok, but how to make it in any of the systems I listed?
rejected_by, duplicate entries in reversed key-value:
- get set of users seen by current user, from merging
- get set of users who rejected current user profile from
- merge the sets above
- get a set of users nearby from
- subtract (5) - (4)
- filter (6) by
It seems like creating a lot of unnecessary traffic.
What I would ask of you
I ask you for starting points - how to handle such situations. I would like to try some non-SQL approaches to handling data.