Databases Reference
In-Depth Information
need to scale, DynamoDB has the headroom for quick growth. DynamoDB offers scal-
able transform Elastic MapReduce, which allows you to move large amounts of data
into and out of DynamoDB if you need efficient and scalable extract, transform, and
load (
ETL
) processes.
Now that we've shown you how NoSQL systems use various strategies to create
high-availability database services, let's look at two NoSQL products with strong repu-
tations for high availability.
8.4
Case study: using Apache Cassandra
as a high-availability column family store
This case study will look at Apache Cassandra, a NoSQL column-family store with a
strong reputation for scalability and high availability, even under intense write loads.
Cassandra was an early adopter of a pure peer-to-peer distribution model. All nodes in
a Cassandra cluster have identical functionality, and clients can write to any node in
the cluster at any time. Because Cassandra doesn't have any single master node,
there's no single point of failure and you don't have to set up and test a failover node.
Apache Cassandra is an interesting combination of NoSQL technologies. It's some-
times described as a Bigtable data model with a Dynamo-inspired implementation.
In addition to its robust peer-to-peer model, Cassandra has a strong focus on mak-
ing it easy to set up and configure both write and read consistency levels. Table 8.2
shows the various write consistency-level settings that you can use once you've config-
ured your replication level.
Table 8.2 The codes used to specify consistency levels in Cassandra tables on writes. Each table in
Cassandra is configured to meet the consistency levels you need when the table is created. You can
change the consistency level at any time and Cassandra will automatically reconfigure to the new
settings. There are similar codes for read levels
Level
Write guarantee
ZERO (weak consistency)
No write confirmation is done. No consistency guarantees. If the
server crashes, the write may never actually happen.
ANY (weak consistency)
A write confirmation from any single node, including a special “hinted
hand-off” node, will be sufficient for the write to be acknowledged.
ONE (weak consistency)
A write confirmation from any single node will be sufficient for the
write to be acknowledged.
TWO
Ensure that the write has been written to at least two replicas before
responding to the client.
THREE
Ensure that the write has been written to at least three replicas
before responding to the client.
QUORUM (strong consistency)
N
/2 + 1 replicas where
N
is the replication factor.
LOCAL_QUORUM
Ensure that the write has been written to <ReplicationFactor> / 2 + 1
nodes, within the local data center (requires
NetworkTopologyStrategy
).
