Building a NoSQL-Based Web App to Collect Crowd-Sourced Data - Data Just Right: Introduction to Large-Scale Data and Analytics - page 38

# Retrieve all keys and values of the hash "employees:1"
> HGETALL employees:1
1) "name"
2) "Michael"
3) "city"
4) "San Francisco"
5) "role"
6) "Author"
The contents of computer memory do not persist when the power shuts off. Stor-
ing persistent data is the role of the disk. Redis is an “in-memory” data store, so what
happens when someone trips over a power cord and your server turns off ? Does the
entire database get erased? Well, not really: Redis augments the performance of the
in-memory system by providing the ability to persist data to disk. When data volumes
are enormous, we must consider various trade-offs. For example, do we need to have
complete consistency at all times? Is it reasonable for our application to potentially lose
the last minute of data if the power suddenly goes out? There are many applications
that don't really require persistence at all, and for these, it's also possible to turn off
Redis persistence completely.
Sharding across Many Redis Instances
Building applications that serve many users requires database administrators to think
about what to do in situations in which the amount of data hurling toward your sys-
tem is constantly growing. This characteristic, known as scalability , is a key goal of
high-throughput databases used in Web scale applications.
The simple application that we've built using Redis is able to collect lots of data
very quickly. In fact, it's become so useful that your boss has asked you to build a sys-
tem that can handle 50 times as much data. In the spirit of picking the right tool for
the job, you might not need to do anything! Redis write performance is very good,
and additional computer resources may not be necessary.
At some point, however, you may need to use multiple machines, whether physical
or virtual, to handle the traffic and data of your application. Redis is limited by the
amount of available memory in a machine, and there is only so much one can add to
a single server before it gets to be prohibitively expensive. Also important is replica-
tion of the database for crucial applications. If the single machine that is your primary
interface with the world goes down for any reason, you will need another machine
ready to pick up the slack. It's not important that these two machines are completely in
sync—as we've learned, making sure that the data between each is exactly consistent
at any given time is not always necessary—but for real life applications, durability is a
concern.
What we really want is for our distributed key-value store to automatically be
able to handle the addition of new machines to our cluster. Ideally, our database will