Skip to content

Rondis#

Rondis implements a Redis server using RonDB as storage for the data. This implements the Redis wire protocol so will be useful with any Redis clients. The implementation uses 3 tables per database. There is a small table mapping hash keys to a hash key id. This table is cached in Rondis, so mainly a configuration table. All rows are stored in the string_keys table. Only rows larger than 4kB will also use the string_values table.

The implementation of the Rondis commands makes heavy use of new interpreter functionality in RonDB 24.10. This minimises the number of round trips that are required to implement the functionality of the commands.

Rondis is a prototype in RonDB 24.10, this means that the commands supported are tested and verified to be working. However only the commands listed in this documentation are supported and working. We will add support for new commands in later versions of RonDB. We recommend that you work together with the RonDB team if you want to use Rondis in production scenarios. Feel free to also suggest which commands would be most useful to implement in Rondis.

The aim of Rondis is to add a new API to RonDB, we will be compatible with Redis behaviour if configured to be so. Most commands will be compatible with Redis always, but in some cases it makes more sense to provide also incompatible behaviour. One such example is the MSET command. This will be available in different modes, the default behaviour is the RonDB mode in which case it works as if it was a set of independent SET commands (thus same behaviour as if one would have used pipelining of a number of SET commands.

When useful we will also add new commands to Rondis when it makes sense to do so.

Rondis runs inside the REST API server (binary is called rdrs2). One can configure the REST API server to run both REST API and Rondis, or only one of them. If both runs at the same time they will both use the same cluster connection to RonDB data nodes.

All commands are following the Redis protocol, so the responses will be compatible with the Redis protocol. All values are stored in RonDB using VARBINARY columns. RonDB have interpreter commands to convert from strings to numbers and vice versa to support increment commands.

Starting a REST API server with Rondis#

The chapter on REST API server shows how to start and configure a REST API server with Rondis support.

However before starting the REST API server with Rondis it is necessary to create the tables used by Rondis. In the RonDB tree there is a sql file with a stored procedure that can be used to create the Rondis tables.

The commands shown here will create 2 Rondis databases. Change the number 2 to any number between 1 and 16 for the appropriate number of databases to use in your Rondis application. Replace RONDB_TREE with the path to the RonDB source tree and replace SOME_DATABASE with any database already created, e.g. test.

mysql> use SOME_DATABASE
mysql> SOURCE RONDB_TREE/storage/ndb/src/rondis/sql/create_rondis_tables.sql;
mysql> call CreateRondisTables(2);

Rondis disk database#

RonDB supports disk columns. This means that it is very easy to use disk columns to store the value part in Rondis. Simply edit the above file create_rondis_tables.sql to add STORAGE DISK on the columns you want stored on disk. It can be a table attribute in which case it will be applied to all non-indexed columns.

Monitoring#

The REST API have an endpoint to report statistics on number of requests and latency of these requests for the various endpoints. There is also statistics about Rondis usage in this endpoint.

This endpoint is called metrics.

Multiple Rondis server in a RonDB cluster#

It is fully possible to have multiple Rondis server in a RonDB cluster. There could be as many as hundreds of them. They will all see each others changes in a transactional manner. Thus as soon as a Rondis server have completed writing a key all other Rondis servers are able to see this change. Given that each Rondis server can handle millions of key lookups per second, one RonDB cluster is capable of handling hundreds of millions of key operations per second.

High Availability of Rondis#

Since Rondis is implemented using normal RonDB tables, this means that Rondis provides the same high availability as any other RonDB application. This means that you can provide less than 5 minutes of downtime per year in a single cluster and less than 30 seconds of downtime per year if you use asynchronous replication of Rondis tables to a stand-by cluster.

Management Commands supported#

Rondis supports the PING command, the ECHO command and a simple version of CONFIG GET command. Through the SELECT one can select the database to use.

The SELECT command will change the database used. By default it will database 0, in RonDB this will be stored in a database called redis_0. It is possible to have up to 16 databases in Rondis, the number of databases an instance can use is part of the configuration of the REST API server.

Retrieval commands#

GET command#

The GET command is very simple, in Rondis it will be a simple key lookup unless the row is large in which case we will read through a set of key lookups. We will ensure that a single command is not overloading the network if the row is very large.

HGET command#

Commands with H are using the hash implementation. This actually stores the rows in the same tables as the string implementation. However before accessing those tables it will map the hash key to a hash key id. The string implementation will set hash key id to 0. This makes it easy to also scan only string rows or a specific hash key even though they are stored in the same table.

After mapping the hash key, the implementation of HGET and GET are the same.

MGET command#

MGET issues a set of simple key lookups. Each of those will execute in its own transaction context, so the behaviour is the same as sending a number of parallel GET commands.

HMGET command#

Same behaviour as MGET except for the mapping of the hash key to a hash key id.

STRLEN command#

This is always a very simple key lookup in the string_keys where the length of the row is stored in a column.

GETRANGE#

This will only report back a subset of the value. So very similar in execution to the GET command.

Updating commands#

SET command#

The SET command has many options. Rondis supports all these options that are mostly related to the Time To Live (TTL) behaviour. Rondis implements TTL behaviour using the RonDB TTL Service.

The execution of the SET command is transactional, thus either the full row is stored in RonDB or no part of it.

MSET command#

The MSET command is currently only supporting the RonDB mode. This mode is compatible with the Redis protocol but not with the behaviour. Each key is handled in a separate transaction, thus the result of the command when failed could be that some rows have been successfully written and others not. Compatible modes of this command will be implemented later.

HSET command#

Same as MSET command with hash key mapping.

HMSET command#

Same as HSET command.

DEL command#

The DEL command will delete keys in separate transactions. The command will return the number of successful deletions.

HDEL command#

Same as DEL command with hash key mapping.

SETRANGE command#

The SETRANGE has some complex conditions, but it is working on a single key and within a single transaction, so it behaves according to the expected behaviour.

Increment commands#

Increment commands are implemented using interpreter instructions in Rondis. There is a configuration parameter affecting the behaviour of these commands. It is called FastHCOUNT. If this is true the increment commands will be executed using dirty writes. A dirty write will commit in the prepare phase. Thus in a crash scenario there might be a discrepancy between the replicas in RonDB, this discrepancy will however be quickly repaired after recovery. Thus one should not set this to true if consistency is of high importance. Setting this parameter is mainly interesting when one sends thousands of increment commands to the same row every second. Using dirty writes means that one can handle hundreds of thousands of increments per second on a single key.

INCR command#

Simple key lookup that increments the value by 1.

HINCR command#

Same as INCR with hash key mapping.

This command actually doesn’t exist in Redis, it can be implemented using HINCRBY using argument 1. The command is supported in Rondis.

DECR command#

Simple key lookup that decrements the value by 1.

HDECR command#

Same as HDECR with hash key mapping.

This command actually doesn’t exist in Redis, it can be implemented using HINCRBY using argument -1. The command is supported in Rondis.

INCRBY command#

Simple key lookup that increments the value by argument in INCRBY command.

HINCRBY command#

Same as INCRBY with hash key mapping.

DECRBY command#

Simple key lookup that decrements the value by argument in INCRBY command.

HDECRBY command#

Same as DECRBY with hash key mapping.

This command actually doesn’t exist in Redis, it can be implemented using HINCRBY using negative argument. The command is supported in Rondis.

Sharing RonDB cluster between Rondis and other applications#

It is fairly easy to load RonDB from Rondis given that the Redis protocol is such a light-weight protocol.

RonDB 24.10 adds a new feature that makes it possible to limit the rate of operations for a database. This could be applied on a Rondis database. One can also set the maximum memory and disk usage and maximum size of a transaction and maximum number of concurrent transactions.

This makes it possible to colocate a high-performance Rondis installation with other high-performance applications.