Is Couchbase good as the main db for social network site?

Couchbase Server
1

There are many graph databases (one of NoSQL classifications) out there, but I heard read times (performance wise ) are really weak to use them as primary database, and are only good to be used in conjunction with some RDBMS.

Social network sites have a lot of relations. How can document-based database storing things in JSON can deal with complex graphs like that?

How can it outperform RDBMS which are made with “relations” in mind? I think even NoSQL graph databases can’t really outperform RDBMS when it comes to relationships.

The main and the only reason to use NoSQL is "scalability " and “flexibility” . Those are the main factors to consider them. Because they are designed to work with big data and scalability.

And because they’re schema-less but that’s partially true because schema is somewhat defined in application’s code.

Regarding flexibility and schema-less:

  • When using RDBMS with some ORM like Entity Framework (C#) it’s not that painful to use. And gives you some nice migration capabilities when your models change.

For example facebook was built entirely on MySQL(first, and they still use it). What if it was built now when Couchbase is available, would it be a good use for them?

How can you convince me to use Couchbase as the main db for social networking site?

2

Hi,

"For example facebook was built entirely on MySQL(first, and they still use it). "
I’m pretty sure this phrase is not true, they might have used it in the V1, but Facebook was a well-known Cassandra user for a long time, and they had some serious issues with eventual consistency.

"And because they’re schema-less but that’s partially true because the schema is somewhat defined in application’s code."

I totally agree, a better definition would be “schema-flexible” but this is one of those things that suffers from bad naming (like NoSQL , for instance)

How can it outperform RDBMS which are made with “relations” in mind? I think even NoSQL graph databases can’t really outperform RDBMS when it comes to relationships.

There are some misconceptions here, the reason why RDBMS rely so much on relationships is that the data model is limited. If in your code you treat the User and UserPreferences as a single entity, why do we have to store it in different tables in the database? Storing that kind of thing separately when they only make sense together feels like a waste of resources.

The relationship of entities in a RDBMS are also totally different than a relationship in a GraphDatabase for instance, as in the first case they are not designed to be traversed (something really useful when you need to build a social network)

JOINS are also supported by Couchbase for quite a long time (you can even create indexes to speed up your joins), but they will naturally be less necessary in this case.

Turns out that I have built an enterprise social network for 5 years (we were using couchbase, that is one of the reasons why I joined CB later), and in our case, a combination of a Document Database and a Graph Database was really useful for us.

Document Database: Fast reads/writes to get user profiles, posts, timelines, etc;
Graph Database: Posts/Friendship recommendations, analysis of user engagements, etc

One last thing: RDBMS are also not good at scaling, after 5… 6 nodes you will only scale your reads, not your writes. Because those read replicas naturally have some delays until they get the latest version of your data, you will also have to deal with stale reads.

Couchbase really shines when you need performance at scale, and that is why I think according to my personal experience with it that it is a good solution for this use case.