As a new Oracle employee working in the External Standards and Community Engagement group in the Czech Republic, I was happy to attend the first MySQL User Group meeting happening for after some time of inactivity in Prague. While I am not working directly on the MySQL team, I was interested to learn more about MySQL and MySQL Heatwave. The Prague MySQL User Group held this meeting in the beautiful Oracle Prague office space.
The MySQL User Group topics cover different subjects with a shared common theme – database setup in cloud environment.
The first talk was delivered by Carsten Thalheimer, who works for Oracle as a MySQL Principal Solution Engineer in EMEA. His presentation was titled “MySQL Cloud” and in his presentation he not only provided the information about architecture design behind MySQL Cloud solutions in Oracle, but also showed practical examples, where he demonstrated how the new features, such as MySQL Heatwave Cluster in-memory engine, impact performance in great manner.
But let me start from beginning and ask you this – what are the core principles behind the architecture design and why to even choose cloud as your database solution.
The idea is rather simple and could be summarised by single principle – automation. That means, that if you decide for cloud solution, it comes with full managed automative tools, which take care of your predefined MySQL instances based on your configuration setup.
MySQL HeatWave Cluster
As mentioned, now HeatWave Cluster targets customers, who needs to process large amount of data, or computation-heavy queries and are aiming for best possible performance. This is where HeatWave comes in. Not only it deals with structured data, but is also suitable for hybrid solutions, where you need to process semi-structured data, or in-memory ML.
Picture below depicts mentioned, which could be referred as “MySQL Heatwave Family”
As you can see, “Heatwave family” covers all areas, where customers can adapt HeatWave features progressively, along with existing MySQL database solution, whether on premise or as a cluster.
Architecture
When talking about HeatWave, I will put focus on OLTP features as opposite to OLAP, In-database ML or Lakehouse. To put in perspective overall architecture of Heatwave is depicted in scheme below:
You can see that OLTP is just one part of overall solution, but even in this area provides great benefits.
Features
The features MySQL HeatWave solution offers are:
- Monitoring where you can see which queries take most of the processing time, or simply understand what the overall performance of your cluster is.
- Autopilot indexing which based on your application usage over time decides, whether selected tables, or columns should be indexed, or not.
- High Availability which comes with Zero RPO[link] and minutes RTO[link]. Also 99.9 % availability is guaranteed as standalone MHS.
OLTP
When talking about OLTP, I refer to general query executions and processing. These could be done the standard way, where executions are made against structured data on InnoDB engine server. Or if you host your database on OCI and enable Heatwave Cluster to benefit from it.
The understand, where the performance leverage comes from, I’ll provide you through architecture.
The MySQL Heatwave Cluster consists of single MySQL Leading Node and several HeatWave Node Backends.
In standard setup, application talks to database server via given connector. This can be implemented in various languages using the adequate connector.
For example, MySQL offers support for several languages, ranging from C/C++ connectors, through Java or Perl, etc.
With HeatWave, the application is always connected directly to the MySQL leading node and the MySQL Optimizer will decide, whether to process query the standard way (InnoDB), or if it should offload to the HeatWave Cluster to be computed via vectorised data stored in Rapid secondary storage engine.
Data changes in MySQL are propagated continuously to InnoDB and Rapid in real-time. With this comes some overload, but it is highly efficient with large amount of data, or high-performance demand.
You can see in below example, how this significantly affects resulting query execution time.
On demonstrated query execution, the query was executed on 40GB large database set, and standard OLTP execution time was cut from 404s to 0.8s.
Summary
After the event, there was space for networking, where I personally talked to Carsten, Michal Kuchta, SW Engineer and Roman Vaněrek, DBA team lead, both from Seznam.cz.
I personally look forward to experimenting more with MySQL Heatwave and plan to complete the MySQL Heatwave course and certification from Oracle University. Also my colleagues put together MySQL Shorts YouTube videos, where you can get more insight into MySQL world. For example – this recent one shows you how to create a MySQL HeatWave instance in OCI.
Hopefully, with more events to come, the community will grow, and more developers will be encouraged to share their experience in the MySQL cloud world.
Please, check also this blog post, not only about the Prague event, but also another one, which was held in Bratislava.