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 
c5.9xlarge 7881   7881
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 scenario

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.

InnoDB versus MyRocks throughput in the cloud

Or presenting average throughput in a tabular form:

cachesizeIOPSengineavg TPS
275000innodb132.66
275000rocksdb481.03
2710000innodb285.93
2710000rocksdb1224.14
2710000gp2innodb227.19
2710000gp2rocksdb1268.89
2715000innodb436.04
2715000rocksdb1839.66
2720000innodb584.69
2720000rocksdb2336.94
2730000innodb753.86
2730000rocksdb2508.97
545000innodb197.51
545000rocksdb667.63
5410000innodb433.99
5410000rocksdb1600.01
5410000gp2innodb326.12
5410000gp2rocksdb1559.98
5415000innodb661.34
5415000rocksdb2176.83
5420000innodb888.74
5420000rocksdb2506.22
5430000innodb1097.31
5430000rocksdb2690.91

 

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.

However it is worth noting that MyRocks showed a greater variance in throughput during the runs. Let’s review the charts with 1 sec resolution for GP2 and io1 30000 IOPS storage:Throughput 1 sec resolution for GP2 and io1 30000 IOPS storage MyROCKS versus InnoDB

Such variance might be problematic for workloads that require stable throughput and where periodical slowdowns are unacceptable.

Conclusion

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).

You May Also Like

Raspberry Pi is cost-effective, has low power consumption and makes a great test machine for developers. Read our blog to learn how to compile Percona Server for MySQL 5.7 in Raspberry Pi 3, in addition to tips on how to improve performance.

Get Up and Running with Percona Server for MySQL outlines a proven entry-level MySQL database architecture that is not only easy to install but includes failover and basic business continuity components. This solution is best suited for on premise environments. Download the solution brief to learn more.

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Mark Callaghan

I might be biased but I love this blog post.

Aliaksei Kandratsenka

Good data. Thanks. Wondering what would happen to performance of rocksdb if data wasn’t as well compressible.

Nils

I wonder what happens when you use multiple EBS volumes, the throughput is capped for EBS (io1 500mb/s, gp2 160mb/s).

Jim Tommaney

Another great benchmark Vadim.

For me, very informative that the core architecture delivers such uplift across wide spectrum of storage systems. The supreme excellence is simplicity.