Skip to main content

Redis and KeyDB In-Memory Databases

On this page you will find information about Redis as a Managed Service. Redis is a non-relational in-memory database that stores data as keys and values. If desired, the fork KeyDB can be used instead, which is compatible with Redis and focuses on better performance with a multithreading engine.

IP/Port​

Redis is accessible on port 6379 by default. The service is bound to localhost and cannot be accessed externally. If you use a separate managed server for Redis, we can adapt the configuration accordingly so that the service can be accessed from e.g. your web server.

Memory Management​

Persistence​

Keys are stored in RAM during the runtime of Redis and are not read from the hard disk, which allows for exceptional performance. Consequently, there are no consistent write operations to a long-lived storage location, which means that the persistence of the data cannot be guaranteed.

To ensure that previously written keys are not lost when the Redis service or managed server is restarted, snapshots are regularly written to the hard drive. The following intervals apply:

  • Every 900 seconds if at least one key has been changed
  • Every 300 seconds if at least 10 keys have been changed
  • Every 60 seconds if at least 10,000 keys have been changed

If desired, the intervals can be customised by Nine Support and the snapshot file can be included in the regular backup routine.

What happens if no more memory can be allocated?​

A Redis instance is allocated a quarter of the memory available on the managed server.

Predefined strategies set by the maxmemory_policy define what should happen when the available memory is exhausted. By default, the policy allkeys-lru is being used, which behaves as follows:

allkeys-lru: Keeps most recently used keys; removes least recently used (LRU) keys

This ensures that no data is lost during writing due to a lack of available memory. To free up the required space, keys that have not been accessed for the longest time are automatically deleted. This form of balancing is designed to ensure the highest possible availability of the application in the most variety of scenarios.

If you are familiar with your application's access patterns, are dependent on longevity of the keys or are working with TTLs and would like to use e.g. volatile-lru, please contact our support team to adjust the default configuration. An overview of all policies can be found in the Redis documentation.