Under the Hood: Redis Enterprise Flash Database Architecture
Under the Hood: Redis Enterprise Flash Database Architecture
Dig deep into Redis Enterprise architecture and see how combining flash-based SSD drives into the mix works in practice.
Join the DZone community and get the full member experience.Join For Free
Download "Why Your MySQL Needs Redis" and discover how to extend your current MySQL or relational database to a Redis database.
For many interactive applications, responsiveness is key to engaging and fluid experiences. However, RAM is expensive. Keeping a large amount of data with Redis can be costly. Given the cost of infrastructure, you end up choosing between the following two options:
Pay a premium for storing sizable datasets in RAM with Redis.
Limit Redis database use to the most valuable data and augment Redis with disk-based relational or NoSQL databases.
Redis Enterprise Flash provides a better option. Redis Enterprise Flash technology combines RAM and flash to store large datasets in Redis with much lower cost per GB. With Redis Enterprise Flash, you can extend RAM onto Flash devices like NVMe- and SATA-based SSD drives and keep larger data sets in Redis, all without losing Redis' performance advantage.
Let's dig deeper into Redis Enterprise architecture to see how combining flash-based SSD drives into the mix works in practice.
Redis Enterprise Architecture Overview
Let's start with an overview of Redis Enterprise before we drill into the Flash architecture.
A Redis Enterprise cluster is composed of identical nodes that are deployed within a data center or stretched across local availability zones. Redis architecture is made up of a management path (depicted in the blue layer in Figure 1 below) and data access path (depicted in the red layer in Figure 1 below).
Management Path is composed of a proxy that helps scale connections and a cluster manager that is responsible for orchestrating the cluster and the placement of database shards, as well as detecting and mitigating failures.
Data Access Path is composed of master and slave Redis shards. Clients perform data operations on the master shard. Master shards maintain slave shards using in-memory replication.
Figure 1: Redis Enterprise nodes, with blue tiles representing the management path and red tiles representing the data access path with Redis as the shards.
High Availability With Replication
Redis Enterprise uses in-memory replication to maintain master and slave replicas stretched across nodes, racks, and zones. Redis Enterprise comes with various watchdogs that detect and protect against many failure types. In the node, for network and process failures that render the master replica inaccessible, Redis Enterprise automatically promotes the slave replica to be a master replica and redirects the client connection transparently to the new master replica.
Besides the intra-cluster replication, Redis Enterprise also has built-in WAN-based replication for Redis deployments across multiple data centers. You can find additional details in the References section.
Scaling and Performance With Sharding
Each Redis Enterprise cluster can contain multiple databases. In Redis, databases represent data that belong to a single application, tenant, or microservice. Redis Enterprise is built to scale to hundreds of databases per cluster to provide flexible and efficient multi-tenancy models.
Each database can contain few or many Redis shards. Sharding is transparent to Redis applications. Master shards in the database process data operations for a given subset of keys. The number of shards per database is configurable and depends on the throughput needs of the applications. Databases in Redis Enterprise can be re-sharded into more Redis shards to scale throughput while maintaining sub-millisecond latencies. Re-sharding is performed without downtime.
Figure 2: Redis Enterprise places master (M) and slave (S) replicas in separate nodes, racks, and zones and use in-memory replication to protect data against failures.
In Redis Enterprise, each database has a quota of RAM. The quota cannot exceed the limits of the RAM available on the node. However, with Redis Enterprise Flash, RAM is extended to the local flash drive (SATA, NVMe SSDs, etc.). The total quota of the database can take advantage of both RAM and flash drive. The administrator can choose the RAM vs. Flash ratio using the slide seen in Figure 3. This ratio can be updated at any moment in the lifetime of the database without downtime.
Figure 3: Create Database dialog in Redis Enterprise Pack with the view of the RAM and Flash configuration.
Redis Enterprise Flash Architecture
With Redis Enterprise Flash, you get an enhanced version of Redis as a shard. Besides other modifications, with this shard, instead of storing all keys and data in RAM, less frequently accessed values are pushed to Flash. In Figure 4, you can see the RAM and Flash combined together for storing data as two separate shades of gray.
Figure 4: Redis Enterprise Flash shards with process, memory, and disk storage components. Redis Enterprise Flash uses both RAM and Flash for keeping data. RAM store all keys and some values. As the RAM fills up, less frequently used values are moved to flash (NVMe or SATA-based SSDs).
If applications need to access a value that is in flash, Redis Enterprise automatically brings the value into RAM. Depending on the flash hardware in use, applications experience slightly higher latency when bringing values back into RAM from flash. However, subsequent accesses to the same value is fast once the value is in RAM.
Using smart placement techniques, Redis Enterprise Flash adapts to changes in the workload over time. Redis Enterprise Flash has a background task that ejects less frequently used values to flash in order to adapt and maintain a healthy dose of free space for new incoming operations.
It is important to note that even though values get ejected to Flash, all keys and metadata stay in RAM. Keys are typically smaller in size than values. Many Redis commands require access to keys without requiring access to the value. Keeping the full list of keys in RAM ensures many operations can be executed without any penalty of value retrieval from flash. Background services manage expiry, ensuring that the uniqueness of keys in the database is frequent operations in the database. With all keys stored in RAM, it is easy to check if the key already exists before inserting the new key or to run expiry checks.
Redis Enterprise Flash uses a flash drive as a RAM extension. At bootstrap of the database, Redis Enterprise Flash expects and ensures that both RAM and Flash drive are completely empty. Once the engine is started, RAM and Flash are populated from the durable copy of data (disk or another replica). When using Redis Enterprise Flash, you can use either of Redis Enterprise's two durability options:
Disk-based durability: Redis Enterprise still maintains a durable copy on disk. Just like disk-based systems, this IO path is placed on a slower and more durable network-attached storage device. Redis databases provide tunable options to maintain this durable copy. You can read more about the durability options here.
Replication-based durability: Redis Enterprise also maintains a replica — a slave shard — for durability. Replication-based durability protects against node, rack, or zone failures and provides better write performance than network-attached storage writes. This means that in the event of an unplanned interruption, it is likely that your replica is more up-to-date than your durable copy on disk. To take full advantage of the replicated-durability, Redis provides the
WAITensures that a write can wait for acknowledgement until multiple replicas confirm that write. This ensures that a write confirmed with
WAITon replicas will be durable even if a node catches on fire and never comes back to the cluster.
"Buffer Cache" vs. "RAM Extension" Approach
The smart data placement in Redis Enterprise Flash, which brings values from flash into RAM based on working set, is similar to disk-based database systems and the "cache miss" on the buffer cache of the database. However, similarities between disk-based databases and the RAM extension method used in Redis Enterprise Flash end there. The IO patterns used in Redis Enterprise Flash are much more efficient than those of a disk-based system. Here are some of the differences between the two.
Hot Value Handling
Many application workloads perform repeated writes to a set of "hot" keys in a short period of time, such as when the keys belong to an active piece of data. For example, imagine repeated updates by an app to its database, 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, updates to data in RAM are not sent to flash in Redis Enterprise Flash. The RAM extension approach used by Redis Enterprise Flash does not require any writes to flash under repeated writes to "hot" keys, unless the value 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 writes. This ensure that the IO bandwidth of the Flash drive is only used for ejections to 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, thus it can fully take advantage of local, fast ephemeral storage.
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 that 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 Redis Enterprise Flash are based on the new direction in-memory technology. As persistent memory is introduced into the compute architecture such as Intel's 3DXPoint, the idea behind these 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. Redis Enterprise Flash was designed to exploit these benefits.
Published at DZone with permission of Cihan B. , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.