{"id":1235,"date":"2013-03-08T18:30:44","date_gmt":"2013-03-08T17:30:44","guid":{"rendered":"http:\/\/blog.fabianpiau.com\/?p=1235"},"modified":"2022-03-27T20:55:02","modified_gmt":"2022-03-27T19:55:02","slug":"comparing-nosql-couchbase-mongodb","status":"publish","type":"post","link":"https:\/\/blog.fabianpiau.com\/en\/2013\/03\/08\/comparing-nosql-couchbase-mongodb\/","title":{"rendered":"Comparing NoSQL: Couchbase & MongoDB"},"content":{"rendered":"

 <\/span>Version fran\u00e7aise disponible<\/strong><\/a><\/p>\n

\"NoSQL<\/p>\n

The NoSQL world is vast: Cassandra, MongoDB, CouchDB, Redis, HBase, Couchbase, Neo4j, BigTable and so on. Not to mention Map-reduce<\/a>, Hadoop, Hive that are quite close to NoSQL concepts… All these tools have recently been released to process very large amounts of data, what is called “Big data”. Take the example of Facebook, LinkedIn or Instagram with their millions of users and you will understand why relational databases have reached their limits.<\/p>\n

The first relational databases were released in 1979 by Oracle, it’s been over 30 years they are used and they still may be used for a long time. While the first NoSQL databases have emerged 7 years ago, if we take into account Google as the NoSQL pioneer with its BigTable<\/a> technology in 2006.<\/p>\n

For us, developers, it has become difficult to navigate in this jungle of technologies. It would need plenty of free time and energy to test all of this. Moreover, the projects we are working on are often not facing the same issues (a few hundred users at most). In this case, a classic relational database such as MySQL will do the job!<\/p>\n

This article is not an introduction to NoSQL, I suggest you read this article<\/a> or this very complete document<\/a>. They were written between 2010 and 2011. They are a bit old, but they are still accurate to understand the basics.<\/p>\n

\"MongoDB<\/a><\/p>\n

\"Couchbase<\/a><\/p>\n



\n

\n

\n

\n

\n
<\/p>\n

I will focus on these two NoSQL document-oriented databases. “document-oriented” or “document store” means that a key (identifier) matches a unique “document”. Don’t think about a complex document, but a simple JSON<\/a> formatted text.<\/p>\n

Here is a sample document:<\/p>\n

\r\n{\r\n  '_id' : '5897g42s0245afo4o473ai1e7',\r\n  'firstname': 'John',\r\n  'lastname': 'Doe',\r\n  'age': 26,\r\n  'sex': 'M',\r\n  'interests': [ 'Reading', 'Running', 'Hacking' ]\r\n}\r\n<\/pre>\n
Couchbase<\/a> and MongoDB<\/a> databases are widely used today. They compete in a market, you will understand, quite saturated. Having used MongoDB (thanks to the 10gen training<\/a>) and being aware to Couchbase (BruJUG<\/a> session), I will make a comparison (probably not very objective) of the two systems. Things are changing so fast that I guess this article may be outdated in a few months…<\/p>\n
A little history to begin with; MongoDB was created in 2009 by the 10gen company, Couchbase was created later in 2011 by the company of the same name.<\/p>\n
Today, both systems are sharing many characteristics (open source, free, compatible with most platforms, good documentation…), but they differentiate on some points.<\/p>\n

<\/p>\n
Scalability<\/h4>\n
In Couchbase, you can easily add servers to do clustering and obtain a distributed system, Couchbase is flexible enough to avoid downtime. Indeed, it relies on the power of the Erlang<\/a> language, a functional and fault-tolerant language that manages hot changes.
\nFor MongoDB, the configuration is a bit more complicated. For example, once you have defined the shard key<\/a> (the key to distribute documents within a sharded cluster), it becomes difficult to change it afterwards. The system is not as flexible, so you have to think carefully about your data modeling before you move your application into production.
\nScalability is why Couchbase is widely used in social gaming, where millions of players can play and their numbers can increase exponentially overnight.<\/p>\n
\"Advantage<\/p>\n
Monitoring tool<\/h4>\n
Couchbase comes with a turnkey package while MongoDB requires an additional subscription to a monitoring service<\/a>. You can monitor MongoDB using the command line<\/a>, but a monitoring tool without graphical interface is relatively restrictive.<\/p>\n
\"Monitoring<\/a>
Monitoring MongoDB<\/p><\/div>\n
\"Monitoring<\/a>
Monitoring Couchbase<\/p><\/div>\n
In the end, graphical products seem pretty similar, but the fact that you must register for MongoDB (even if it is free) and that the service cannot be self-hosted… Meh!<\/p>\n
\"Advantage<\/p>\n
Querying data<\/h4>\n
MongoDB includes a variety of tools to perform queries. There is an equivalent for most of SQL operators, of course making joins is not possible. Someone coming from the SQL world will not be too disoriented and will find some similar concepts such as indexes and secondary indexes. You will find all operators available on this page<\/a>.
\nWith Couchbase, there are views like in relational SQL. It is a kind of a pre-written query in JavaScript, which is based on the Map-reduce concept. And that’s all! If you want to do more complex operations like filtering or aggregating your data, you must use Elastic Search<\/a> (there is a Couchbase plugin<\/a> available). Couchbase has chosen to focus on its NoSQL engine, letting the querying side to specialized search tools.<\/p>\n
\"Advantage<\/p>\n
Conclusion<\/h4>\n
These two databases are commonly used and are supported by large communities. You will understand there is no winner or loser. As always, adopting a technology instead of another will depend on your needs.<\/p>\n

<\/p>\n
Other resources<\/h4>\n