What’s New in Cassandra 2.1: Better Implementation of Counters

Apache Cassandra 2.1 introduces a new distributed counters implementation that is safer, simpler, and often faster than previous versions. The crucial difference is that instead of logging counter deltas directly to the commit log, Cassandra now reads the current value for every counter update and applies the delta. This results in more accurate values and more consistent performance. However, increased latency may be experienced for RF=1/CL.ONE/replicate_on_write=false counter tables. The new implementation also creates fewer objects for the JVM to garbage-collect, reducing pathological behavior under heavy load. Counters are split into fragments called 'shards', and a counter's value is calculated as the sum of all shards' values in its replica set. In Cassandra 2.1, local shards are eliminated, and a lock is acquired for each counter being updated to read the current value before writing the incremented value. This simplifies almost every counters aspect and reduces garbage collection activity. A new form of cache called counter cache is introduced in Cassandra 2.1 to keep hot counter values performant, with configurable size and save period in cassandra.yaml. In Cassandra 3.0, the legacy local/remote shards will be removed entirely, eliminating the need for the counter cache.