Cassandra instead of MySQL for social networking app

Question

I am in the middle of building a new app which will have very similar features to Facebook and although obviously it wont ever have to deal with the likes of 400,000,000 million users it will still be used by a substantial user base and most of them will demand it run very very quickly.

I have extensive experience with MySQL but a social app offers complexities which MySQL is not well suited too. I know Facebook, Twitter etc have moved towards Cassandra for a lot of their data but I am not sure how far to go with it.

For example would you store such things as user data - username, passwords, addresses etc in Cassandra? Would you store e-mails, comments, status updates etc in Cassandra? I have also read alot that something like neo4j is much better for representing the friend relationships used by social apps as it is a graph database. I am only just starting down the NoSQL route so any guidance is greatly appreciated.

Would anyone be able to advise me on this? I hope I am not being too general!

Answer 1

For example would you store such things as user data - username, passwords, addresses etc in Cassandra?

No, since it does not guarantee consistency. Cassandra is eventually consistent. Surely there shouldn't be concurrency on a certain user account's data, but I wouldn't want to bet on it. You might not need consistency on your fulltext search, your message inbox, etc. but you want consistency in anything that is security-related.

I have also read alot that something like neo4j is much better for representing the friend relationships used by social apps as it is a graph database.

I'm a big fan of the right tool for the right job. I haven't used neo4j but I've been using db4o (which is an object database) and find it very helpful. It makes development easier to use a tool that natively supports your needs. Since you need graphs and working with graphs in SQL is a pain, I'd recommend to give it a look, and evaluate whether it fits your specific needs.

Mixing databases sounds like a good idea to me as long as the choice is natural (i.e. the respective database is helpful with the specific jobs, a graph databases for graphs, a table for tables, ACID databases for anything that needs transaction safety, etc...).