February 2016 Summaries

The Apache Cassandra project has recently begun exploring Byteman, an open-source tool that enables additional Java code to be injected into a running JVM. This tool can increase observability and facilitate fault injection testing in unit tests by injecting code at specific points in the existing code. Byteman is useful for verifying behaviors without easily observable side effects and simulating pathological conditions, such as disk filling up or network partitioning. The tool has been integrated with JUnit test runner to support integration with test fixtures through annotations. In a recent Cassandra unit test, Byteman was used to assert that the HintsBufferPool provides backpressure to its callers by drawing write buffers from a BlockingQueue.

The article discusses primary key selection and usage in Apache Cassandra, a distributed database system. It explains that unlike relational databases, Cassandra does not support JOIN operations, so data models must be designed with specific queries and access patterns in mind. The basic primary key is a single parameter identifying a record, while complex primary keys consist of multiple clustering columns that determine the order of data within partitions. The CLUSTERING ORDER BY clause allows for default sorting of clustering columns at table creation time, enabling efficient queries on time series data models. Understanding primary key components is crucial for effective Cassandra data modeling and can help prevent common mistakes like using only one partition key.

Apache Cassandra's functional test suite, cassandra-dtest, is an open-source Python project on GitHub where much of the Apache Cassandra test automation effort takes place. It consists of end-to-end, black box tests that run against Cassandra clusters via CCM (Cassandra Cluster Manager). The process of adding a new dtest involves choosing the appropriate module and/or test suite, creating a new test method with "test" in its name, adding a docstring describing the test's purpose and how it verifies it, launching a C* cluster using CCM, connecting to the cluster using one of the methods from dtest.py, performing testing logic using Python driver or ccmlib API, asserting C*'s correctness with assertions.py and built-in assertions, ensuring code compliance with PEP8, and finally opening a pull request against the riptano/cassandra-dtest repository for review and merging.

Cassandra 3.0 introduces Materialized Views, a feature designed for efficient querying of denormalized data on high cardinality columns. Unlike secondary indexes that can become inefficient due to fan-out across all nodes, materialized views allow direct lookups and hold other denormalized data from the base table. However, it's crucial to understand the design and tradeoffs associated with this feature. Cassandra offers highly available, eventually consistent materialized views, but data safety depends on factors like replication factor and consistency level used for writes. Manual maintenance of Materialized Views can lead to inconsistencies between views, so understanding the internal design is essential. The Materialized Views feature aims to address complexities surrounding manual denormalization while offering its own set of guarantees and tradeoffs. Repairs work differently depending on whether the base or view is being repaired, ensuring consistency across replicas.