Databases Reference
In-Depth Information
move on to another site. There are other factors, not as easily measured, which can
lead to losses as well, such as poor reputation and lack of confidence.
Measuring overall system availability is more than generating a single number. To
fairly evaluate NoSQL systems, you need an understanding of the subtleties of avail-
ability measurements.
If a business unit indicates they can't afford to be down more than eight hours in a
calendar year, then you want to build an infrastructure that would provide three-nines
availability. Most land-line telephone switches are designed for five-nines availability,
or no more than five minutes of downtime per year. Today five nines is considered the
gold standard for data services, with few situations warranting greater availability.
Although the use of counted nines is a common way to express system availability,
it's usually not detailed enough to understand business impact. An outage for 30 sec-
onds may seem to users like a slow day on the web. Some systems may show partial out-
age but have other functions that can step in to take their place, making the system
only appear to work slowly. The end result is that no simple metric can be used to
measure overall system availability. In practice, most systems look at the percentage of
service requests that go beyond a specific threshold.
As a result, the term
service level agreement
or
SLA
is used to describe the detailed
availability targets for any data service. An
SLA
is a written agreement between a ser-
vice provider and a customer who uses the service. The
SLA
doesn't concern itself with
how the data service is provided. It defines what services will be provided and the avail-
ability and response time goals for the service. Some items to consider when creating
an
SLA
are
What are the general service availability goals of the service in terms of percent-
age uptime over a one-year period?
What are the typical average response times for the service under normal oper-
ations? Typically these are specified in milliseconds between service request and
response.
What is the peak volume of requests that the service is designed to handle? This
is typically specified in requests per second.
Are there any cyclical variations in request volumes? For example, do you
expect to see peaks at specific times of day, days of the week or month, or times
of the year like holiday shopping or sporting events?
How will the system be monitored and service availability reported?
What is the shape of the service-call response distribution curve? Keeping track
of the average response time may not be useful. Organizations focus on the
slowest 5% of service calls.
What procedures should be followed during a service interruption?
NoSQL system configuration may be dependent on some of the exceptions to the
general rules. The key focus should not be a single availability metric.
