Jonathan Ellis

<p>Let’s see how Cassandra’s architecture and implementation stands up against top distributed NoSQL competitors—Couchbase, HBase, and MongoDB. After reviewing the comparison, I think you’ll see why Cassandra is so popular with leading companies around the world.</p>

<h2>NoSQL Architecture: Apache Cassandra vs. Competitors</h2>

<p>Cassandra incorporates a number of architectural best practices that affect performance. None are unique to Cassandra, but Cassandra is the only NoSQL system that incorporates all of them.</p>

<h3>Fully distributed</h3>

<p>Every Cassandra machine handles a proportionate share of every activity in the system. There are no special cases like the HDFS <a href="http://hadoopblog.blogspot.com/2010/04/curse-of-singletons-vertical.html">namenode</a>, MongoDB <a href="http://docs.mongodb.org/manual/core/sharding/">mongos</a>, or the MySQL Fabric Process that all require special treatment. And with every node the same, Cassandra is far simpler to install and operate, which has long-term implications for troubleshooting. Even when everything works perfectly, master/slave designs have a bottleneck at the master. Cassandra leverages its masterless design to deliver <a href="https://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2">lower latency</a> as well as uninterrupted uptime.</p>

<h3>Log-structured storage engine</h3>

<p>A log-structured engine that avoids overwrites to turn updates into sequential I/O is essential both on hard disks (HDD) and solid-state disks (SSD). On HDD, it’s because the seek penalty is so high, whereas on SSD, it’s to avoid <a href="https://docs.datastax.com/en/cassandra-oss/2.2/cassandra/planning/planPlanningHardware.html">write amplification and disk failure.</a> This is why you see MongoDB performance go through the floor as the dataset size exceeds RAM.&nbsp;</p>

<p>Couchbase's append-only B-trees avoid overwrites, but <a href="http://www.bzero.se/ldapd/btree.html">require several seeks</a> when updating or inserting new documents and do not support durable writes without a large performance penalty.</p>

<h3>Locally-managed storage</h3>

<p>HBase has an integrated, log-structured storage engine, but relies on the Hadoop Distributed File System (HDFS) for replication instead of managing storage locally. This means HBase is architecturally incapable of supporting Cassandra-style optimizations like putting the commitlog on a separate disk, mixing SSD and HDD in a single cluster with appropriate data pinned to each, or incrementally pulling compacted SSTables into the page cache.</p>

<h3>Prepared statements</h3>

<p>NoSQL systems were formerly characterized by only allowing primary key lookups, and there was no query planning to speak of. Today, Cassandra and most other systems1 support indexes and increasingly complex queries.&nbsp;</p>

<p>The Cassandra Query Language allows Cassandra to pre-parse and re-use query plans, reducing overhead. Others remain stuck with primitive JSON APIs or even raw Java Scanner objects. CQL also allows Cassandra to express more sophisticated operations like <a href="https://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0">lightweight transactions</a> with a minimal impact on clients, resulting in wide support across many languages. The closest alternative is <a href="http://phoenix.apache.org/">Apache Phoenix</a>, a Java-only SQL layer for HBase.</p>

<h2>NoSQL Implementation: Apache Cassandra vs. Competitors</h2>

<p>An architecture is only as good as its implementation. For the first years after Cassandra's open-sourcing as an Apache project, every release was a learning experience. 0.3, 0.4, 0.5, 0.6, each attracted a new wave of users that exposed some previously unimportant weakness. Today, there are thousands of production deployments of Cassandra, the most for any scalable database.&nbsp;</p>

<h3>Common methods of implementing a NoSQL database</h3>

<p>When comparing each NoSQL database option, we considered the 3 most common use cases for implementation:</p>

<ul>
	<li><strong>New Applications:</strong> Begin with NoSQL by choosing a new application and start from the ground up. Such an approach mitigates the issues of application rewrites, data migrations, etc.&nbsp;</li>
	<li><strong>Augmentation:</strong> Augment an existing system by adding a NoSQL component to it. This often happens when applications outgrow RDBMS (e.g., due to scale problems, there’s a need for better availability, hybrid/cloud environments, etc.)&nbsp;</li>
	<li><strong>Full database replacement:</strong> For RDBMS systems that are simply proving too costly to keep, or are failing due to increases of user concurrency, data velocity, or data volume, a full replacement is done with a NoSQL database.</li>
</ul>

<h2>Apache Cassandra vs. MongoDB</h2>

<p>MongoDB can be a great alternative to MySQL, but it's not really appropriate for the scale-out applications targeted by Cassandra. Still, as early members of the NoSQL category, the two do draw comparisons.</p>

<h3>Updates</h3>

<p>One important limitation in MongoDB is <a href="http://docs.mongodb.org/manual/faq/concurrency/#what-type-of-locking-does-mongodb-use">database-level locking</a>. That is, only one writer may modify a given database at a time. Support for collection-level (a set of documents, analogous to a relational table) was added more recently, but, even with collection-level locking, a small number of writes would produce stalls in read performance to "hot" tables.</p>

