Databases Reference
In-Depth Information
You'll see how NoSQL databases can be configured to handle lots of data and keep
data services running without downtime. We'll begin by defining high-availability data-
base systems and then look at ways to measure and predict system availability. We'll
review techniques that NoSQL systems use to create high-availability systems even
when subcomponents fail. Finally, we'll look at three real-world NoSQL products that
are associated with high-availability service.
8.1
What is a high-availability NoSQL database?
High-availability NoSQL databases are systems designed to run without interruption
of service. Many web-based businesses require data services that are available without
interruption. For example, databases that support online purchasing need to be avail-
able 24 hours a day, 7 days a week, 365 days a year. Some requirements take this a step
further, specifying that the database service must be “always on.” This means you can't
take the database down for scheduled maintenance or to perform software upgrades.
Why must they be always on? Companies demanding an always-on environment
can document a measurable loss in income for every minute their service isn't avail-
able. Let's say your database supports a global e-commerce site; being down for even a
few minutes could wipe out a customer's shopping cart. Or what if your system stops
responding during prime-time shopping hours in Germany? Interruptions like these
can drive shoppers to your competitor's site and lower customer confidence.
From a software development perspective, always-on databases are a new require-
ment. Before the web, databases were designed to support “bankers' hours” such as 9
a.m. to 5 p.m., Monday through Friday in a single time zone. During off hours, these
systems might be scheduled for downtime to perform backups, run software updates,
run reports, or export daily transactions to data warehouse systems. But bankers'
hours are no longer appropriate for web-based businesses with customers around the
world.
A web storefront is a good example of a situation that needs a high-availability
database that supports both reads and writes. Read-mostly systems optimized for big
data analysis are relatively simple to configure for high availability using data replica-
tion. Our focus here is on high availability for large-volume read/write applications
that run on distributed systems.
Always-on database systems aren't new. Companies like Tandem Computers' Non-
Stop system have provided commercial high-availability database systems for
ATM
net-
works, telephone switches, and stock exchanges since the 1970s. These systems use
symmetrical, peer-to-peer, shared-nothing processors that send messages between pro-
cessors about overall system health. They use redundant storage and high-speed fail-
over software to provide continuous database services. The biggest drawbacks to these
systems are that they're proprietary, difficult to set up and configure, and expensive
on a cost-per-transaction basis.
Distributed NoSQL systems can lower the per-transaction cost of systems that need
to be both scalable and always-on. Although most NoSQL systems use nonstandard
