December 2014 Summaries

The DataStax C/C++ driver is a new member of the DataStax drivers family, with its first release candidate recently launched. Its main focus has been on feature parity with other drivers and finalizing the API. This post provides introductory documentation for using the driver, while more in-depth documentation can be found in the header file and examples provided with the driver. The driver's API is designed to prevent application blocking during operations like connecting to a cluster or running a query. Queries are constructed using CassStatement objects, which can be regular or prepared statements. Prepared statements cache queries on the Cassandra server for improved performance. Results from queries can be retrieved and iterated over using appropriate iterator objects. Large result sets can be divided into multiple pages automatically using the driver's paging API. Batches can be used to group multiple mutations together into a single statement, with different types of batches available depending on the use case.

The DataStax C/C++ driver for Apache Cassandra and DataStax Enterprise has released its first release candidate, including bug fixes and improvements in both the core and API. Changes include decoupling session lifecycle from connect and close operations, making logging global, updating UUID API to use explicit initialization, and setting DC-aware policy as the default load balancing policy. These changes may require minor updates to existing code but are designed to improve the driver's stability and functionality. Future major versions might introduce further API changes, but these will be minimized and thoroughly documented.

The text discusses Cassandra's ALLOW FILTERING feature and how it affects query performance. It explains that Cassandra requires ALLOW FILTERING for some CQL queries to prevent inefficient resource usage, as the system might need to retrieve all rows from a table before filtering out irrelevant data. The text also highlights the importance of understanding data distribution and making informed decisions when using ALLOW FILTERING or adding indexes to improve query performance. It emphasizes that users should consider their specific use case and choose the appropriate strategy, such as changing the data model, adding an index, or using another table.

Cassandra on Windows has been a topic of interest for years. Although it is now endorsed and supported for development purposes only, there are known issues that prevent its recommendation for production environments. The main issue lies in file deletion, which is critical for database operations. However, with the introduction of JDK7's new I/O library, Cassandra 3.0 aims to resolve these errors by allowing file deletion while other processes have handles open to them. Memory-mapped file I/O on Windows remains a challenge due to technical limitations, but disabling it in the upcoming 2.1.3 release should improve performance. Cassandra's launch scripts for Windows have been rewritten and improved, making the development and usage environment smoother. The target for official Windows support is Cassandra-3.0, with a focus on replicating page cache optimizations currently available in Linux only.

Consensus in distributed systems is crucial for maintaining agreement among peers on the value of shared data. The Paxos protocol is used by Cassandra since version 2.0 to support consensus. Lease tables can be created in Cassandra to track owners of things, providing a leader election algorithm and a mental model that developers can easily understand. A lease has a name, optional value, owner, and a default TTL for fail-safe purposes. Clients acquire leases by issuing statements and periodically renew them using CQL. When the client no longer needs the lease, it can be explicitly dropped with another CQL statement. This approach allows for leader election of things, distributed locks, and distributed sequences to be built on top of Cassandra.