For the purposes of discussion let's consider a FourSquare scenario.
- Checkins: users <-> places, many to many
- Friends: users <-> users, many to many
These will most likely have errors, please point them out.
- Checkins (junction)
- Friends (junction)
- CAP: consistency, availability
- CAP: partition tolerance, aka sharding
- schemes = inflexible structure
- poor replication?
- Friends: User <-> User
- Checkins: User -> Places
- contains timestamp
- CAP: consistency, availability?
- schemaless, easily mutable objects and edges
- graph traversal queries, for example:
- finding groups of friends
- finding restaurants liked by similar people
- any other common / useful queries?
- CAP: partition tolerance?
Document / Object
3 separate databases?
- friends list
- CAP: availability, partition tolerance
- schemaless, easily mutable objects
- CAP: consistency
For the record, they ended up using MongoDB. In addition to all those question marks above:
- I'm not sure how to implement a document database.
- How do document databases gain partition tolerance?
- To get a single user's checkins, I assume the operation would parse all checkins and filter the metadata for username (map + filter). The performance of parsing 1,000,000+ documents for each user would be terribly poor. I assume this is not the correct behavior?
- What other pro / cons are there?