March 2012 Summaries

Cassandra is a suitable database for storing time series data such as performance metrics, fleet tracking, sensor data, logs, financial data, and user activity. Two strategies are typically employed when working with time series data: index strategy and materialized view strategy. The latter provides more efficient reads by allowing fetching of a time slice of events from one set of replicas. All event data is serialized as JSON in the column values. To support queries that ask for all events before a given time, it's essential to keep track of when the timeline was first started using metadata rows. In some cases, splitting each time bucket into multiple rows can help spread the write load among more nodes in the cluster. Timelines may require different time bucket sizes based on their event rate or changes over time.

The text discusses how to migrate data from an RDBMS (Relational Database Management System) such as MySQL, Oracle or SQL Server to a NoSQL database like Apache Cassandra using the tool Sqoop. This is made possible by DataStax Enterprise 2.0 which combines Cassandra, Hadoop and Solr into one big data platform. The process involves downloading the JDBC driver for the source RDBMS, placing it in a directory accessible to Sqoop, and then using the dse command to specify the source database details, destination keyspace and column family name, primary key of the column family, Cassandra node IP address, and whether to create a new keyspace. The result is the successful migration of data from RDBMS to Cassandra.

The text discusses token management in a Cassandra cluster, which is crucial for maintaining the balance and performance of the system. It explains that consistent hashing is at the core of Cassandra's peer-to-peer architecture, with each node assigned a token determining its data responsibility. Balancing a live Cassandra cluster involves minimizing the number of token changes and optimizing data transfer distances. Tools like DataStax OpsCenter can automate this process, but understanding the underlying concepts is essential for effective management.

The recent rewrite of code handling schema changes in Cassandra has undergone significant improvements with its second major rewrite, now referred to as a "renaissance". This latest version introduces next-generation schema management that addresses the weaknesses found in previous versions. The new algorithm for schema modification and distribution is more reliable, user-friendly, and allows frequent schema updates without causing disagreement among nodes. It also handles situations where modifications are delayed or applied out of order due to network failures. However, simultaneous 'CREATE COLUMN FAMILY' operations on different nodes remain unsafe until version 1.2.