Databases Reference
In-Depth Information
4.5.1
Customization for RAM or SSD stores
In chapter 2 we reviewed how access times change based on the type of memory
media used. Some NoSQL products are designed to specifically work with one type of
memory; for example, Memcache, a key-value store, was specifically designed to see if
items are in RAM on multiple servers. A key-value store that only uses RAM is called a
RAM cache; it's flexible and has general tools that application developers can use to
store global variables, configuration files, or intermediate results of document trans-
formations. A RAM cache is fast and reliable, and can be thought of as another pro-
gramming construct like an array, a map, or a lookup system. There are several things
about them you should consider:
Simple RAM resident key-value stores are generally empty when the server starts
up and can only be populated with values on demand.
You need to define the rules about how memory is partitioned between the
RAM cache and the rest of your application.
RAM resident information must be saved to another storage system if you want it
to persist between server restarts.
The key is to understand that RAM caches must be re-created from scratch each time a
server restarts. A RAM cache that has no data in it is called a cold cache and is why some
systems get faster the more they're used after a reboot.
SSD systems provide permanent storage and are almost as fast as RAM for read
operations. The Amazon DynamoDB key-value store service uses SSD s for all its stor-
age, resulting in high-performance read operations. Write operations to SSD s can
often be buffered in large RAM caches, resulting in fast write times until the RAM
becomes full.
As you'll see, using RAM and SSD s efficiently is critical when using distributed sys-
tems that provide for higher volume and availability.
4.5.2
Distributed stores
Now let's see how NoSQL data architecture patterns vary as you move from a single
processor to multiple processors that are distributed over data centers in different
geographic regions. The ability to elegantly and transparently scale to a large number
of processors is a core property of most NoSQL systems. Ideally, the process of data
distribution is transparent to the user, meaning that the API doesn't require you to
know how or where your data is stored. But knowing that your NoSQL software can
scale and how it does this is critical in the software selection process.
If your application uses many web servers, each caching the result of a long-
running query, it's most efficient to have a method that allows the servers to work
together to avoid duplication. This mechanism, known as memcache , was introduced in
the LiveJournal case study in chapter 1. Whether you're using NoSQL or traditional
SQL systems, RAM continues to be the most expensive and precious resource in an
Search WWH ::




Custom Search