October 2012 Summaries

The guide describes version 3 of the CQL language (CQL3), which provides a new API to work with Apache Cassandra. Unlike the legacy thrift API, CQL3 offers a thin abstraction layer over Cassandra's internal storage structure, making it simpler and more intuitive for users. This guide explains how to translate thrift to CQL3 and covers the basics of CQL3 implementation. It also discusses when one should use CQL3 and provides examples of translating static, dynamic, and composite column families from thrift to CQL3. Additionally, it touches on the differences between compact and non-compact storage in CQL3 tables and mentions that super columns will be fully available through CQL3 in a future update.

In graph theory and network science, a supernode is a vertex with an unusually high number of incident edges. Supernodes are rare in natural graphs but appear frequently during graph analysis due to their connection to numerous paths. Graph computing can be affected by the presence of supernodes, leading to system performance problems. However, property graphs offer a theoretical and applied solution to this issue. Peer-to-peer networks often experience DoS attacks due to the existence of supernode clients that are quickly inundated with search requests. Twitter handles this discrepancy by maintaining different mechanisms for handling celebrities (supernodes) and ordinary users. Blueprints is a Java interface for graph-based software, which supports vertex queries through indexing incident edges by label or property. This allows efficient retrieval of data from massive graphs, such as those supported by the distributed graph database Titan. Vertex-centric indices can significantly improve query performance in activity stream-type systems and overcome the supernode problem by intelligently leveraging edge information.

Cassandra 1.2 is currently in beta, with final release planned before the end of the year. It introduces support for version 3 of the CQL language, which brings several improvements to the developer experience. The Thrift API remains supported and will continue to be backwards-compatible. Cassandra's storage engine design supports high-performance writes through a log-structured approach, allowing for efficient indexing and distributed counters. Denormalization is encouraged instead of joins, with wide, sparse rows being used to store data in the cell name as well as the value. CQL3 introduces several improvements over CQL2, including better representation of Cassandra's storage engine cells and support for more powerful indexing.

In Cassandra 1.2, atomic batches are introduced to ensure that all updates within a batch are completed successfully or not at all. This feature addresses the issue of partially applied batches in case of coordinator failure. However, atomic batches come with a performance cost of about 30% compared to non-atomic batches. To balance between atomicity and performance, Cassandra also provides UNLOGGED BATCH for scenarios where atomicity is not required. Additionally, COUNTER BATCH is introduced for improved performance when updating multiple counters in the same partition. Atomic batches use a new system table called batchlog to record batches until they are successfully written or hinted. The batchlog is node-local and uses StorageProxy for special handling of replication and failure recovery. Cassandra 1.2beta1, which includes atomic batches, is available for download on the Apache site with a projected final release by the end of the year.

The text discusses how Cassandra handles node failures and its robustness. Prior to version 1.2, a single unavailable disk could make an entire replica unresponsive due to issues with memtables and commitlog append. Traditional workarounds involved using RAID10 volumes, but this approach was becoming less feasible as data volumes increased. The upcoming Cassandra 1.2 release introduces a disk_failure_policy setting with two options: best_effort and stop. These policies allow for sensible handling of disk failure by either stopping the affected node or blacklisting the failed drive, depending on availability/consistency requirements. This improvement allows deploying Cassandra nodes with large disk arrays without the need for RAID10 overhead.