Tải bản đầy đủ
4 Case study: using Apache Cassandra as a high-availability column family store

4 Case study: using Apache Cassandra as a high-availability column family store

Tải bản đầy đủ

Case study: using Apache Cassandra as a high-availability column family store

185

Table 8.2 (continued)
Level

Write guarantee

EACH_QUORUM

Ensure that the write has been written to / 2 + 1
nodes in each data center (requires NetworkTopologyStrategy).

ALL (strong consistency)

All replicas must confirm that the data was written to disk.

Next, you consider what to do if one of the nodes is unavailable during a read transaction. How can you specify the number of nodes to check before you return a new
value? Checking only one node will return a value quickly, but it may be out of date.
Checking multiple nodes may take a few milliseconds longer, but will guarantee you
get the latest version in the cluster. The answer is to allow the client reader to specify
a consistency level code similar to the write codes discussed here. Cassandra clients
can select from codes of ONE, TWO, THREE, QUORUM, LOCAL_QUORUM, EACH
_QUORUM, and ALL when doing reads. You can even use the EACH_QUORUM code to
check multiple data centers around the world before the client returns a value.
As you’ll see next, Cassandra uses specific configuration terms that you should
understand before you set up and configure your cluster.

8.4.1

Configuring data to node mappings with Cassandra
In our discussion of consistent hashing, we introduced the concept of using a hash to
evenly distribute data around a cluster. Cassandra uses this same concept of creating a
hash to evenly distribute their data. Before we dive into how Cassandra does this, let’s
take a look at some key terms and definitions found in the Cassandra system.
ROWKEY

A rowkey is a row identifier that’s hashed and used to place the data item on one or
more nodes. The rowkey is the only structure used to place data onto a node. No column values are used to place data on nodes. Designing your rowkey structure is a critical step to making sure similar items are clustered together for fast access.
PARTITIONER

A partitioner is the strategy that determines how to assign a row to a node based on its
key. The default setting is to select a random node. Cassandra uses an MD5 hash of the
key to generate a consistent hash. This has the effect of randomly distributing rows
evenly over all the nodes. The other option is to use the actual bytes in a rowkey (not a
hash of the key) to place the row on a specific node.
KEYSPACE

A keyspace is the data structure that determines how a key is replicated over multiple
nodes. By default, replication might be set to 3 for any data that needs a high degree
of availability.

186

CHAPTER 8

Building high-availability solutions with NoSQL

A1 D2 C3

A

B

D1

B1

C2

A2

B3

D3
D

C

C1 B2 A3

Figure 8.5 A sample of how replication works on a
Cassandra keyspace using the SimpleStrategy
configuration. Items A1, B1, C1, and D1 are written
to a four-node cluster with a replication factor of 3.
Each item is stored on three distinct nodes. After
writing to an initial node, Cassandra “walks around
the ring” in a clockwise direction until it stores the
item on two additional nodes.

An example of a Cassandra keyspace is usually drawn as a ring, as illustrated in
figure 8.5.
Cassandra allows you to fine-tune replication based on the properties of keyspace.
When you add any row to a Cassandra system, you must associate a keyspace with that
row. Each keyspace allows you to set and change the replication factor of that row. An
example of a keyspace declaration is shown in figure 8.6.
Using this strategy will allow you to evenly distribute the rows over all the nodes in
the cluster, eliminating bottlenecks. Although you can use specific bits in your key,
this practice is strongly discouraged, as it leads to hotspots in your cluster and can be
administratively complex. The main disadvantage with this approach is that if you
change your partitioning algorithm, you have to save and restore your entire dataset.
When you have multiple racks or multiple data centers, the algorithm might need
to be modified to ensure data is written to multiple racks or even to multiple data centers before the write acknowledgement is returned. If you change the placementstrategy value from SimpleStrategy to NetworkTopologyStrategy, Cassandra will walk
around the ring until it finds a node that’s on a different rack or a different data center.
Because Cassandra has a full peer-to-peer deployment model, it’s seen as a good fit
for organizations that want both scalability and availability in a column family system.
In our next case study, you’ll see how Couchbase 2.0 uses a peer-to-peer model with a
JSON document store.
For a single location site, use “SimpleStrategy.”
If you have multiple sites, use “NetworkTopologyStrategy.”
CREATEKEYSPACE myKeySpace
with placement_strategy='org.apache.cassandra.locator.SimpleStrategy'
and strategy_options={replication_factor:3};

We set a replication factor of 3 so that each
item will be stored on three separate nodes in the cluster.

Figure 8.6 A sample of how replication is configured within Cassandra. Replication is
a property of keys that indicates the type of network you’re on and the replication for
each key.

Case study: using Couchbase as a high-availability document store

8.5

187

