Skip to content

Managed RonDB#

Managed RonDB documentation

In the above link the documentation for how to create a RonDB cluster as part of Hopsworks is presented. It also describes how to reconfigure a RonDB cluster that is a part of Hopsworks.

Create a new RonDB cluster#

In this interface the user is able to decide on the following parameters when creating a new cluster.

  • Number of Data Nodes

  • VM Type for the Data nodes

  • Storage Size for Data nodes

  • Number of MySQL Servers

  • VM Type for the MySQL Servers

  • Storage Size for MySQL Servers

In the Detailed section it is also possible to decide on the following parameters.

  • Number of Replicas

  • Number of API Nodes

  • VM Type of API Nodes

  • Storage Size for API nodes

Setting up RonDB Data nodes#

The number of data nodes must be a multiple of the number of replicas.

The first decision is whether to use 1,2 or 3 replicas. If high availability isn’t required, then 1 replica is sufficient. If high availability is required 2 replicas at least should be choosen.

For the most part the number of data nodes should be equal to the number of replicas. One reason for having more data nodes than replicas is that we need a larger database size than can be accomplished through one set of data nodes.

In a cluster with the same amount of data nodes as replicas the database size is limited by the memory size of the data node VM. The largest standard VM is the r5-metal which can house around 768 GByte of memory. This means that around 650 GBytes of memory is available for in-memory rows and indexes.

RonDB supports storing columns on disk, thus if disk columns are used this size can be even bigger. There are also even bigger VM sizes that we haven’t tried out very much yet. Future versions of Hopsworks will allow creation of a RonDB cluster with support for using disk columns, this version will use RonDB 22.10 as the version which supports variable sized disk columns.

Thus size of the database affect the choice of the number of data nodes. The data nodes of RonDB is the storage layer of Hopsworks. The MySQL Server and in the future REST API servers represent the storage clients of RonDB in Hopsworks.

It is unlikely that the requirement on database processing requires more data nodes. If this is the case one should most likely first verify that the requirement is larger than what can be accomplished with one node group of data nodes.

RonDB data nodes requires around 60% more storage space than the memory size of the VM. In addition it requires around 128 GByte of storage space for REDO logs and UNDO logs. Thus a minimum of 256 GByte is required for a data node. A very large data node VM with 768 GByte of memory would thus require at least 1.25 TByte of storage space.

Setting up RonDB MySQL Servers#

The number of MySQL Servers should be choosen based on the amount of query processing is required towards RonDB. In Sysbench benchmarks we find that we need about twice as many CPUs on the MySQL Servers as we need on the data nodes. If we want high availability we should have at least 2 MySQL Servers.

VMs for MySQL Servers have no more than 32 VCPUs. It is possible to scale to use more MySQL Servers if more VCPUs are needed in the Storage client layer.

Setting up RonDB API VMs#

API nodes can be used to house applications using the native RonDB APIs for C++, Java and JavaScript. An API node can also be used to execute benchmarks from, in this case it should be sufficient with 1 API node which contains at least 25% of the total number of VCPUs found in the MySQL Servers. To enable benchmark tools one should click the button that enables benchmark tools in the Advanced section.

Storage size of MySQL Server and API nodes can normally use the minimum amount possible to set.

One can in Hopsworks choose to colocate DuckDB on the same VM as the MySQL Server, in this case memory size is likely more important since DuckDB will read a lot of data into memory, process a query and deliver a result. Thus when a query is executed it will use all the memory it can get hold of.

Thus this should be considered when selecting the VM for the MySQL Server VM.

Online Reconfiguration of RonDB#

The above section describes how to set up the RonDB cluster when creating it. It is possible to reconfigure the cluster as an online operation. This means that you can increase the number of MySQL Servers, decrease the number of MySQL Servers. One can also resize the MySQL Servers to be smaller or to be bigger.

For RonDB Data nodes one can change the number of replicas both upwards and downwards. It is also possible to reconfigure the RonDB Data node VMs to larger VMs.

Scaling the Storage Client Layer#

Being able to scale the Storage Client Layer (the MySQL Server VMs) is very useful and could be used on a daily basis or even several times per day to adjust to business needs. Thus in the busy hours of the day one can allocate more and larger VMs to the Storage Client layer. At night it could be enough to have smaller VMs for the MySQL Server VMs and possibly even fewer VMs as an example.

Resizing the Storage Client layer is an online operation that is completed within a few minutes. During this time all operations towards RonDB continues without interruption. A few queries might get temporary errors due to MySQL Servers shutting down, thus applications should be written such that those temporary errors lead to retries. These retries should be immediately successful.

One strategy to more or less avoid any temporary errors as well is to close connection and reconnect regularly (e.g. at 5 seconds intervals). The new connection will avoid using any MySQL Server in the process of being stopped. Thus most temporary errors can be avoided with this strategy in the application.

MySQL Servers in RonDB are pure clients. They do not contain any persistent data. Thus they only need memory to handle ongoing queries. This means that they would not need more than 16 GByte of memory and even 4-8 GByte of memory will mostly suffice. Thus normally one should choose the VMs with high number of CPUs and small amount of memory. As mentioned previously, using DuckDB in those VMs will change these considerations.

To scale the Storage Client layer is easy, one simply sets the new number of VMs, the VM type to use in those VMs and if necessary also sets the storage space for the VMs. After that one submits the operation and a few minutes later the RonDB cluster runs with the new configuration.

Scaling the Storage Layer#

The Storage Layer (the RonDB Data nodes) is also important to be able to scale. However it is important to consider that RonDB has the database stored in memory. Thus decreasing the VM size to use VMs with smaller amount of memory is currently not allowed to ensure that the new configuration can still maintain the databases stored in RonDB. Scaling to smaller number of CPUs and larger number of CPUs is allowed. Scaling to VMs with a larger memory is allowed as well.

The number of replicas can be scaled both upwards and downwards as online operations.

It is likely that reconfiguration of the Storage Layer is an activity that happens when business needs require a larger database and more compute power in the storage layer.

To scale the Storage Layer is a fully online operation, thus at most operations will be required to handle a few temporary errors. The RonDB software attempts to avoid also temporary errors during a graceful shutdown of a RonDB Data node. When starting up a new RonDB Data node rare events can cause temporary errors. Thus applications written for RonDB should retry operations after temporary errors to ensure smooth operations of the applications.

To reconfigure the Storage Layer one first changes the VM type, the number of replicas and possibly also the storage space. After changing those parameters one submits the reconfiguration.

The reconfiguration of the Storage Layer will be a bit longer operation since it will require an online start up of new VMs. Currently those use initial starts of the RonDB Data nodes and thus data has to be shipped from live RonDB Data nodes. Thus the time it takes to reconfigure is dependent on the size of databases in the RonDB Data nodes.