The main focus of a previous blog post was the performance of MyRocks when using fast SSD devices. However, I figured that MyRocks would be beneficial for use in cloud workloads, where storage is either slow or expensive.
In that earlier post, we demonstrated the benefits of MyRocks, especially for heavy IO workloads. Meanwhile, Mark wrote in his blog that the CPU overhead in MyRocks might be significant for CPU-bound workloads, but this should not be the issue for IO-bound workloads.
In the cloud the cost of resources is a major consideration. Let’s review the annual cost for the processing and storage resources.
|Resource cost/year, $||IO cost $/year||Total $/year|
|1TB io1 5000 IOPS||1500||3900||5400|
|1TB io1 10000 IOPS||1500||7800||9300|
|1TB io1 15000 IOPS||1500||11700||13200|
|1TB io1 20000 IOPS||1500||15600||17100|
|1TB io1 30000 IOPS||1500||23400||24900|
|3.4TB GP2 (10000 IOPS)||4800||4800|
The server version is Percona Server 5.7.22
For instances, I used c5.9xlarge instances. The reason for c5 was that it provides high performance Nitro virtualization: Brendan Gregg describes this in his blog post. The rationale for 9xlarge instances was to be able to utilize io1 volumes with a 30000 IOPS throughput – smaller instances will cap io1 throughput at a lower level.
I also used huge gp2 volumes: 3400GB, as this volume provides guaranteed 10000 IOPS even if we do not use io1 volumes. This is a cheaper alternative to io1 volumes to achieve 10000 IOPS.
For the workload I used sysbench-tpcc 5000W (50 tables * 100W), which for InnoDB gave about 471GB in storage used space.
For the cache I used 27GB and 54G buffer size, so the workload is IO-heavy.
I wanted to compare how InnoDB and RocksDB performed under this scenario.
If you are curious I prepared my terraform+ansible deployment files here: https://github.com/vadimtk/terraform-ansible-percona
Before jumping to the results, I should note that for MyRocks I used LZ4 compression for all levels, which in its final size is 91GB. That is five times less than InnoDB size. This alone provides operational benefits—for example to copy InnoDB files (471GB) from a backup volume takes longer than 1 hour, while it is much faster (five times) for MyRocks.
The benchmark results
So let’s review the results.
Or presenting average throughput in a tabular form:
We can see that MyRocks outperformed InnoDB in every single combination, but it is also important to note the following:
MyRocks on io1 5000 IOPS showed the performance that InnoDB showed in io1 15000 IOPS.
That means that InnoDB requires three times more in storage throughput. If we take a look at the storage cost, it corresponds to three times more expensive storage. Given that MyRocks requires less storage, it is possible to save even more on storage capacity.
On the most economical storage (3400GB gp2, which will provide 10000 IOPS) MyRocks showed 4.7 times better throughput.
For the 30000 IOPS storage, MyRocks was still better by 2.45 times.
Such variance might be problematic for workloads that require stable throughput and where periodical slowdowns are unacceptable.
MyRocks is suitable and beneficial not only for fast SSD, but also for cloud deployments. By requiring less IOPS, MyRocks can provide better performance and save on the storage costs.
However, before evaluating MyRocks, make sure that your workload is IO-bound i.e. the working set is much bigger than available memory. For CPU-intensive workloads (where the working set fits into memory), MyRocks will be less beneficial or even perform worse than InnoDB (as described in the blog post A Look at MyRocks Performance)