Apache Cassandra入门指南[长期连载]

jieforest

QUERYING/INDEXING

Cassandra provides simple primitives. Its simplicity allows it to scale linearly with high availability and very little performance degradation.   That simplicity allows for extremely fast read and write operations for specific keys, but servicing more sophisticated queries that span keys requires pre-planning.

Using the primitives that Cassandra provides, you can construct indexes that support exactly the query patterns of your application.  Note, however, that queries may not perform well without properly designing your schema.

Secondary Indexes

To satisfy simple query patterns, Cassandra provides a native indexing capability called Secondary Indexes.  A column family may have multiple secondary indexes.  A secondary index is hash-based and uses specific columns to provide a reverse lookup mechanism from a specific column value to the relevant row keys.

jieforest

Under the hood, Cassandra maintains hidden column families that store the index. The strength of Secondary Indexes is allowing queries by value. Secondary indexes are built in the background automatically without blocking reads or writes. To create a Secondary Index using CQL is straight-forward. For example, define a table of data about movie fans, and then create a secondary index of states where they live:

CREATE TABLE fans ( watcherID uuid, favorite_actor text,  address text, zip int,  state text PRIMARY KEY (watcherID)  );

CREATE INDEX watcher_state ON fans (state);

Range Queries

It is important to consider partitioning when designing your schema to support range queries.

jieforest

Range Queries with Order Preservation

Since order is preserved, order preserving partitioners better supports range queries across a range of rows.  Cassandra only needs to retrieve data from the subset of nodes responsible for that range.  For example, if we are querying against a column family keyed by phone number and we want to find all phone numbers between that begin with 215-555, we could create a range query with start key 215-555-0000 and end key 215-555-9999.To service this request with OrderPreservingPartitioning,
it’s possible for Cassandra to compute the two relevant tokens:

token(215-555-0000) and token(215-555-9999).Then satisfying that querying simply means consulting nodes responsible for that token range and retrieving the rows/tokens in that range.

Range Queries with Random Partitioning

The RandomPartitioner provides no guarantees of any kind between keys and tokens.  In fact, ideally row keys are distributed around the token ring evenly.  Thus, the corresponding tokens for a start key and end key are not useful when trying to retrieve the relevant rows from tokens in the ring with the RandomPartitioner.  Consequently, Cassandra must consult all nodes to retrieve the result.  Fortunately, there are well known design patterns to accommodate range queries.  These are described below.

jieforest

Index Patterns

There are a few design patterns to implement indexes.  Each services different query patterns.  The patterns leverage the fact that Cassandra columns are always stored in sorted order and all columns for a single row reside on a single host.

Inverted Indexes

First, let’s consider the inverted index pattern.  In an inverted index, columns in one row become row keys in another.  Consider the following data set, where users IDs are row keys.


Without indexes, searching for users in a specific Zip Code would mean scanning our Users column family row-by-row to find the users in the relevant Zip Code.  Obviously, this does not perform well.

To remedy the situation, we can create a column family that represents the query we want to perform, inverting rows and columns.  This would result in the following column family.

jieforest

Since each row is stored on a single machine, Cassandra can quickly return all user IDs within a single Zip Code by returning all columns within a single row. Cassandra simply goes to a single host based on token(zipcode) and returns the contents of that single row.

jieforest

Wide-row Indexes

When working with time series data, consider storing the complete set of data for each event in the timeline itself by serializing the entire event into a single column value or by using composite column names of the form <timestamp>:<event_field>. Unless the data for each event is very large, this approach scales well with large data sets and provides efficient reads.

Fetch a time slice of events by reading a contiguous portion of a row on one set of replicas. When you track the same event in multiple timelines, denormalizing and storing all of the event data in each of the timelines works well.

jieforest

When you use composite keys in CQL, Cassandra supports wide Cassandra rows using composite column names. In CQL 3, a primary key can have any number (1 or more) of component columns, but there must be at least one column in the column family that is not part of the primary key. The new wide row technique consumes more storage because for every piece of data stored, the column name is stored along with it.

1. CREATE TABLE History.events (
   
2.     event uuid PRIMARY KEY,
   
3.     author varchar,
   
4.     body varchar);
   
5. CREATE TABLE timeline (
   
6.     user varchar,
   
7.     event uuid,
   
8.     author varchar,
   
9.     body varchar,

复制代码

HotTip
Wide-Row indexes can cause hotspots in the cluster.  Since the index is a single row, it is stored on a single node (plus replicas).  If that is a heavily used index, those nodes may be overwhelmed.

jieforest

Composite-Types in Indexes

Using composite keys in indexes, we can create queries along multiple dimensions.  If we combine the previous examples, we could create a single wide-row capable of serving a compound query such as, “How many users within the 18964 Zip Code are older than 21?”

Simply create a composite type containing the Zip Code and the date of birth and use that as the column name in the index.

Denormalization

Finally, it is worth noting that each of the indexing strategies as presented would require two steps to service a query if the request requires the actual column data (e.g., user name).  The first step would retrieve the keys out of the index.  The second step would fetch each relevant column by row key.

We can skip the second step if we denormalize the data. In Cassandra, denormalization is the norm.  If we duplicate the data, the index becomes a true materialized view that is custom tailored to the exact query we need to support.

jieforest

INSERTING/UPDATING/DELETING

Everything in Cassandra is a write, typically referred to as a mutation.  Since Cassandra is effectively a key-value store, operations are simply mutations of a key/value pairs. The column is atomic, but the fundamental unit is a row in the ACID sense. If you have multiple updates to the same key, group the changes into a single update.

Hinted Handoff

Similar to ReadRepair, Hinted Handoff is a background process that ensures data integrity and eventual consistency.  If a replica is down in the cluster and the client requests a consistency level of ANY, a write may still succeed by writing a “hint” to a coordinator node, which will disseminate that data to replicas when they become available.

jieforest

OPERATIONS AND MAINTENANCE

Cassandra provides tools for operations and maintenance.  Some of the maintenance is mandatory because of Cassandra’s eventually consistent architecture.  Other facilities are useful to support alerting and statistics gathering.  Use nodetool to manage Cassandra.

Nodetool Repair

Cassandra keeps record of deleted values for some time to support the eventual consistency of distributed deletes.  These values are called tombstones.  Tombstones are purged after some time (GCGraceSeconds, which defaults to 10 days).  Since tombstones prevent improper data propagation in the cluster, you will want to ensure that you have
consistency before they get purged.

To ensure consistency, run:

1. >$CASSANDRA_HOME/bin/nodetool repair

复制代码