September 2013 Summaries

The author discusses their transition from a background in software development to a role as a test engineer at DataStax, focusing on testing strategies for Apache Cassandra. They highlight various tools such as hdparm, dd, iozone, bonnie++, and iostat for assessing disk performance and troubleshooting potential I/O bottlenecks, as well as tools like jconsole, jmxterm, and Eclipse Memory Analyzer Tool for managing and analyzing Java heap memory. The text emphasizes the importance of visualizing data for effective monitoring and bug detection, recommending the use of D3.js for creating insightful visualizations of performance metrics. By illustrating the benefits of graphical representations over raw data analysis, the text underscores the value of collaboration and sharing visual data to gain deeper insights and resolve issues more efficiently.

Erin, a QA engineer, shares her experience working with the OpsCenter team and highlights common problems encountered by users. She provides solutions for issues such as difficulty loading OpsCenter in a browser or connecting to a cluster. For those using the enterprise edition, she explains how to manage permissions and backups. Additionally, Erin offers a list of useful resources and documentation, including official DataStax documentation, getting started with Apache Cassandra, and troubleshooting tips for OpsCenter 3.2.

CQL (Cassandra Query Language) was tagged production ready in Cassandra 1.2 and brought along the CQL Native Protocol as a replacement for Thrift. Despite improvements, limitations remained when using batch prepared statements, blobs in non-prepared statements, or paging over large results. Cassandra 2.0 introduced enhancements to address these issues. It allows developers to batch Prepared Statements and supports parameterized statements that accept question mark placeholders and parameters like prepared statements. Automatic paging was also introduced in Cassandra 2.0, allowing developers to iterate through an entire ResultSet without having to manually page over results. This feature provides a transparent failover mechanism between page responses using a paging state returned with each result page.

Streaming in Apache Cassandra is a crucial component responsible for data exchange among nodes within a cluster. It plays a significant role during operations like bootstrapping, repairing, and bulk loading of data. However, tracing the cause of slow or stuck streaming has been challenging. To address this issue, the streaming protocol and API were redesigned in C* version 2.0 to improve reliability, traceability, and speed. The new Streaming 2.0 design associates all streaming sessions related to an operation (e.g., bulk load, move, bootstrap) with a single Stream Plan, making it easier to track the ongoing streams in one place using nodetool netstats. Each Stream Plan has its unique Stream Plan ID, which can be used for log tracing and monitoring through JMX interface or by building custom streaming monitoring applications. Streaming 2.0 also introduced pipelining on the same connection, eliminating the need for senders to wait for ACKs before transferring subsequent files. Although there is room for further performance improvements, this redesign allows for future enhancements like supporting streaming of older version SSTable files during C* upgrades. The Streaming API can be found under the package org.apache.cassandra.streaming, and more information about its design is available on the Wiki.

The text highlights the key features of version 2.0, which include lightweight transactions, CQL enhancements, and triggers. Additionally, it mentions numerous internal optimizations and improvements that have been incorporated into this release.

Amazon's Dynamo paper introduced the use of vector clocks for conflict resolution in key/value databases like Voldemort and Riak. However, systems such as Cassandra and DynamoDB avoid using vector clocks in favor of finer-grained updates. The main problem with a key/value database is that it can lead to data loss when using last-write-wins conflict resolution. Vector clocks solve this issue by allowing the database to push conflict resolution back to the client, but they have limitations. Cassandra addresses this problem by breaking up documents into columns that can be updated independently, offering improved performance and simpler application design.