When we launched KeyDB back in March of last year we were really excited about the possibilities that multithreading could bring. Today with KeyDB we are continuing that vision with our new FLASH feature which achieves near RAM performance while taking advantage of the massive cost savings FLASH storage can provide. As with all KeyDB features, FLASH support continues to provide full compatibility with existing KeyDB and Redis clients.
Selecting an EC2 Instance for KeyDB
When searching for information on what instance type to use, the answer is typically “it depends”. This article boils down instance types with both general data on EC2 types as well as in depth analysis of KeyDB performance and selection for the different types.
KeyDB is a high performance fork of Redis that’s able to hit 1,000,000 ops/sec on a single node, without sharding. This article not only discusses the performance, but the benefits that go along with it. More power means less moving parts to do the same job, and the semantics of that statement are worth discussing.
This article discusses several changes we have made to the EXPIRE command and how it works. We have added the ability to expire individual members of a set with the EXPIREMEMBER command and have also enabled active deletion to operate in near real time which has big advantages for those who rely heavily on using expires in production. Throughout the work with the EXPIRE command we have actually achieved 5-10% memory savings with these.
We are excited to introduce version 5.1 which includes new stable features to the RELEASE_5 branch. If you haven’t been keeping up with KeyDB here are a few things you can expect to see!
What if I told you there is a fork of Redis that can run 5x faster with nearly 5x lower latency. What if you no longer needed sentinel nodes and your replicas could accept both reads and writes? This could provide the potential to achieve a 10x reduction in the amount you shard.
Today ARM processors are becoming a cost effective way of computing providing great bang for your buck… and now they are in the cloud! This begs to question whether your setup is still the most economical means for serving your customers.
Active Replication eliminates the need for having ‘monitoring sentinel nodes’ to decide when to perform failovers in a high availability setup. This also enables your active replica node to accept reads and writes while actively syncing with the other active replica node.
We’ve talked to many of our users who were looking to optimize their cost on AWS. While most had experimented with the many available x86 based instance types we were surprised that few had tried the Arm-based Amazon EC2 A1 instances. These Arm-based instances come with unique performance advantages for multi-threaded cache server workloads. To understand why cache databases, and KeyDB specifically, is uniquely suited to Arm we have to first understand a little about the hardware.
A lot of sites run replica nodes for high availability of their servers. Makes sense, but is this replica being fully utilized? Or are you just paying for high availability without getting the performance boost of essentially doubling your resources? This article discusses options used with Redis, as well as the active-replication option used in the Redis compatible database KeyDB.