The Battle of the NoSQL Databases – Comparing MongoDB and CouchDB

MongoDB and CouchDB both are the types of document-based NoSQL databases. A document database is also called mdocument store, and they are usually used to store the document format of the semi-structured data and detailed description of it. It allows the creation and updating of programs without the need to refer to the master schema. Content management and handling of data in the mobile application are two of the fields where the document store can be applied.

Overview of MongoDB

MongoDB was the startup of 10gen, which originated in 2007. Coming from the family of Document stores, it is one of the typical NoSQL, schema-free databases with comparatively high performance, scalability, and is rich in data processing functions. This open-source database is written in C++ and makes use of dynamic schemas. The architecture of MongoDB contains documents grouped into collections based on their structure. This database makes use of BSON. BSON is the binary representation of JSON and supports document storage and data interchange. In MongoDB, business subjects can be stored in a minimum number of documents, which can be indexed primarily or secondarily, without breaking them into multiple relational ones.

Along with the above-mentioned capabilities of MongoDB, it also provides a large replica sets collection where each set can contain more than one copy of data. In the replica sets, all primary functions (read and write) are performed on the primary set while secondary sets are used in case of failure of the former one. MongoDB incorporates sharding, which makes use of the scaling process horizontally. The load balancing property of this document store database is justified by the fact that it runs on multiple servers, thereby providing duplication of data and balancing of the load. In return, it also provides backup during the hardware failure. It also makes use of a grid file system which divides the particular file into different parts and stores them separately.

The common features of MongoDB:

• The data model design reduces the need for joins and provides easy evolution of schema.
• High performance, as it contains neither join nor transactions which provide fast accessing and hence performance is increased.
• High availability due to the incorporation of replica sets that are able to provide backup during failures and also are highly robust.
• Ease in scalability. 
• The sharding property of MongoDB enables it to perform fast and in an efficient manner in the distributed functions. This is also possible since it supports horizontal scaling of data.
• Language is highly rich in the query. MongoDB has its own query language called Mongo query language, which can replace SQL ones. Similarly, utility functions and map or reduce can replace complicated aggregate functions.

Figure 1: MongoDB Architecture

Overview of CouchDB

CouchDB, an Apache Software Foundation Product and inspired by Lotus Notes, is also an open-source document-based NoSQL database that focuses mainly on easy use. It is a single node database, working exactly like other databases. It generally starts with the single node instance but can be seamlessly upgraded to the cluster. It allows the user to run a single database on many servers or VMs. A CouchDB cluster provides high capacity and availability as compared to single node CouchDB. It uses Erlang, a general-purpose language. Like MongoDB, it also uses javascript and map/reduce. It stores data in the form of a collection of documents rather than as tables. The updated CouchDB is lockless, which means there is no need to lock the database during writes. The documents in this database also make use of HTTP protocol and JSON, along with the ability to attach non-JSON files to them. So, CouchDB is compatible with any application or software that supports JSON format.

The common features of CouchDB

• A CouchDB server hosts named databases, which store documents with an uniquely named in the database, and CouchDB provides a RESTful HTTP API for reading and updating (add, edit, delete) database documents
• CouchDB provides a browser based GUI to handle  the data, permission and configuration.
• CouchDB provides the simplest form of replication.
• CouchDB facilitates authentication and Session Support: to keep authentication open via a session cookie like a web application.
• CouchDB provides database-level security where the permissions per database are separated into readers and administrators. Readers are allowed to read and write to the CouchDB database.
• CouchDB validates the inserted data into the database using authentication to verify the creator and login session id are the same.

Figure 2: CouchDB Architecture

REST API is used to write and query the data. It also offers document read, add, edit, and delete. It uses the ACID model rather than BASE by MVCC implementation. Just like MongoDB supports the replication of devices when they are offline. It uses a special replication model called Eventual Consistency. CouchDB is highly and seriously reliable in terms of data. Single-node databases make use of an append-only crash-resistant data structure, and a multimode or cluster database can save the data redundantly so that it can be made available whenever the user needs it. CouchDB can be scaled along as big clusters as global clusters to as small ones as mobile devices. The ability to run on any Android or iOS devices makes CouchDB stand out among other databases.

The CouchDB architecture is distributed, which supports bidirectional synchronization. It does not require any schema as it makes use of a unique id. Although CouchDB follows the AP (availability and partition tolerant) feature of the CAP model, to overcome the traded consistency, it follows the ACID model on a practical basis.

Comparisons Between CouchDB and MongoDB

CouchDB and MongoDB: Vastly Different Queries

CouchDB and MongDB are document-oriented data stores which work with JSON documents but when it comes to queries, both databases couldn’t be any more different. CouchDB requires pre-defined views (which are essentially JavaScript MapReduce functions) and MongoDB supports dynamic-queries (basically what we are used to with normal RDBMS ad-hoc SQL queries).

For example, in order to insert some data in CouchDB using Groovy’s RESTClient and issue a RESTful post as below:

import static groovyx.net.http.ContentType.JSON

import groovyx.net.http.RESTClient

 def client = new RESTClient("http://localhost:5498/")

response = client.put(path: "parking_tickets/1280002020",

  contentType: JSON,

  requestContentType:  JSON,

  body: [officer: "Micheal Jordan",

      location: "189 Berkely Road",

      vehicle_plate: "KL5800",

      offense: "Parked in no parking zone",

      date: "2020/02/01"])

Sample code a function to query any document whose officer property is “Micheal Jordan”:

function(doc) {

  if(doc.officer == "Micheal Jordan"){

emit(null, doc);

  }

}

When  we issue an HTTP GET request to that view’s name, we can expect at least one document as below:

response = client.get(path: "parking_tickets/_view/by_name/officer_grey",

     contentType: JSON, requestContentType: JSON)

assert response.data.total_rows == 1

response.data.rows.each{

   assert it.value.officer == "Micheal Jordan"

}

MongoDB works much like we are used to with normal databases: we can query for whatever our heart desires at runtime.

Inserting the same instance of a parking ticket using MongoDB’s native Java driver:

DBCollection coll = db.getCollection("parking_tickets");

BasicDBObject doc = new BasicDBObject();



doc.put("officer", "Micheal Jordan");

doc.put("location", "189 Berkely Road ");

doc.put("vehicle_plate", "KL5800");

//...

coll.insert(doc);

To query any ticket from MongoDB issued by Officer Micheal Jordan by simply issuing a query on the officer property:

BasicDBObject query = new BasicDBObject();

query.put("officer", "Micheal Jordan");

DBCursor cur = coll.find(query);

while (cur.hasNext()) {

   System.out.println(cur.next());

}

Conclusion

In this blog, we have compared two document-based NoSQL databases- MongoDB and CouchDB. The table gives an overview of the main parametric comparisons between these two databases. As we have seen, the priority of the project will determine the selection of the system. Major differences include the replication method and platform support. Also, from the comparisons, it is clear that if the application requires more efficiency and speed, then MongoDB is a better choice rather than CouchDB. If the user needs to run his database on mobile and also needs multi-master replication then CouchDB is an obvious choice. Also, MongoDB is suited better than CouchDB if the database is growing rapidly. The main advantage of using CouchDB is that it is supported on mobile devices (Android and iOS) rather than MongoDB. So basically, different application requirements will require different databases based on scenarios.

We have observed that MongoDB is slightly better than CouchDB as it uses the SQL-like structure of querying, and the same is easier in the former one. Also, for using dynamic queries, MongoDB is a far better choice. Regarding security in both databases, research is still going on, and it is hard to say which of these provides a better and secure environment.