1. PlanetCassandra.org 2013
C*Cassandra 1.2
Eddie Satterly
Splunk- Chief Evangelist, Office of CTO
esatterly@splunk.com

2. PlanetCassandra.org 2013
C*
• Concurrent Schema changes
• Virtual nodes (vnodes)
• Off-heap bloom filters & compression metadata
• Improved JBOD functionality
• Query Profiling & Tracing
• Atomic batches
• CQL 3
• Collections
Highlighted Features in 1.2

3. PlanetCassandra.org 2013
C*
Concurrent Schema Changes

4. PlanetCassandra.org 2013
C*
Vnodes Advantages
•Rather than just one or a few nodes
participating in bootstrapping a new
node, all nodes participate
•No longer a need to stay with thin
nodes as the impact is much smaller on
nodes
•Vnodes automatically maintain the data
distribution (balance) of the cluster so
no need to perform rebalance after
cluster modification
•Instead of each node having a token a
new configuration num_tokens per
cluster
•Simple to upgrade a cluster for Vnodes
support

5. PlanetCassandra.org 2013
C*

6. PlanetCassandra.org 2013
C*

7. PlanetCassandra.org 2013
C*
Off-heap bloom filters & metadata
• Reduces the Java heap requirements for large datasets to
reduce garbage collection impact on performance and
stability (1-2GB per billion rows)
• Moves memory used for Bloom Filters & compression
metadata into native memory (~20GB per TB compressed
data)

8. PlanetCassandra.org 2013
C*
Improved JBOD functionality
• In Prior versions a single disk failure could make a node
unavailable for I/O
• 1.2 introduces a new disk_failure_policy setting that allows
a choice from two policies that deal with failure:
• best_effort – This setting means that if Cassandra cant
write to a disk it will become blacklisted for writes
and the node will continue writing elsewhere. If
Cassandra cant read from a disk it will mark it as
unreadable and continue serving data from readable
sstables only.
• Ignore – This setting causes Cassandra to behave in
exactly the same way as in previous versions

9. PlanetCassandra.org 2013
C*
Query Profiling & Tracing
• All new performance diagnostic utilities aimed at
helping understand, diagnose and troubleshoot CQL
statements
• You can:
• interrogate individual CQL statement in an ad-hoc
manner
• Perform a system-wide collection of all queries
that are sent to a cluster
• Cassandra provides a description of each step along
with what nodes(s) are affected, time per step and
total time of request (example follows)

10. PlanetCassandra.org 2013
C*
Tracing Example

11. PlanetCassandra.org 2013
C*
Atomic Batches
• In 1.2 batches are now guaranteed by default to be atomic
and are handled differently than earlier version. Steps are:
• Batch is first written to a new system table that
consumes the serialized batch as blob data
• After the rows in the batch have been successfully
written and persisted (or hinted) the system table
entry is removed
• This is the new default behavior and it should be noted
that for this there is a performance penalty so for use
cases that don’t necessitate a BEGIN UNLOGGED BATCH
can be issued

12. PlanetCassandra.org 2013
C*
CQL3
• There are several enhancements to CQL 3 in 1.2 and you should
review the full documentation for a complete overview.
• Some of the main new features are:
• ALTER KEYSPACE
• Commands to view TTL time remaining
• Conditional operators
• Limited Ordering
• New metatdata tables in system keyspace for
• Keyspace – Quick reference for keysapce metadata
• Local - Supplies demographic for the local node
• Peer – Supplies demographic for peer nodes in cluster

13. PlanetCassandra.org 2013
C*
Collections
• All new mechanisms for storing data called collections which
provide easier methods of inserting and manipulating data with
multiple items in a single column
• There are 3 different types of collections you can select from
• Sets – Group of elements that are returned in sorted order
when queried
• Lists – Group of elements that allows for append and
prepend and allows refernce by index
• Maps – Maps one thing to another in a pair