April 2012 Summaries

Cassandra has built-in key and row caches since versions 0.5 and 0.6, respectively. Key cache saves primary key indexes for a table, while the row cache is similar to memcached, pulling entire rows into memory for faster access. Typically, one of these caches is enabled per table, with exceptions for infrequently read archive tables. Cache sizes do not need to be specified per table and are managed automatically based on size and access frequency. The main settings are key_cache_size_in_mb and row_cache_size_in_mb in cassandra.yaml. Row cache hit rate should ideally be at least 90%. Limitations include the inability to cache compound-key rows, which is being addressed in Cassandra 1.2.

Cassandra 1.1 introduces significant changes in the CQL modeling and query language, necessitating a new version of the CQL language specification (CQL 3). The primary focus is on encouraging composite keys for simpler denormalization. CQL 3 allows multi-column primary keys, which are translated into wide Cassandra rows using composite column names. This change requires understanding that storage-engine rows differ from CQL rows. CQL 2 is still supported in Cassandra 1.1 for backward compatibility, but new applications should use CQL 3. The major additions to CQL include the ability to create tables with compound primary keys and perform ORDER BY operations on SELECT queries. However, direct access to column ranges via storage engine is no longer supported in CQL 3.

A multitenant software system is designed to support multiple customers within a single application instance using shared data sets with proper separation. TinkerPop's Blueprints provides an interface for building multitenant, graph-based applications supported by various graph databases. PartitionGraph separates the underlying graph into different partitions/buckets and enables multitenancy, where a partition serves as the location for a single tenant's data. This design allows for "cross-fertilization" of data through inter-partition linking. The example demonstrates how PartitionGraph can be used to separate customer data in an Electronic Health Records (EHR) system and introduces global data that can be shared amongst all customers, enabling complex graph queries and analyses across multiple partitions.