Redis Enterprise

Technology

A Foundational Look at Redis Enterprise

Redis Enterprise was built from the ground-up to serve as a system of record for any application. It enhances the speed and the versatility of Redis with robust reliability, ease of use, cost savings and new advanced capabilities. The below sections describe our technology implementation, that ensures the seamless linear scaling, blazing fast performance, reliability and security that customers expect from enterprise-grade databases. Read on to understand the concepts and the architecture behind advanced features like Active-Active Geo Distribution with CRDTs, Redis on Flash, RediSearch and integrated modules.


Redis Enterprise Cluster – An Architecture Overview

Redis Enterprise Cluster is based on a shared-nothing symmetric architecture that facilitates extremely high performance with linear scalability, high availability with seamless single digit (<10 sec) failover time, greater security and easy manageability. It’s built-in multi-tenancy allows you to create any number of Redis databases and of any type (single shard, highly available (HA) Redis, Clustered, and HA Clustered) over a shared pool of memory in a fully isolated manner.

Learn more

Redis Enterprise Cluster

Cluster Architecture Symmetric-Architecture Security Diagram

 


Scaling Redis Enterprise

Redis Enterprise offers multiple ways to scale:

  • Up/down – by adding/removing shards to/from existing cluster nodes and if needed upgrading/downgrading the nodes
  • Out/in – by adding/ removing nodes to/from the cluster, re-sharding databases and rebalancing databases’ shards across the cluster, scaling out/in proxies to handle increased/decreased throughput requirements without changing your app, by adding more proxies behind your database endpoint or by utilizing OSS cluster API.
  • Read Scaling- using the “replica of” feature to scale read operations without impacting your HA settings.

Learn more

Scale out, Rebalancing, Resharding

technical-diagram-scaleing

 


Highly Available Redis

(with failover time in single digit seconds)

Redis Enterprise provides a different approach for high-availability: it relies on fast, pure in-memory replication and depends on node-to-node communication to detect failure and network split events, rather than on shard-to-shard communication. This architecture enables a single digit auto-failover time (<10 sec) and significant cost savings by reducing the number of copies of data needed. A full suite of failure protection, backup and recovery options ensure robust and reliable Redis databases.

Learn More

High Availability and Durability

diagram-durability


Durable Redis

Redis Enterprise provides full durability through two persistence mechanisms:

  • Append-Only file (AOF) per write or per second
  • Snapshots (point-in-time copy of the entire database with configurable time intervals).

Redis Enterprise cluster is designed to work with network-attached storage for data persistence. By default, every node in the cluster is connected to a network-attached storage resource, thus making the cluster immune to data loss events like multiple node failures when no copy of the dataset is left in RAM.

Learn More

Durable Redis


Backup, Restore and Cluster Recovery

Redis Enterprise allows you to backup your database to any of the major public clouds’ storage (AWS S3, Azure Blob Storage, Google Cloud Storage) as well as to any FTP or Swift services. Backup is done in a point-in-time manner and across all the shards of the database. Restoring from backups is simple and requires only a few clicks in Redis Enterprise.

Cluster recovery is an independent tool that re-instates a fully operational Redis Enterprise cluster from scratch in cases where the cluster has reached an irrecoverable state, for example, when a majority of the cluster nodes are down.

Read More

Backup, Restore

 


Active-Passive Geo-Distribution with “Replica-of”

Gain great flexibility in creating geo-distributed Redis Enterprise databases through its ‘Replica-of ‘ capability. This unique directional replication capability allows you to synchronize data between any source and destination databases, placing the data close to the user for low latency read access. You can configure multiple sources to a single destination or multiple destinations to a single source. Furthermore, the number of nodes and shards at the source cluster can be totally different than the number of nodes and shards at the destination. This capability allows you to scale reads, non-disruptively migrate databases and create highly available copies of the data.

Learn More

Active Passive Geo Distribution Diagram

 


Active-Active Geo-Distribution (CRDT-Based)

Active-active geo-distributed topology is achieved by implementing CRDTs (Conflict-free Replicated Data Types) techniques in Redis Enterprise using a global database that spans multiple clusters. This globe spanning database is called a “Conflict-free Replicated Database” or “CRDB.”

CRDB provides three fundamental benefits over other geo-distributed solutions:

  • Local latency on read/write operations, regardless of the number of geo-replicated regions and their distance from each other
  • Seamless conflict resolution (“conflict free”) for simple and complex data types like those of the Redis core or the Redis modules.
  • Even if the majority of geo-replicated regions (for example 3 out of 5) are down, the remaining geo-replicated regions are uninterrupted and can continue to handle read and write operations.

Learn More

Active-Active Geo Distribution

 


Redis on Flash (RoF)

Redis Enterprise allows you to create Redis on Flash (RoF) databases that extend your RAM capacity with local SSDs (SATA/NVMe-based) and store significantly more data with less resources, reducing costs. It is important to note that Flash is not designed to be used as an alternative mechanism for data persistence. In fact, RoF retains the same data-persistence mechanisms as Redis : AOF and Snapshots.

RoF is based on the core open-source Redis architecture with the following primary enhancements:

  • Rather than keeping the entire dataset in RAM, RoF only keeps the keys and the Redis dictionary (the data structure behinds the keys) in RAM, along with the “hot values” of the dataset (the working set). The “warm values” (the lesser used portion of the dataset) are kept on the local SSD (the Flash storage).
  • To avoid head-of-the line blocking scenarios resulting from the single-threaded nature of Redis, RoF is based on a multi-threaded asynchronous architecture that guarantees no blocking between a heavy request made to Flash and a light request made to RAM.

Learn More

This multi-layer memory architecture is shown in the figure below:

Redis Flash Memory Architecture Diagram

 


RediSearch

RediSearch is a powerful text search and secondary indexing engine, built on top of Redis as a Redis Module.

Unlike other Redis search libraries, it does not use Redis’ internal data structures such as Sorted Sets. Using its own highly optimized data structures and algorithms, it allows for advanced search features, high performance and low memory footprint. It can perform simple text searches as well as complex structured queries, filtering by numeric properties and geographical distances.

Learn More

RediSearch

 


Integrated Modules

Redis Enterprise allows you to seamlessly integrate Redis modules into your database. Modules are add-ons to Redis which extend Redis to cover most of the popular use cases for any industry. Redis Enterprise comes with the following built-in Enterprise Modules, each trusted, tested and verified to work with Redis Enterprise and open-source Redis:

  1. RediSearch (high performance full-text search engine)
  2. RedisGraph (high performance, memory-efficient Graph database)
  3. ReJSON (a native JSON data type for Redis)
  4. ReBloom (a bloom filter data type for Redis)

Learn More


Redis Enterprise: A Secure Database

Redis Enterprise architecture is built to provide a great deal of control to help you meet your security standards and regulations. It provides separate paths for administrative access and data access, which helps simplify compliance. The use of separate paths means that administrators do not get direct access to customer data. It also means that applications and developers can have full access to read and write data without acquiring cluster administration privileges that may impact other databases/applications utilizing the same cluster.

Learn More