What's new in Apache Cassandra 2.1

An overview of new features in Apache Cassandra.

New features:

User-defined types
Collection indexes
Better implementation of counters that makes them safer, simpler, and typically faster
New listsnapshots and reloadtriggers nodetool commands
Improved metrics reporting through the use of the metrics-core library

Performance improvements:

Faster reads and writes than previous releases
Improved row cache
Reduced heap used by memtables
New counters implementation

Compaction and repair improvements:

Post-compaction read performance
A configurable percentage of cold SSTables can be ignored
Incremental node repair

Other notable changes:

Pre-Cassandra 2.0 SSTables are no longer supported in Cassandra 2.1 and later. To upgrade to Cassandra 2.1 from a previous release that stored Cassandra 1.2.x SSTables, see the Apache Cassandra website.
The shuffle utility for migrating to virtual nodes (vnodes) and the nodetool taketoken command have been removed. To migrate to vnodes, bootstrap a new data center.
Cassandra 2.1 bundles and enables JNA. If JNA fails to initialize, you can disable JNA by using the -Dcassandra.boot_without_jna=true option to start Cassandra.
Incremental replacement of compacted SSTables has been disabled.
Improved Hadoop support
Unique table IDs
Improved logging using logback
New configuration options for allocating and managing memtable memory
Improvements to bootstrapping a node that ensure data consistency
A number of other CQL and cqlsh changes
Configurable properties have been added to manage counter writes.
A configurable counter cache reduces lock contention and helps with concurrency.
CASSANDRA-6504 has been backported to Cassandra 2.0.5 so you can perform a rolling upgrade of a database having counters to Cassandra 2.1.
Default data and log locations have changed for tarball installations and source checkouts. By default, the data file directory, commitlog directory, and saved caches directory are in $CASSANDRA_HOME/data/data, $CASSANDRA_HOME/data/commitlog, and $CASSANDRA_HOME/data/saved_caches, respectively. The log directory now defaults to $CASSANDRA_HOME/logs. If not set, $CASSANDRA_HOME, defaults to the top-level directory of the installation. Deb and RPM packages continue to use /var/lib/cassandra and /var/log/cassandra by default.
Cassandra 2.1 maintains data consistency during bootstrapping. As you bootstrap a new node, Cassandra streams the data for the new node from an existing node that is free from range movement. If data inconsistency issues are present in the cluster, the improvement to bootstrapping handles these issues. Data inconsistency commonly occurs after frequent data deletions and a node going down.
To inhibit the new Cassandra 2.1 bootstrapping behavior, and make Cassandra 2.0 behavior effective, start the node using the -Dcassandra.consistent.rangemovement=false property:
- Cassandra Package installations: Add the following option to /usr/share/cassandra/cassandra-env.sh file:
```
JVM_OPTS="$JVM_OPTS -Dcassandra.consistent.rangemovement=false
```
- Cassandra Tarball installations: Start Cassandra with this option:
```
$ bin/cassandra -Dcassandra.consistent.rangemovement=false
```
To replace a dead node, you also need to specify the address of the node from which Cassandra streams the data.

For a detailed list of changes, see the Cassandra 2.1 change log.