Jonathan Ellis

<p>Cassandra 1.2 brings a number of new and improved configuration options that it is good to be aware of.</p>

<h3>Request timeouts</h3>

<p>We've split the old&nbsp;<tt>rpc_timeout_in_ms</tt>&nbsp;setting into separate timeouts for [single-row] reads, range scans, writes, truncation, and miscellanea. This allows you more fine-grained control over timeouts; in particular, range queries tend to take longer than others, and truncate requires flushing so it will also be slower.</p>

<p>We've left the defaults alone for all of these but truncate, which was extended to 60s. (Incidentally, in 1.2 truncate only needs to flush the table being emptied,&nbsp;<a href="https://issues.apache.org/jira/browse/CASSANDRA-4906">not every table in the cluster</a>.)</p>

<h3>Improved recovery from request overload</h3>

<p>Cassandra deals with request overload by&nbsp;dropping requests that are so behind that they've timed out before being processed. Prior to Cassandra 1.2, each replica tracked request timeout locally -- that is, it assumed that setting up the request on the&nbsp;coordinator&nbsp;was instantaneous. But if the coordinator is also overloaded, which is often the case, then this is not a good assumption.</p>

<p>For 1.2 we've added the ability to do this with the&nbsp;<tt>cross_node_timeout</tt>&nbsp;option. This is off by default, since it requires your Cassandra cluster's clocks to be synchronized. If you have ntp enabled or otherwise synchronize your clocks, go ahead and turn cross node timeouts on.</p>

<h3>End-to-end encryption</h3>

<p>Cassandra has supported&nbsp;SSL between cluster nodes&nbsp;since 0.8. Now we're extending that to client connections as well. Look for&nbsp;<tt>client_encryption_options</tt>&nbsp;in cassandra.yaml.</p>

<h3>Bloom filters</h3>

<p>Cassandra uses&nbsp;<a href="http://en.wikipedia.org/wiki/Bloom_filter">bloom filters</a>&nbsp;in its&nbsp;log-structured storage engine&nbsp;to avoid scanning data files that can't possibly include the partitions being queried.</p>

<p>Bloom filters are configured on a per-table basis, not globally like the above options.&nbsp;Compaction&nbsp;is also configured per-table.</p>

<p>Since&nbsp;<a href="https://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra">leveled compaction</a>&nbsp;does such a good job at minimizing the number of sstables that a given data partition can be spread across, we don't need to be quite so aggressive with the bloom filters we create. By default, Cassandra 1.2 will use a&nbsp;bloom filter false positive chance&nbsp;of 0.1 for tables using leveled compaction, and 0.01 for tables using size-tiered compaction. This results in memory savings of about 50% for those bloom filters.</p>

<h3>Others</h3>

<p>We've blogged about some other configuration changes in longer articles:</p>

<ul>
	<li>The&nbsp;<a href="https://www.datastax.com/dev/blog/binary-protocol">CQL binary protocol</a></li>
	<li><a href="https://www.datastax.com/dev/blog/handling-disk-failures-in-cassandra-1-2">Disk failure policy</a></li>
	<li><a href="https://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2">Virtual nodes</a></li>
</ul>


Configuration changes in Cassandra 1.2

Jonathan EllisTechnology

Share

Share

Request timeouts

Improved recovery from request overload

End-to-end encryption

Bloom filters

Others

More Company

DataStax Acquires Langflow to Accelerate Generative AI Development

The Top 5 DataStax Stories from 2023

2023 Recap: Data = AI

DataStax Astra DB Nabs Three Prestigious 2023 TrustRadius “Best of” Awards, Dominates the Vector Databases Category

One-stop Data API for Production GenAI