Databases Reference
In-Depth Information
query languages, their design and the ability to be deployed on low-cost cloud com-
puting platforms make it possible for startups, with minimal cash, to provide always-on
databases for their worldwide customers.
Understanding the concept of system availability is critical when you're gathering
high-level system requirements. Since NoSQL systems use distributed computing, they
can be configured to achieve high availability of a specific service at a minimum cost.
To understand the concepts in this chapter, we'll draw on the
CAP
theorem from
chapter 2. We said that when communication channels between partitions are broken,
system designers need to choose the level of availability they'll provide to their cus-
tomers. Organizations often place a higher priority on availability than on consistency.
The phase “A trumps C” implies that keeping orders flowing through a system is more
important than consistent reporting during a temporary network failure to a replica
server. Recall that these decisions are only relevant when there are network failures.
During normal operations, the
CAP
theorem doesn't come into play.
Now that you have a good understanding of what high-availability NoSQL systems
are and why they're good choices, let's find out how to measure availability.
8.2
Measuring availability of NoSQL databases
System availability can be measured in different ways and with different levels of preci-
sion. If you're writing availability requirements or comparing the
SLA
s of multiple sys-
tems, you may need to be specific about these measurements. We'll start with some
broad measures of overall system availability and then dig deeper into more subtle
measurements of system availability.
The most common notation for describing overall system availability is to state
availability in terms of “nines,” which is a count of how many times the number 9
appears in the designed availability. So
three nines
means that a system is predicted to
be up 99.9% of the time, and
five nines
means the system should be up 99.999% of the
time.
Table 8.1 shows some sample calculations of downtime per year based on typical
availability targets.
Stating your uptime requirements isn't an exact science. Some businesses can asso-
ciate a revenue-lost-per-minute to total data service unavailability. There are also gray
areas where a system is so slow that a few customers abandon their shopping carts and
Table 8.1
Sample availability targets and annual downtime
Availability %
Annual downtime
99% (two nines)
3.65 days
99.9% (three nines)
8.76 hours
99.99% (four nines)
52.56 minutes
99.999% (five nines)
5.26 minutes
