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.