Jonathan Ellis

<p>Cassandra 1.0 incorporates several improvements to how Cassandra's storage engine manages memory and disk space, bringing better performance and addressing some of the most common pain points for Cassandra administration.</p>

<h3>Off-heap row cache</h3>

<p>Cassandra provides a built-in&nbsp;<a href="https://www.datastax.com/dev/blog/maximizing-cache-benefit-with-cassandra">row cache</a>&nbsp;for super-fast access to frequently requested data, competitive with standalone caching products but without the&nbsp;<a href="http://en.wikipedia.org/wiki/Cache_coherence">cache coherence</a>&nbsp;problems that come from using a separate system, i.e., data in the cache becoming temporarily or even permanently out of sync with the database.</p>

<p>Cassandra 1.0 adds the ability to store cached rows in native memory, outside the Java heap. This results in both a smaller per-row memory footprint and reduced JVM heap requirements, which helps keep the heap size in the sweet spot for JVM garbage collection performance.</p>

<p>This off-heap row cache debuted in 0.8&nbsp;but it didn't become the default until 1.0. It requires&nbsp;<a href="http://jna.java.net/">the JNA library</a>&nbsp;to be installed; otherwise, Cassandra will automatically fall back to the old on-heap cache provider. The Debian and RPM packages of Cassandra install JNA automatically, but if you are installing from a tarball or source, you should install JNA as well. (For licensing reasons, JNA can't be distributed as part of Cassandra itself.)</p>

<h3>Storage engine self-tuning</h3>

<p>Cassandra 1.0's storage engine also self-tunes memtable sizes for the optimum balance between faster writes, reduced compaction overhead, and memory use.</p>

<p>Recall that memtables are&nbsp;the structure where Cassandra groups updates in memory&nbsp;before writing to disk. Prior to 1.0, Cassandra needed to be explicitly told&nbsp;how much space to allocate for each ColumnFamily's memtables.</p>

<p>This was tolerable but clunky for small numbers of ColumnFamilies, but whenever additional ColumnFamilies were created, the settings on the existing ones needed to be adjusted to make room. Getting this wrong was the primary cause of&nbsp;<a href="http://www.google.com/search?q=cassandra+outofmemoryerror">OutOfMemoryErrors</a>.</p>

<p>Cassandra 1.0 only uses one memtable setting:&nbsp;<tt>memtable_total_space_in_mb</tt>&nbsp;(found in cassandra.yaml), which defaults to 1/3 of your JVM heap. Cassandra manages this space across all your ColumnFamilies and flushes memtables to disk as needed. This has been tested to work across hundreds or even thousands of ColumnFamilies. (Do note that a minimum of 1MB per memtable is used by the&nbsp;<a href="https://issues.apache.org/jira/browse/CASSANDRA-2252">per-memtable arena allocator</a>&nbsp;also introduced in 1.0, which is worth keeping in mind if you are looking at going from thousands to tens of thousands of ColumnFamilies.)</p>

<p><tt>memtable_total_space_in_mb</tt>&nbsp;was&nbsp;introduced in 0.8&nbsp;and has proved successful enough that for 1.0 we've disabled the old per-ColumnFamily&nbsp;<tt>memtable_operations_in_millions</tt>&nbsp;and&nbsp;<tt>memtable_throughput_in_mb</tt>&nbsp;settings. For backwards compatibility, Cassandra still accepts those settings from applications, but they are ignored.</p>

<p>Cassandra 1.0 also introduces a global&nbsp;<tt>commitlog_total_space_in_mb</tt>, which replaces the old&nbsp;<tt>memtable_flush_after_mins</tt>&nbsp;per-ColumnFamily setting. The purpose here is to set a bound on how much data will need to be replayed on startup. Since there is a single commitlog per server, an infrequently-updated ColumnFamily could otherwise keep CommitLog segments around for an arbitrarily long time.&nbsp;<tt>commitlog_total_space_in_mb</tt>&nbsp;will cause any unflushed memtables in the oldest CommitLog segments to be written to disk when its threshold is exceeded, allowing those segments to be removed.</p>

<h3>Faster disk space reclamation</h3>

<p>Cassandra 1.0 also improves on the disk side of the storage engine, using&nbsp;<a href="https://issues.apache.org/jira/browse/CASSANDRA-2521">explicit reference counting</a>&nbsp;to reclaim obsolete data files post-compaction.</p>

<p>In older versions, Cassandra cleaned up these data files when the JVM's garbage collection ran, which resulted in unpredictable reclaiming of space. Cassandra 1.0 provides behavior that matches what operators would naturally expect, and avoids ugly hacks like forcing a GC cycle when disk space is low, which Cassandra would do automatically as a failsafe.</p>

<h3>Previously</h3>

<ul>
	<li><a href="https://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-compression">What's new in Cassandra 1.0, part 1: Compression</a></li>
	<li>What's new in Cassandra 0.8</li>
	<li>What's new in Cassandra 0.7</li>
	<li>What's new in Cassandra 0.6</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

What’s New in Cassandra 1.0: Improved Memory and Disk Space Management

Sign up for our Developer Newsletter

Share