Traditional relational databases are inadequate for big data. In fact, NoSQL databases, with looser consistency models, work better. Such databases are highly scalable, and even allow horizontal scalability. They are flexible as well, allowing growing or changing schemas with remarkable ease.

Most document oriented NoSQL databases adopt JSON (JavaScript Object Notation) to define documents, or the collection of named data fields in the database. Unlike RDBMS databases, where every row in a given table must have the same columns, with JSON, each document has its own schema.

Until recently, most developers preferred MongoDB for a document oriented NoSQL databases. But of late, Couchbase is posing a serious challenge to MongoDB’s dominance. In a way MongoDB and Coucchbase share many similarities. Both databases use JavaScript as the primary data manipulation language, employ JSON, run on commodity hardware, and facilitate horizontal scaling. Both of them provide APIs for almost all popular programming languages, allowing applications to access the database directly.

Initially, Couchbase had the limitation of the database storing the JSON data as a single entity, making it effectively a key/value database. However, Couchbase Server 2.0, released in December 2012 removes this shortcoming and makes it a full-blown “document database.” The Couchbase Management GUI offers easy to use GUI consoles for management, for which Mongo DB has no answer. The management in MongoDB is through command lines.

However, MongoDB has been quick to step up to the challenge. Unlike Couchbase, MongoDB has always been a document database. MongoDB also uses Binary JSON (BSON). BJSON is a superset of JSON and defines more data types compared to the latter. MongoDB 2.4, released in March 2013, incorporates many performance and usability enhancements. MongoDB 2.4 handles documents better than Couchbase. It is possible to undertake both management and development activities on a MongoDB database. The shell hosts collections, documents, and databases as first-class entities.

The cloud-based MongoDB Monitoring Service (MMS) not only gathers statistics, but also offers seamless connectivity between the abstracted data objects found in the mongo shell and the modelled entitles of the database. This has many uses. For instance, it becomes possible to create an index based on a specific document field, with a single function call. Creating indexes in Couchbase require more complex mapreduce operations.

The bottomline: richer querying and indexing options, combined with superior ease of use, allow MongoDB to ward off the threat thrown up by the Couchbase Server.

Comments (2)

Cloud-User (4 years ago)

Hi there, I need to implement an idea and wondering whether you can help me find the solution or may be a good part of the solution. Basically I want to use Memcached to cache data for my application. However the data in the Memcached is to be loaded from NoSQL (probably Json documents), and the data in Json documents is to be imported automatically from database (Mysql) (periodically or upon modifications of Memcached data). Also during the process I will need to apply some Map/Reduce operations on the Json documents (periodically). I hope this makes sense to you, and I look forward to receiving your suggestions. Your reply is very much appreciated. Thanks

Tugdual Grall (4 years ago)

Hello, Nice post, I would like to add something on this topic. You are talking about 2 topics to help people select a database: easy of use (Flexible Schema, Queries, ...) and Monitoring. I think an important part is missing, especially when talking about NoSQL engine: the scalability. I believe that it is quite important to see how the solution scale: - when you add more and more data - when you have a large number of operation per seconds (read/write ...) So how the database server react under the load and how can you scale your cluster (adding, removing new nodes to the cluster..) and the impact to your application (live system update, performance, ...) and system administrator. This also means to deal with failure, when you have a large cluster how does the cluster react, how do you failover/recover from it. This would be a good addition to this comparison. Disclaimer: I am working at Technical Evangelist at Couchbase ... Regards Tug @tgrall