Redis 101: Optimizing performance by leveraging cache

Redis 101: Optimizing performance by leveraging cache Build • Hana Khelifa • 07/10/22 • 10 min read

It all started when Salvatore Sanfilippo wondered in 2009: What if a cache could also be a durable way to store data? And boom, Redis was born!

Now, Redis powers most of the significant applications you know. It has been voted the most loved database for four years, the most widely used NoSQL database , and the most-launched database on Docker Hub.

That is why we are particularly excited to announce we are launching Managed Database for Redis™ , to make it even easier for developers to leverage Redis in the Scaleway ecosystem. We built a whole system on top of Redis to facilitate the setup of a secure cache. The result? A lighter load for your primary database and a secure and smooth automated caching service which improves your database’s performance.

Redis: A history

Redis, which stands for Remote Dictionary Server, is an open-source in-memory multi-model database that was quickly adopted by certain heavily trafficked sites. Twitter built its architecture for real-time delivery on 300k tweets/sec on Redis, GitHub leveraged Redis to make their platform faster , and StackOverflow has quite an aggressive approach to cache for optimization .

Redis shifted the way we thought about storing data. It created a system where the data is always modified, or read, from the main computer memory (RAM), as opposed to the much slower disk (Disk), allowing it to improve performance drastically. It also stores its data on the disk so it can be reconstructed as needed, meaning the database is fully durable when supporting tasks like snapshots and backups.

Since Redis is a memory-oriented database, it's really effective for storing frequently updated real-time data, such as session store, state database, statistics, and caching, and its advanced data structures makes it versatile enough to handle many types of data.

Redis is not a NoSQL replacement for classic relational databases since it doesn't support many standard features of the RDBMS world, like querying your data, which might slow it down. However, Redis shines when it comes to supplementing specific functionalities when speed and support for advanced data structures is needed.

Redis vs. other database

What makes Redis stand out among all the different database systems? Redis popularized the idea that a system can be a store and a cache simultaneously. Redis provides an unusual data model in comparison to other relational database management systems. User commands do not describe a query to be executed by the database engine, but specific operations performed on given abstract data types. As a result, data must be stored in a way suitable for fast retrieval, without help from the database system in form of secondary indexes, aggregations, or other common features of traditional RDBMS.

Redis versus other database systems

Optimizing performance with caching mechanism

It’s safe to say Redis is a solid option if you are looking to improve your application performance with a caching mechanism. In fact, that’s the use case we had in mind when we built Scaleway’s Managed Database for Redis™ .

Let’s take a look at how it works.

When your API tries to retrieve data from your main database node–the master, the source, the primary–the read transaction gives more work to your database process, adding load to the database that was already running other operations like updating data, running a query, and creating a backup.

The more load you add on that primary node, the slower it becomes.

This moment–when your application needs information–is the perfect opportunity to optimize performance by leveraging cache. So instead of requesting the primary node, it will request Redis. If the data was previously stored in your Redis cluster, it will be surfaced as a response in milliseconds–or even less for simple requests–with zero impact on your main database node.

Now, if it’s the first time you’ve requested the data, or it has been a long time since the last request, the application will have to get it from your main database. But, the application will store a copy of the data in Redis for faster access next time.

Redis caching system

Redis versus Scaleway’s Managed Database for Redis™

We built our managed database with multiple services that differentiate it from a self-hosted or on-premise Redis database.

First, you’ll get automatic engine updates to ensure the latest versions are integrated and the deprecated ones are stopped.

Then, we’ll handle the time-consuming part of installing and setting up your machines, configuring them so you can easily reach them through an endpoint.

We also simplified network configurations. You’ll choose if you want your resource to be public (on the internet–in which case we recommend using ACLs), or private (by attaching a private network), and we do the rest.

Finally, let’s talk about the cluster mode. This is where it gets really interesting. Each Managed Database for Redis™ cluster consists of a minimum of three and a maximum of six compute Instances. Each Instance hosts a primary Redis™ Instance and a secondary Instance for one of the other nodes. If one of the primary nodes fails, the remaining nodes hold a vote and elect one of the secondary nodes as the new primary node. When the failed node rejoins the cluster, it automatically becomes a secondary node and begins to replicate the data of another primary node.

And there lies the genius behind our Redis cluster mode: It enables vertical scaling and makes data Highly Available. Let’s take a closer look.

Managed Database for Redis™ cluster‌‌

Each node contains both a source and a replica –the live copy of a source in a different node. The cluster nodes use hash partitioning to split the keyspace into key slots. Then each replica copies the data of a specific source. Once the data has been copied, the replica can be reassigned to replicate another source or be elected as a source node if needed.

Having the operation spread across multiple nodes instead of just one entry point is much better for scaling. Cluster mode ensures high availability through a three- to six-node multi-master architecture. In case of downtime on a node in the cluster, a new node is able to take over the requests with minimal downtime. And when a node dies in a cluster, another node takes over the request to ensure continuity in the service while a new node is…