Database Reference
In-Depth Information
Peer-to-Peer
In traditional databases that can be deployed on multiple machines (such as MySQL), and even
in newer models such as Google's Bigtable, some nodes are designated masters and some slaves.
They have different roles in the overall cluster: the master acts as the authoritative source for
data, and slaves synchronize their data to the master. Any changes written to the master are
passed on to slaves. This model is optimized for reading data, as it allows data to be read from
any slave. But the replication is one-way, from master to slave. This has an important ramific-
ation: all writes must be sent to the master, which means that it is a potential single point of
failure. In a master/slave setup, the master node can have far-reaching effects if it goes offline.
By contrast, Cassandra has a peer-to-peer distribution model, such that any given node is struc-
turally identical to any other node—that is, there is no “master” node that acts differently than
a “slave” node. The aim of Cassandra's design is overall system availability and ease of scaling.
The peer-to-peer design can improve general database availability, because while taking any giv-
en Cassandra node offline may have a potential impact on overall throughput, it is a graceful
degradation that does not interrupt service. Assuming that you are using a reasonable replication
strategy, the data on a failed node will still be available for reads and writes.
This design also makes it easier to scale Cassandra by adding new nodes. Because the behavior
of each node is identical, in order to add a new server, you simply need to add it to the cluster.
The new node will not immediately accept requests so that it has time to learn the topology of
the ring and accept data that it may also be responsible for. After it does this, it can join the ring
as a full member and begin accepting requests. This is largely automatic and requires minimal
configuration. For this reason, the P2P design makes both scaling up and scaling down an easier
task than in master/slave replication.
Gossip and Failure Detection
To support decentralization and partition tolerance, Cassandra uses a gossip protocol for intra-
ring communication so that each node can have state information about other nodes. The gos-
siper runs every second on a timer. Hinted handoff is triggered by gossip, when a node notices
that a node it has hints for has just come back online. Anti-entropy, on the other hand, is a manu-
al process; it is not triggered by gossip.
Gossip protocols (sometimes called “epidemic protocols”) generally assume a faulty network, are
commonly employed in very large, decentralized network systems, and are often used as an auto-
matic mechanism for replication in distributed databases. They take their name from the concept
of human gossip, a form of communication in which peers can choose with whom they want to
exchange information.
