ScyllaDB is the NoSQL Database Built for High Availability
Our customers are able to achieve monstrous scale and save up to 70% of their cost.
Compare Pricing Now When ScyllaDB starts up, nodes use the gossip protocol to discover peer nodes to establish the cluster. There are no leaders nor followers, the underlying architecture is leaderless. No primaries and no replicas. In fact, with ScyllaDB, we have even removed the concept of seed nodes found in other gossip implementations. It’s completely peer-to-peer. This gossip mechanism is also used in case of topology changes, such as adding or removing a node, or in case of an unexpected node outage, providing strong resiliency to a ScyllaDB cluster.
ScyllaDB allows users to set a replication factor (RF), meaning that multiple copies of the same data can be stored on multiple nodes across the cluster. In this way, even if a node is lost, the data still resides somewhere in the cluster.
For many high availability use cases, setting a replication factor of three (3) is sufficient. In such cases, even if two out of the three copies of the data are unavailable, the data will reside somewhere live in the cluster.
With a properly set replication factor, zero downtime is achievable. Users can determine their own replication factor, based on their use case. There are times when a replication factor of two may be sufficient, and times when a replication factor of five may be called for. ScyllaDB automatically takes care of replicating the data in the background. You just set the replication factor, and the cluster handles the rest.
The CAP Theorem is based on the hypothesis that systems could choose to offer consistency, availability or partition tolerance, and that database designers would have to choose two of those three characteristics. Any distributed database requires partition tolerance — the ability to continue operating even if part of the system becomes off-line due to network or server failure. Thus, two prevalent modes of databases are common today:
which favor consistency and partition tolerance
which favor availability and partition tolerance
ScyllaDB is the latter, focusing on high availability. Learn more about ScyllaDB’s Fault Tolerant architecture
Consistency in ScyllaDB is tunable — users can allow their transactions to have different degrees of consistency. Here are a few examples:
means successfully writing an update to any node is sufficient (the system will eventually replicate it to other nodes)
means a majority of replicas (based on the replication factor) need to acknowledge an update
means all replicas must acknowledge an update
Nodes can fail. Racks can fail. Even whole datacenters. Yet your applications cannot. They remain always-on. That’s the goal for high availability database systems. The way ScyllaDB achieves zero downtime is through a few mechanisms, including rack and datacenter awareness, as well as multi-datacenter replication.
A ScyllaDB cluster can span datacenters scattered across any geographic space. Data in ScyllaDB is automatically synchronized across datacenters in an eventually consistent manner without requiring users to create any sort of streaming or batch processing to ensure the clusters communicate changes.
ScyllaDB is topology aware. It uses snitches to know which rack and which datacenter a node belongs to. These allow you to spread your data across nodes in different racks in a datacenter, or across different datacenters, availability zones and regions in public clouds. That way, if a rack goes out, or even a whole datacenter, your data is still available.
ScyllaDB clusters that span different datacenters can employ the NetworkTopologyStrategy and set different replication factors for each datacenter. For instance, the primary datacenter may have a RF of 3, and a separate satellite datacenter may be set to an RF of 2. This allows you to determine the resiliency of your data per site.
ScyllaDB is designed to operate even in the case of temporary node unavailability (when it eventually rejoins the cluster) or a node failure (when it has to be replaced). But when those situations occur, the system has to battle against entropy and bring the cluster back to full operation. The following processes and features are designed to mitigate that
| Hinted Handoffs | In the case of a temporary node outage (less than three hours), ScyllaDB uses a feature called Hinted Handoffs to keep track of what transactions occurred while the node was unavailable. When the node returns to service, the Hinted Handoffs allow the node to catch up on what transpired while it was offline. (You can think of it like a classmate who takes notes for you in case you miss a class or two.) |
| Row-level Repair | In case you had a more serious loss of availability of a node, ScyllaDB has a background repair process that allows you to get a new node up to speed. This process can be managed with a command-line interface, called nodetool repair, or from within ScyllaDB Manager, which can also restore data from backups. |
Apache® and Apache Cassandra® are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Amazon DynamoDB® and Dynamo Accelerator® are trademarks of Amazon.com, Inc. No endorsements by The Apache Software Foundation or Amazon.com, Inc. are implied by the use of these marks.
