NoSQL grudge match: MongoDB vs. Couchbase Server

Which document database? From ease of installation and backup flexibility to index design and query capabilities, a few key differences point the way

1 2 Page 2
Page 2 of 2

Due to the different options of indexing, there are different options to query data in Couchbase. The most straightforward is to use N1QL, which will look familiar to anyone who has experience using SQL. The coverage of SQL syntax is impressive, and N1QL even supports a few JOINs. Additionally, N1QL augments SQL with a few handy features to help out with handling missing fields, restructuring documents, and defining conditions on nested arrays. Queries against MapReduce views can be performed using the Couchbase SDK or via the REST API directly. Because most of the work has been done in defining the views, querying is usually as simple as specifying the value or range of values you’re looking for.

Round winner: MongoDB, but Couchbase is a close second thanks to N1QL.

Aggregation

Beyond basic query operations, the database will need to support some form of aggregation. Traditionally this would be used to generate reports but also to drive user interface elements like faceted navigation.

Aggregations are defined in MongoDB using the aggregation framework. Like Unix pipes, the aggregation framework is built around the idea of data passing through a chain of small, discrete processes. Each pipeline operator takes input data, manipulates it in some way, and outputs the result. The available pipeline operators make it easy to filter documents from a collection, group by fields on those documents, restructure documents, and perform graph lookups.

With Couchbase, many simple aggregations can be accomplished using GROUP BY statements in N1QL. If N1QL doesn’t do the job, you can drop down to MapReduce views. MapReduce views are a powerful way to express aggregation, but the downside is you have to write MapReduce code.

Round winner: MongoDB.

Scalability

The ability to scale out a database cluster is necessary for dealing with growth and performance issues. While the cluster should be scaling up and down throughout the day, exactly as your API servers might, it should be a relatively easy process from an operational standpoint to add or remove capacity to the cluster.

It’s easy to add nodes to a replica set in MongoDB by simply spinning up a new node and pointing the existing replica set to the new host. All of the data is then automatically transferred to the node. It’s also possible to preseed the node with data so that only stale data has to be updated. The process to add a shard to a cluster is a little more complicated because you’ll have to spin up a replica set for the new shard. After the replica set is up, the shard can be added to the cluster via mongos and the cluster balancer will automatically redistribute the data across the cluster. The redistribution process, called chunk migration, will likely take a while. Prior to MongoDB 3.4, the cluster could migrate only a single chunk at a time; MongoDB 3.4 introduced parallel chunk migration to improve performance. Each shard can participate in only a single chunk migration at a time, but that still leaves opportunity for parallelism.

To add nodes to a Couchbase cluster, you have to spin up the new node; point it to the existing cluster via the UI, CLI, or REST API; and initiate a rebalance. The cluster will then recalculate where the data should live, move it, and update the client SDKs with the new topology. Depending on the services you choose to run on the new node, you may want to run additional commands. For example, if you’re adding a node that’s running the index service, you may want to run a N1QL query to create an index on that new node.

Round winner: Tie. Scaling out is going to be more or less equally painful in both MongoDB and Couchbase.

Documentation

In terms of reference material, tutorials, and video training, MongoDB takes a clear lead. The documentation is well organized and easily navigable, whereas the Couchbase documentation is fragmented and sparse in places. MongoDB also offers 15 free multiweek courses through the MongoDB University program. These are not on-demand like Couchbase’s 10 video courses, but they offer the ability to interact with other students and professors via forums. Couchbase has a leg up on MongoDB, however, when looking at the example apps. Couchbase’s app, despite only covering N1QL and full-text search, has reference implementations using multiple back-end languages and frameworks, including Node.js, .Net, and Go.

Round winner: MongoDB.

Final score: MongoDB 5, Couchbase 2

It’s important to note that both of these databases keep growing and expanding to cover more use cases and data models. For example, MongoDB 3.4 incorporated graph queries, while Couchbase is rolling out a fully featured text search service to augment the existing query services. The value these databases provide is constantly shifting with the landscape of application development needs. It’s hard to say what new features will be included in future releases that may tip the scales, but today the winner is MongoDB.

Couchbase’s strongest assets are N1QL for querying, the flexible approach to backups, and a built-in monitoring tool, but it stumbles on developer setup, documentation, and the necessity for MapReduce. MongoDB aligns with the development experience, providing a quick start and following through with clear documentation, as well as a unified indexing and query interface regardless of the use case.

At a Glance

Copyright © 2017 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform