consistent: to be, or not to be

About the Author

Shane K Johnson is the Director of Product Marketing at Couchbase. Prior to Couchbase, he occupied various roles in developing and evangelism with a background in Java and distributed systems. He has consulted with organizations in the financial, retail, telecommunications, and media industries to draft and implement architectures that relied on distributed systems for data and analysis.

Tags

This is from a client's point of view absent a partition and / or failover.

MongoDB

Is data in MongoDB consistent?

MongoDB executes read and write operations on the primary node, and data is consistent. However, performance is limited because clients do not leverage secondary nodes. The first alternative is to execute read operations on all nodes, primary and secondary. Read performance is better, but data is no longer consistent because replication is asynchronous by default. The second alternative is synchronous replication. The data is consistent, but write performance is worse.

Primary

Medium Read Performance, Medium Write Performance

Consistent Data

Primary + Secondary (Asynchronous)

High Read Performance, Medium Write Performance

Eventually Consistent Data

Primary + Secondary (Synchronous)

High Read Performance, Low Write Performance

Consistent Data

Data may or may not be consistent.

Couchbase Server

Is data in Couchbase Server consistent?

Couchbase Server executes all read and write operations on the primary node, and data is consistent. Performance is high because clients leverage all of the nodes. That's because every node is a primary node.

Default

High Read Performance, High Write Performance

Consistent Data

Data is consistent.

Partitioned versus Replicated

Couchbase Server and MongoDB both implement partitioning and replication. However, the implementations are different.

In MongoDB, a partition is stored within a replica set. A replica set consists of a primary node and multiple secondary nodes. If there were nine nodes, there would be three replica sets with write operations distributed to the three primary nodes. In Couchbase Server, every node is both an active primary node and a passive secondary node. If there were nine nodes, there would be nine primary nodes with write operations distributed to all them (9). This is a high level description of how data is partitioned and replicated within Couchbase Server. A low level description is available in the documentation on vBuckets (link).

If data is replicated, MongoDB would require twenty-seven nodes to distribute write operations to nine nodes.

Note

MongoDB relies on a single lock per database per node (link & link). Couchbase Server relies on document locks (more). Couchbase Server not only leverages more nodes to execute writes, it executes more writes per node.