Database Reference
In-Depth Information
of weather sensors around the world. This design pattern is also common in the
online gaming world. Many social multiplayer games offer the ability for a game to
be replayed, with statistics about the gaming environment broadcast publicly. In this
case, a continuous stream of data might be streamed into the application backend from
thousands or even millions of players at all times.
In the previous example, f lexibility in querying is less important than the ability
to collect data very fast. For applications like this, a key-value store is a good choice,
as the simplicity of this model makes database writes as fast as possible. The key-
value design also lends itself well to distributed applications, in which the choice
of which part of the database to shard is not particularly crucial. One database that
meets many of these criteria is the open-source key-value store Redis. The Web site
DB-Engines.com,
3
which provides a ranking of the most popular database software
using metrics such as search engine result sizes and the amount of technical questions
posted on forums such as StackOverflow.com, claims that Redis is also the most
popular key-value data store.
Redis has many interesting features that make it a good choice for applications that
require very fast read and write performance. It is primarily an “in-memory” data-
base, meaning that it stores the entire database using your server's available memory.
This might seem like a big limitation, as you will need to provide adequate hardware
(whether physical or virtual) for your application, and once the power goes out, your
data will presumably be lost. Not so fast! Redis can also provide the “D” of ACID
compliance—durability—as it provides configurable options for persisting the in-
memory data to disk. In other words, Redis provides both a volatile, but performant,
layer for reading and writing data and a persistent on-disk cache for durability.
Like everything in the data world, great advantage must come at the expense of
something else, and in this case, that something else is consistency. For example, if the
in-memory database is set to persist data to disk every ten seconds, and the memory
fails in that time (due to power failure), data will be lost. A high-volume Web applica-
tion recording the scores of thousands of online game players may produce a consider-
able amount of data. It is also possible to tell Redis to persist every single in-memory
database write to disk individually, thus providing very good durability. Unfortu-
nately, this reduces Redis' performance quite a bit, negating the advantage of using a
memory-based system in the first place. On top of all this, Redis also has an easy-to-
configure replication feature, which allows a primary instance to stream updates to a
secondary server asynchronously.
Redis is excellent at setting and getting data quickly based on the data's keys—but
as it is a key-value store, it does not allow queries to access the values referred to by
the keys. If your application requires a different type of functionality, such as the need
to quickly retrieve data based on a particular aspect of the data itself, then a different
type of nonrelational database, such as a document store, may be more appropriate.
Search WWH ::
Custom Search