Saving With MyRocks in The Cloud资料
本文为去找网小编(www.7zhao.net)为您推荐的Saving With MyRocks in The Cloud，希望对您有所帮助，谢谢！
The main focus of aprevious 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 thatearlier post, we demonstrated the benefits of MyRocks, especially for heavy IO workloads. Meanwhile, Mark 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 server version is Percona Server 5.7.22
For instances, I used instances. The reason for c5 was that it provides high performance Nitro virtualization: Brendan Gregg describes this in his . 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:
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:
cachesize IOPS engine avg TPS 27 5000 innodb 132.66 27 5000 rocksdb 481.03 27 10000 innodb 285.93 27 10000 rocksdb 1224.14 27 10000gp2 innodb 227.19 27 10000gp2 rocksdb 1268.89 27 15000 innodb 436.04 27 15000 rocksdb 1839.66 27 20000 innodb 584.69 27 20000 rocksdb 2336.94 27 30000 innodb 753.86 27 30000 rocksdb 2508.97 54 5000 innodb 197.51 54 5000 rocksdb 667.63 54 10000 innodb 433.99 54 10000 rocksdb 1600.01 54 10000gp2 innodb 326.12 54 10000gp2 rocksdb 1559.98 54 15000 innodb 661.34 54 15000 rocksdb 2176.83 54 20000 innodb 888.74 54 20000 rocksdb 2506.22 54 30000 innodb 1097.31 54 30000 rocksdb 2690.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:
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 )
以上为Saving With MyRocks in The Cloud文章的全部内容，若您也有好的文章，欢迎与我们分享！