February 2015 Summaries

The new version of DataStax Node.js Driver for Apache Cassandra introduces improved data type support in JavaScript, including types not available in the Ecmascript standard. It also adds support for ES 6 Map/Set built-in types and introduces support for batches of prepared statements and named parameters for prepared statements. The driver now uses its own BigDecimal representation for Cassandra decimal support and Google Closure Integer for varint, as well as rolling out its own Uuid and TimeUuid classes. These enhancements aim to make working with Cassandra data types easier and more efficient.

DataStax Community 2.1.3 has been released, offering numerous bug fixes and upgrade notes for users transitioning to this version. The release is available for Debian-based and RPM-based systems through package repositories, as well as in tarball and MSI formats for download. Key links include installation guides for Debian and Red Hat systems, and direct downloads for tarball and MSI installers.

The latest release introduces a new object Mapper component that simplifies mapping query results to objects, and several improvements to the Linq component for a more user-friendly interface. The Mapper, inspired by PetaPoco, NPoco, Dapper.NET, and cqlengine, allows users to write queries with CQL while it handles mapping rows returned from Cassandra to their classes. It can be used with short-lived instances as long as the same Session instance is reused. The Mapper provides methods for various operations like Inserts, Updates, Deletes, and more. Linq capabilities have also been improved, allowing users to query their Cassandra cluster using Linq lambda syntax or queries and get results mapped to classes or anonymous classes. There are no breaking changes for Linq in this release, but an upgrade guide is available. The driver now comes as a single strong-named assembly, with the latest version available on NuGet and source code on GitHub.

Designing an efficient data model for Apache Cassandra requires understanding its basic rules and goals. The main objectives are to spread data evenly across nodes and minimize the number of partitions read during queries. Developers coming from a relational background should avoid applying traditional modeling rules to Cassandra, as it is optimized for high write throughput and denormalization. To achieve efficient reads, model your data around specific query patterns rather than relations or objects. Use compound partition keys to balance the two goals when necessary. Consider using time ranges for splitting partitions based on query patterns, and remember that data duplication is acceptable in Cassandra.