Case study: using Couchbase
as a high-availability document store
Couchbase 2.0 is a JSON document store that uses many of the same replication patterns found in other NoSQL databases.

Couchbase vs. CouchDB
Couchbase technology shouldn’t be confused with Apache CouchDB. Though both
are open source technologies, they’re separate open source projects that have significantly different capabilities, and they support different application developer
needs and use cases. Under the covers, Couchbase has more in common with the
original Memcached project than the original CouchDB project. Couchbase and
CouchDB share the same way of generating views of JSON documents, but their
implementations are different.

Like Cassandra, Couchbase uses a peer-to-peer distribution model, where all nodes
provide the same services, thus eliminating the possibility of a single point of failure.
Unlike Cassandra, Couchbase uses a document store rather than a column family
store, which allows you to query based on a document’s content. Additionally, Couchbase uses the keyspace concept that associates key ranges with individual nodes.
Figure 8.7 shows the components in a multidata-center Couchbase server.
Couchbase stores document collections in containers called buckets, which are configured and administered much like folders in a filesystem. There are two types of buckets:
a memcached bucket (which is volatile and resides in RAM), and a Couchbase bucket,
Data center: US West

Data center: US East

App server

App server

App server

App server

Couchbase client

Couchbase client

Couchbase client

Couchbase client

Cluster map

Cluster map

Cluster map

Cluster map

1
Active
doc

Active

2

Replicas
doc

doc

doc1

doc

Data server 1

Active
doc

XDCR

Replicas
doc1

doc

Active
doc

Replicas
doc

Data server 2

3

doc1

doc

doc

Replicas
doc

Data server 3

doc

doc

Data server 4

Figure 8.7 High-availability documents in Couchbase. Couchbase buckets are logical
collections of documents that are configured for high availability. Couchbase clients use
cluster maps to find the physical node where the active version of a document is stored.
The cluster map directs the client to a file on the active node (1). If Data server 1 is
unavailable, the cluster map will make a replica of doc1 on Data server 2 the active version
(2). If the entire US West data center goes down, the client will use cross data center
replication (XDCR) and make a copy on Data server 3 active (3) from the US East region.

188

CHAPTER 8

Building high-availability solutions with NoSQL

which is backed up by disk and configured with replication. A Couchbase JSON document is written to one or more disks. For our discussions on high-availability systems,
we’ll focus on Couchbase buckets.
Internally, Couchbase uses a concept called a vBucket (virtual bucket) that’s associated with one or more portions of a hash-partitioned keyspace. Couchbase keyspaces
are similar to those found in Cassandra, but Couchbase keyspace management is done
transparently when items are stored. Note that a vBucket isn’t a single range in a keyspace; it may contain many noncontiguous ranges in keyspaces. Thankfully, users
don’t need to worry about managing keyspaces or how vBuckets work. Couchbase clients simply work with buckets and let Couchbase worry about what node will be used
to find the data in a bucket. Separating buckets from vBuckets is one of the primary
ways that Couchbase achieves horizontal scalability.
Using information in the cluster map, Couchbase stores data on a primary node as
well as a replica node. If any node in a Couchbase cluster fails, the node will be
marked with a failover status and the cluster maps will all be updated. All data requests
to the node will automatically be redirected to replica nodes.
After a node fails and replicas have been promoted, users will typically initiate a
rebalance operation to add new nodes to the cluster to restore the full capacity of the
cluster. Rebalancing effectively changes the mapping of vBuckets to nodes. During a
rebalance operation, vBuckets are evenly redistributed between nodes in the cluster
to minimize data movement. Once a vBucket has been re-created on the new node,
it’ll be automatically disabled on the original node and enabled on the new node.
These functions all happen without any interruption of services.
Couchbase has features to allow a Couchbase cluster to run without interruption
even if an entire data center fails. For systems that span multiple data centers, Couchbase uses cross data center replication (XDCR), which allows data to automatically be replicated between remote data centers and still be active in both data centers. If one data
center becomes unavailable, the other data center can pick up the load to provide
continuous service.
One of the greatest strengths of Couchbase is the built-in, high-precision monitoring tools. Figure 8.8 shows a sample of these monitoring tools.
These fine-grained monitoring tools allow you to quickly locate bottlenecks in
Couchbase and rebalance memory and server resources based on your loads. These
tools eliminate the need to purchase third-party memory monitoring tools or configure external monitoring frameworks. Although it takes some training to understand
how to use these monitoring tools, they’re the first line of defense when keeping your
Couchbase clusters healthy.
Couchbase also has features that allow software to be upgraded without an interruption in service. This process involves replication of data to a new node that has a
new version of software and then cutting over to that new node. These features allow
you to provide a 24/365 service level to your users without downtime.