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 versus other database systems

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

Source

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 being created and configured. Cluster mode also allows vertical scaling. For example, you can create a three-node Managed Database for the Redis cluster and decide later to add up to three nodes, depending on your workload and architecture requirements.

All that can be built in two minutes in the console!

When we built Managed Database for Redis™, we had three characteristics on which we refused to compromise.

First, the performance. We aimed for excellence. We know that latency is a major pain point for you, and we wanted to reduce it to the absolute minimum. Implementing cache is an effective and easy way to speed up applications, and for that purpose, our managed Redis has quite powerful performances.

Requests

Clients

Threads

Data Size

Operation

Ops/sec

KB/sec

Average Latency

10000

10

1

32

Sets

1981.170

152.590

0.360

10000

10

1

32

Gets

19789.980

770.910

0.358

10000

10

1

8192

Sets

2582.680

20784.690

0.437

10000

10

1

8192

Gets

25798.420

1004.960

0.343

10000

50

4

32

Sets

5936.970

457.250

3.096

10000

50

4

32

Gets

59304.470

2310.160

3.091

10000

50

4

8192

Sets

4884.740

39311.030

5.591

10000

50

4

8192

Gets

48793.740

1900.730

3.508


The second goal we had for this product was security. Data is gold nowadays, and just like any treasure, its protection has to be guaranteed. So we built a set of options that can either be cherry-picked or combined: a private network to isolate, ACLs to authorize only known connections, SSL certificates to encrypt your in-transit data, and IAM to handle permissions.

And last but not least: no lock-in. We don’t mind repeating ourselves: This is core to everything we do. We love and support open-source solutions for the innovation they bring to IT communities. Redis is a great example of just such a solution, and we promise we will always be compatible with the official versions of Redis.

Recap: key features Scaleway’s Managed Database for Redis™

In short, Scaleway’s Managed Database for Redis™ offers:

Horizontal and vertical upscaling
We made scaling up horizontally or vertically as smooth as possible. After just a few clicks on the console to choose certain configurations, you’ll be able to add nodes on your cluster or to increase the power of your nodes.

High Availability
Your data will be automatically replicated by your nodes, across source and replicas, to ensure a high availability anywhere and anytime–whether you have three nodes, six, or any number in between.

Data encryption
You can set up an SSL connection automatically to protect your data in transit.

Security and isolation
Through our ACLs and Private Network, you are free to choose who will have access to your cluster. Each node is isolated at Scaleway, and each node has its own dedicated virtual machine.

Powerful caching solution
Redis can serve items at sub-millisecond response times for read and write latency, which facilitates the scale for higher loads.

Managed Database
A managed Redis cluster can be deployed in a few clicks through the console, API calls, or Terraform. Machines go from 2 to 64GB of RAM, and from 2 to 16 vCPU.

Ready to try it?

Managed Database for Redis™ is ideal for database queries, persistent sessions, and web page caching, but also for caching frequently used objects like images, files, and metadata.

Nothing speaks louder than a good demo, right? So here’s one where we show how to launch your first Redis™ Database Instance within the Scaleway ecosystem, and how to use it with a web application.

We hope you learned a bit more about Redis, and Managed Database for Redis™. To give it a try, check out this tutorial on how to create a Redis™ Database Instance. And if you wanna chat with us and our community about Redis, join #managed-database-for-redis in our Slack Community.

Read more