A distributed system runs components on multiple networked nodes that coordinate to provide one service. ScyllaDB uses this design to distribute data, improve scalability, and tolerate node failures. section 1.2 section 1.2.1
ScyllaDB’s distributed design works through several connected mechanisms:
- Accept a request through any node, then calculate the row’s owner with a hash ring and forward the request when necessary. section 1.2.1
- Replicate each row across multiple nodes, with the replication factor determining how many copies exist. section 1.2.1
- Tune consistency by choosing how many replicas must acknowledge a query; stronger requirements reduce availability during failures. section 1.2.1
- Expect eventual consistency: replicas may temporarily disagree while the system converges toward a consistent state. section 1.2.1
A replicated write
A client sends a write to any ScyllaDB node. The receiving node determines which nodes own replicas of the row and forwards the request. At consistency level QUORUM in a three-replica cluster, two replicas must acknowledge success, while one replica may fail. section 1.2.1
Table 1.1 Sample of consistency level options, assuming a cluster with three replicas
|
Consistency level
|
Description
|
Number required to succeed
|
Failures tolerated
|
|---|---|---|---|
ALL
|
Requires all replicas to succeed
|
3
|
0
|
QUORUM
|
Requires a majority of replicas to succeed
|
2
|
1
|
ONE
|
Requires a single replica to succeed
|
1
|
2
|
Compare ALL, QUORUM, and ONE to see how acknowledgement requirements change availability and tolerated failures. section 1.2.1
Figure 1.7 The CAP theorem says a database can only provide two of these three properties: consistency, availability, and partition tolerance. ScyllaDB is classified as an AP system.
Use the CAP-theorem figure to place ScyllaDB’s AP classification alongside consistency, availability, and partition tolerance. section 1.2.1
