KeyDB as a [potential] alternative to Redis

There are no reviews of a "faster alternative to Redis" on Habr — KeyDB. Having gained some fresh experience using it, I want to fill this gap.

The background is fairly mundane: once, during a major traffic surge, there was a significant degradation in application performance (namely, response times). At that moment, unfortunately, we couldn't conduct a proper diagnosis of what was happening, so we later scheduled a series of load tests. After conducting them, we identified the bottleneck, which turned out to be the Redis database cache. As is often the case, the problem couldn't be solved instantly or correctly — by the developers (by changing the logic of operation). Thus, curiosity and the desire to tackle the situation through an alternative approach kicked in. This is how this article came to be.

Issues

About Redis in general

As many know, Redis is a single-threaded database. To be more precise, it is so in the context of user data operations. Since version four, the service and internal operations of Redis have been transitioned to parallel execution. However, this change has only affected a small portion of the load, as most operations revolve around user data.

A countless number of discussions have been sparked on this topic, but the Redis developers stubbornly refuse to implement full parallelism, citing how much it complicates the application, increases overheads, and adds bugs. Their position is that if you are facing issues with single-threading, you have architectural problems with your application that need to be addressed. Among users, however, there is also an "opposing camp" — those who have hit the single core limit and argue that Redis itself creates the bottleneck. In cases of truly large loads, sooner or later, one will inevitably face this issue, which imposes significant limitations on the architecture and/or necessitates complexity in it.

I won’t judge either opinion. Instead, I will share our specific case and how we resolved it.

Our case

In one of our projects, we encountered a situation where the development team set up extremely aggressive caching of data from the database (PostgreSQL) via Redis. This was the only path that during sharp traffic spikes saved PostgreSQL itself and, consequently, the application from failure.

After a series of load tests, we analyzed the situation and discovered that Redis was limited to a single core (what is referred to as "in the army"), after which there was a fairly rapid degradation of the application. The "choking" had a geometric progression: as soon as Redis reached its performance limit, everything stopped working.

It looked something like this:

From New Relic, the problem was clearly identified:

And here is the statistics for the operation get in Redis:

After the problem was detailed to the development team, it turned out that "the problem cannot be solved right now." Thus began the search for a solution on the operations side, and the answer was the already mentioned KeyDB.

However, before we proceed to its review, it is worth mentioning that the project uses standalone Redis, as the clustered solution based on Sentinel falls significantly short in terms of latency. One obvious solution was to create several cache replicas: let the application balance its load everywhere! However, after consulting with the developers, we were forced to abandon this option due to the active and complex cache invalidation mechanism in the application. The same problem extended to cache sharding.

A brief overview of KeyDB

In search of a possible solution to the problem, we discovered an application called KeyDB. It is a fork of Redis, developed by a Canadian company and distributed under the BSD open license. The project is quite young: it has existed since early 2019. The history is such that the authors also once faced the limitations of Redis… and decided to create their own fork. Moreover, it not only addressed known issues but gained additional features available only in the enterprise version of Redis.

For those interested in learning more about KeyDB, there is a nice introductory article on Medium, which presents the DBMS and brief benchmarks comparing it to its

First of all, we were attracted to KeyDB as a potential solution to our problems, and we were also interested in some additional features. Using KeyDB promised the following advantages:

• full multithreading support;
• complete and absolute compatibility with Redis (this was particularly important for us, as making any modifications on the application side was not feasible), which also promised a smooth migration;
• an integrated backup mechanism to S3 storage;
• easy-to-implement active replication;
• simple clustering and sharding without Sentinel or other auxiliary software.

Over 3,000 stars and numerous contributors on GitHub also looked promising. The application is actively developed and maintained, as evidenced by the commits, communication in issues, and also by the closed (accepted) PRs. The main maintainer's response is always friendly and prompt across all fronts. Overall, there were plenty of arguments in favor.

Migration and Results

Even though the migration project was somewhat of an adventure (due to the novelty of KeyDB), there was not much to lose. After all, rolling back changes was quick and easy—fortunately, the entire infrastructure is deployed in Kubernetes, and the built-in mechanisms Rolling Update effectively handle such tasks.

In general, we prepared Helm templates, switched the application in the test environment to the new database, and deployed everything, handing it over to the client’s QA department.

Testing began, which lasted about a week, and we did not delve into the details. We only know that the client checked the standard features of working with Redis using the PHP driver phpredis, and also conducted QA testing of the user interface. After that, we received the green light: no side effects from using the new software were detected. That is, from the application's perspective, nothing changed at all..

It is worth noting that we did not change anything in the config either: literally—we just replaced the image being used. The same goes for monitoring and exporting metrics to Prometheus: the most common of them works perfectly with KeyDB without any modifications. Thus, it can be confidently stated that from an operational standpoint, the migration was simply ideal.

Thanks to all of this, after switching the application to the new DBMS, you don't have to change anything, and as a "stabilization measure," you can leave it as is to operate in production for a while. However, if you want to see a performance boost (or any changes at all), you need to remember that default the KeyDB parameter responsible for multithreading (server-threads) is set to one, which means the DBMS operates exactly like Redis..

After the switch, testing, and some time running on the new application (with KeyDB), we decided to repeat the load testing with the same parameters that were used for Redis. What were the results?..

The CPU usage graph immediately showed the elimination of the "ceiling" issue on a single core: the process began to utilize available resources:

Later, I tried to heavily "stress" the application and saw usage of up to three cores…

According to New Relic, the web application as a whole, while having the same load, began to behave noticeably more adequately. Some performance degradation was still observed, but comparing it with the similar graph above, you can assess the significant progress for yourself:

The latency metric with the new database (KeyDB) also worsened, but remained within acceptable limits:

In the next graph, it is clear that the number of requests to KeyDB is similar:

In summary of these synthetic tests, it can be said that both Redis and KeyDB show significant performance degradation in latency (40 ms+) with a substantial increase in the number of parallel connections (1000+). In our case, the web application managed to lower Redis's latency even with fewer connections (400+), while for KeyDB, this load remained acceptable.

Conclusions

This example beautifully illustrates the power of the Open Source community in the development of projects it cares about. I came across a great saying on the internet, the essence of which boiled down to: 'A large company creates an interesting product, makes some of its features open, but keeps the most important part paid. The community uses it for a while, and then someone decides to fork it, implementing those very paid features and making them available to everyone.' KeyDB is a prime example of this.

Speaking of the migration, which surprisingly went smoothly, we did not experience such a significant increase in performance that one might expect based on KeyDB authors' graphs… However, this is just our specific case, which may have many deviations, including the notorious application architecture (for example, the vast number of commands get in Redis instead of a more efficient option of aggregated requests mget…). Nevertheless, we achieved positive results, along with many useful features that we will be implementing in the near future.

Overall, KeyDB looks promising: as we gain practical experience with this DBMS (which we have yet to accumulate!) and as the project develops, we will consider its application in other situations.

However, this article should not be viewed as a guide (much less a call) to universally abandon Redis in favor of KeyDB. Despite our positive experience, it is clear that this is not a silver bullet. The case was quite specific: specifically for solving an immediate problem in a situation that required a quick and low-cost solution, this approach proved justified. Will KeyDB be useful in your case? At least now you know that such a potential exists.

P.S.

Also read in our blog:

• «Databases and Kubernetes (Overview and Presentation Video)»;
• «Migration of Cassandra to Kubernetes: features and solutions»;
• «Challenging migration of MongoDB to Kubernetes»;
• «Challenging migration of RabbitMQ to Kubernetes».

Source: habr.com