<p>In contrast, Cassandra uses advanced concurrent structures to provide <a href="https://twitter.com/spyced/status/419302383206666240">high performance updates</a> without locking. Cassandra even <a href="https://www.datastax.com/dev/blog/performance-improvements-in-cassandra-1-2">eliminates the need for locking during index updates.</a></p>

<p>A more subtle MongoDB limitation: When adding or updating a field in a document, the entire document must be rewritten. If you preallocate space for each document, you can <a href="http://blog.pythonisito.com/2012/09/mongodb-schema-design-at-scale.html">avoid the associated fragmentation</a>. But, even with preallocation, updating your document gets slower as it grows. Cassandra's storage engine only appends updated data; it never has to rewrite or reread existing data. That means updates to a Cassandra row or partition stay fast as your dataset grows.</p>

<h3>Replication</h3>

<p>MongoDB's replication is <a href="http://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/">complex</a> and <a href="https://speakerdeck.com/mitsuhiko/a-year-of-mongodb">fragile</a>. It's relatively easy to achieve "impossible" scenarios like multiple masters for the same shard.</p>

<h2>Apache Cassandra vs. HBase</h2>

<p>HBase's storage engine is the most similar to Cassandra's; both drew on Bigtable's design early on.</p>

<p>But today, Cassandra's storage engine is far ahead of HBase's. This is primarily because building on HDFS instead of locally-managed storage makes everything more complex and less performant. Cassandra leads in SSD support, efficient use of the page cache support for large data sets, and more.</p>

<p>Cassandra's replication design is inherently more suited for delivering low latency response times, while also <a href="https://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2">tolerating failures</a> better.</p>

<p>Cassandra is also a leader in developer productivity, introducing CQL while HBase remains stuck on the difficult to use column family model. It's also worth noting that while Cassandra supports hundreds of tables, HBase "<a href="http://hbase.apache.org/book.html#number.of.cfs">does not do well with anything above two or three column families.</a>"</p>

<h2>Apache Cassandra vs. Couchbase</h2>

<p>Couchbase presents a document-based data model to the end user, but under the hood it maps everything to a key/value storage API. Like MongoDB, updating any field in a document requires rewriting the whole thing.</p>

<p>Like MongoDB, Couchbase performs asynchronous writes by default. That is: After performing a Couchbase put operation, it is buffered in memory but not on disk. This is why naive Couchbase benchmarks post such startling performance numbers. Couchbase can be forced to <a href="http://www.couchbase.com/wiki/display/couchbase/Observe">persist writes to disk</a>, but doing so kills performance; since there is no commitlog or journaling, each write must update Couchbase's B-tree and fsync.</p>

<p>Couchbase's storage engine has trouble dealing with more than five buckets (analogous to relational tables). The suggested workaround is to <a href="http://blog.couchbase.com/10-things-developers-should-know-about-couchbase">create a type attribute that will help you differentiate the various objects stored</a> in a single bucket.</p>

<p>Couchbase's replication is simpler than MongoDB's, but no more rigorous in its design. Couchbase manages to be neither fully consistent, nor fully available. It cannot serve reads during failover or network partitions, but it can still serve <a href="http://damienkatz.net/2013/05/dynamo_sure_works_hard.html">stale data to reads</a>. Couchbase nominally supports active/active cross-datacenter replication. However, if the same document is updated concurrently in both, one of the updates <a href="http://damienkatz.net/2012/05/stabilizing_couchbase_server_2.html">will be lost</a>. Cassandra solves this problem by <a href="https://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks">merging updates at the column level</a> and optionally by using <a href="https://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0">lightweight transactions</a> to opt in to a linearizable operation order. Finally, Couchbase’s cross-datacenter replication failure often <a href="http://docs.couchbase.com/couchbase-manual-2.0/#couchbase-admin-tasks-xdcr-functionality">requires manual intervention to recover.</a></p>

<h1>Conclusion: Apache Cassandra is the clear winner</h1>

<p>When you take a close look at Cassandra's architecture and implementation, its advantages over other top NoSQL databases is clear. It doesn’t matter if we’re talking about distribution, storage, queries, scaling, updates, or replication, Cassandra is the clear winner in all of the above.</p>

<p><a href="https://www.datastax.com/products/astra/demo">See how Apache Cassandra can help your company</a>.</p>

<h3>Learn more about NoSQL &amp; Apache Cassandra</h3>

<ul>
	<li>Explore our hub page: <a href="https://www.datastax.com/nosql">What is NoSQL? Non-Relational Databases Explained</a></li>
	<li>Check out our blog post on <a href="https://www.datastax.com/blog/evolution-nosql">The Evolution of NoSQL</a></li>
	<li>Download the whitepaper:&nbsp;<a href="https://www.datastax.com/resources/report/benchmarking-top-nosql-databases">Benchmarking Top NoSQL Databases</a></li>
</ul>


Build and scale cloud native apps

Discover the benefits of DBaaS and why your apps deserve an upgrade.

Learn about NoSQL Databases

Learn about NoSQL databases with Apache Cassandra and Astra DB.

2022 Recap: A Year for Customers, Community, and Real-Time Data

Highlights from 2022 and a glimpse into the year ahead.

ViewingIndustry

Apache Cassandra Architecture vs. Top NoSQL Competitors

Sign up for our Developer Newsletter