Running Out of RAM on Redis? No More OOM With Hybrid Memory (RAM and Flash)

We all have been in front of a slow, sluggish app or page before. Responsiveness is key to engaging and fluid experiences on the web and on mobile apps. In-memory databases help reduce latencies to sub-milliseconds and Redis is typically the choice for developers to achieve this. However keeping a large amount of data in RAM can be expensive. Most of us either pay a premium for storing their larger datasets in RAM, or, we limit use to the most valuable data, and resort to disk-based databases.

With new advances in hardware, flash technology (SSDs based on SATA, NVMe or Intel's 3DXpoint) provides a great alternative for low latency read/writes and comes at a 10-20x cheaper cost compared to RAM on a per GB basis. RAM continues to dominate with lowest latency data access guarantees, however, flash technology is catching up fast with NV-DIMM and NVMe SSDs from major vendors.

Figure.1: Cost of GB per Technology - DRAM to NVMe to SATA SSDs from HW vendors like Intel, Samsung, and others.

With faster and cheaper SSDs, it is possible to combine RAM and flash to store large data sets. This is the difference between a $20K/month bill vs $2K/month bill in the cloud. The cost savings come from flash drives: "10TB in RAM” vs. “2TB RAM + 8TB in Flash drive” (SATA or NVMe based SSDs) can store and serve the same amount of data but lower costs by 5x. 

You can do hybrid memory processing with Redis Enterprise Flash. Instead of storing all data in RAM, it externs RAM onto Flash creating a tiered access strategy. Let's dig deeper.

RAM + Flash Architecture With Hybrid Memory Usage

Redis Enterprise and Redis Enterprise Flash extends Redis storage and are fully compatible with Redis open source. Figure.2 below is a simplified representation of Redis shard architecture in Redis Enterprise Flash.

Internally, Redis Enterprise Flash can store values across RAM and Flash. Redis's lock-free architecture executes events that arrive using the connection and command handlers. The background services manage longer running operations like eviction, expiry, and data placement between flash and RAM. Disk persistence provides local durability and replication provides protected durability by placing replicas in other nodes, racks, or zones. This is a high-level overview. If you'd like to dig deeper into how Redis Enterprise looks like under the hood, you can visit the documentation here.

As the hot working-set (the frequently accessed data) changes over time, values move between flash and RAM. The next section discusses the data placement approach in more detail.

Figure.2: Redis Shard architecture in Redis Enterprise

Place Data With Hybrid Memory Architecture: RAM vs. Flash

With two places to process data, the Redis engine needs a smart strategy to place data for the best latencies. In Redis Enterprise Flash, instead of storing all keys and data in a given shard in RAM, less frequently accessed values are pushed to flash.

If applications need to access a value that is in flash, Redis Enterprise brings the value into RAM. Depending on the flash HW in use, applications experience varying degrees of additional latency when bringing values back into RAM from flash. However, subsequent accesses to the same value is fast, once the value is in RAM.

Over time, free space in RAM shrinks as either new keys and values are inserted into the shard or more values on flash get accessed and are brought into RAM. To maintain a healthy dose of free space of new incoming operations, a Redis Enterprise Flash shard comes with a background task that ejects less frequently used values out to flash. This is done both reactively and proactively based on need.

Memory Architecture: “Buffer Cache” vs “RAM Extension” Approach

The data placement in Redis Enterprise Flash adapts to the working set over time. This is similar to disk-based database systems and the "buffer cache" of the database. RDBMSs and databases like MongoDB are examples of disk-based systems. However, similarities between "disk-based databases with buffer-cache" and the Redis Enterprise Flash with hybrid memory architecture end there.

The IO patterns used in Redis Enterprise Flash when accessing Flash are much more efficient than the IO done by a disk-based database system. Here are some of the differences between the IO patterns:

• Hot Value Handling: Many application workloads perform repeated writes to a set of “hot” keys in a short period of time. This may happen because the keys belong to an active piece of data - for example: imagine repeated updates by the app to a database that is tracking a current shopper's state on a site as the shopper views various products.

Disk-based databases perform these writes both in RAM and on disk to persist the changes each time. However, in the hybrid memory architectures in Redis Enterprise Flash, updates to data in RAM are not sent to flash. The RAM extension approach does not require any writes to flash under repeated writes to “hot” keys. The only time IO is exercised to flash is when existing values are brought from flash to RAM or an updated value in RAM gets ejected to flash. Remember that active values don’t get ejected to flash and mostly stay in RAM. So the repeated updates to the active shopper's keys simply happen in RAM and do not require flash reads/writes. This ensures that the IO bandwidth of the Flash drive is reduced to only the movement of data between RAM and Flash.

• Exploiting Ephemeral Storage: The cloud architecture in public or private clouds typically comes with two types of storage - faster ephemeral storage and slower durable network-attached storage. Disk-based databases require their writes to persist all the way to disk for every write. Thus, you are required to use the persisted network-attached storage. However, Redis Enterprise Flash treats flash memory as a RAM extension, and thus can fully take advantage of local, fast ephemeral storage. You can read more about this here.

• Write Amplification:  Disk-based databases depend on disk writes for durability. Each write to disk in disk-based databases is typically done through a redo-log (RL) or a write-ahead-log (WAL) before the actual values are updated on storage. Redis Enterprise Flash uses RocksDB to manage the flash drive access. The call sequence to RocksDB with Redis Enterprise Flash does not need to maintain these additional WALs. Write amplification measures the number of IO operations any single read/write causes. Due to the logged writes, disk-based databases end up with much higher write amplification. You can read more about RocksDB and various IO amplification effects here.

• Advances in HW with Persistent Memory: The techniques used in creating hybrid memory architecture are also based on the new HW direction in-memory technology. As persistent memory technology, such as Intel’s 3DXPoint, is introduced into the compute architecture, Redis Enterprise will be ready to take advantage of it. The idea behind persisted memory technologies is to allow the application to decide which part of the data will be kept in RAM and which will use Flash/Nand in-order to maximize performance at the optimal cost, and this is exactly how Redis Enterprise Flash thinks today as well.

If you'd like to try out the new hybrid memory architecture in Redis, visit Getting Started. For more details on the new hybrid memory architecture, you can visit Redis Enterprise Flash.