【数据库评测报告】MyRocks VS MySQL57

导语

facebook 开源了他们的 Zstandard 压缩算法和 MyRocks 存储引擎,ZSTD 压缩算法志在取代当前普遍使用的的 zlib 压缩技术,而MyRocks 是基于 rocksdb 引擎嵌入到 MySQL5.6的一个分支,在 facebook 内部用作提升存储效率。那么,这个整合后的引擎性能如何呢,本周OMG-DBA 团队第一时间进行了调研。

一、MyRocks和MySQL的关系

MySQL是一个当前使用最广泛、且支持插件式存储引擎的开源数据库。我们常用的MySQL引擎有:InnoDB、MyISAM等;而MyRocks是 facebook 将他们自己的修改后的RocksDB引擎嵌入到MySQL56中实现的。

MyRocks基于RocksDB引擎,不同于基于B+tree组织方式的InnoDB引擎,RocksDB是基于LSM方式组织数据的,这种append only的写入方式,很少出现随机io的情况,是在内存merge之后才写入,写入放大较小;在压缩方面,MySQL5.7之后实现了透明页压缩技术,压缩之后的页对齐会导致压缩效率降低,虽然MyRocks也是页压缩,但不用页对齐(存储的SST文件需要与操作系统对齐,但因SST size是2M,和InnoDB的单页16k相比,这里的SST文件级别对齐对压缩效率的影响可忽略不计),除此之外,MyRocks还在索引层面实现了2点来减少存储开销:Prefix Key Encoding 技术(索引中前缀相同的不重复存储)和 Zero-filling row metadata 技术(压缩索引中额外表示的seqid)。

因此,MyRocks整体上被描述为一个写入性能、存储效率均优于InnoDB的新引擎。但具体性能如何,下面我们一探究竟。

二、性能测试部分

本文主要分3个方面进行对比:1.写入性能;2读取性能;3.压缩性能;

说明:因MyROCKS为facebook内部使用的分支版本,外部公开资源较少,因此本次测试上有如下几方面的局限:

1、最新的ZSTD压缩算法,可以编译进MyROCKS中,但不能通过DDL指定压缩算法使用,因此MyROCKS的压缩只能针对原生的ZLIB压缩算法做测试。

3、MySQL57版本,同时支持传统表压缩技术和透明页压缩技术,但透明页压缩技术依赖于内核版本和文件系统的稀疏文件特性和打孔技术,当前测试机环境不能满足,因此MySQL57的压缩只能针对透明表压缩技术进行测试。

(一)、写入性能对比

样本表配置:57不开启压缩、57开启zlib压缩(压缩级别为最严格的第9级,relog刷盘参数设置为0)、rocks不开启压缩、rocks开启zlib压缩(压缩级别为默认设置)

结果图示:横轴为测试的并发数,纵轴为往4类样本表中写入sql的平响

  • MySQL57开启表压缩后对写入性能损耗较大;1000并发时,与不开压缩相比,写入性能差别在500倍(因压缩和并发线程争抢综合因素)
  • MyROCKS开启压缩前后对写入性能差别较小
  • 并发对MyROCKS的读取影响大于MySQL57
  • 当并发低于50时候,MyROCKS写入性能略优于MySQL57
  • 随着并发增大,MyROCKS写入性能损耗严重
  • 较高并发下(并发大于50),MyROCKS写入性能远不及MySQL57

(二)、读取性能对比:

样本配置:57不开启压缩、57开启zlib压缩(压缩级别为最严格的第9级,relog刷盘参数设置为0)、rocks不开启压缩、rocks开启zlib压缩(压缩级别为默认设置)

结果图示:横轴为测试的并发数,纵轴为往4类样本表中查询sql的平响

  • MySQL57开启表压缩后对读取性能影响也比较大;1000并发时,与不开压缩相比,写入性能差别在30倍
  • MySQL57开启表压缩,对读写性能损耗均比较大;且对写入性能的影响远大于读取性能
  • MyROCKS开启压缩前后对读取性能差别较小
  • 并发对MyROCKS的读取影响大于MySQL57
  • 当并发低于200时,MyROCKS的读取性能优于MySQL57;
  • 随着并发增大,MyROCKS读取性能也损耗严重
  • 高并发下(并发大于200),MyROCKS读取性能也远不及MySQL57

(三)、数据空间对比方面:

样本配置:57开启zlib压缩(压缩级别为最严格的第9级,relog刷盘参数设置为0)、rocks开启zlib压缩(key_block_size设置为4k)、rocks开启zlib压缩(key_block_size设置为16k)

结果图示:横轴为导入的数据量,纵轴为数据磁盘占有量(单位为MB)

说明:因为MySQL57支持的透明页压缩算法依赖于hole punching技术和稀疏文件技术,而当前系统内核过低,因此本次只针对MyRocks和MySQL57的表压缩性能做测试。

  • MySQL57压缩效果较好,压缩前后磁盘占有量比例约1:2.6,即压缩后能减少60%的存储
  • MyROCKS默认ZLIB压缩效果较差。几乎和不开启压缩时磁盘占用量相当(怀疑是测试环境问题,这点待确认)
  • MyROCKS在不开启压缩时,存储成本高于MySQL57
  • 随着单表数据量增大,在不开压缩时,MyROCKS的存储成本增长速率高于MySQL57

三、测试总结:

通过第二部分的测试和分析,我们得出如下结论:

  • MySQL57的表压缩技术,对读写的性能损耗都比较大
  • MySQL57的表压缩技术,能降低约60%的磁盘存储
  • MyROCKS在高并发下的表现,并没有预期的那么强劲,尤其是在200并发以后,写入和读取性能均下降明显
  • MyROCKS不开启压缩时候,存储成本高于MySQL57

基于如上测试结论,我们建议:

  • MySQL57的表压缩技术适用于对读写要求不高,但对磁盘利用率要求搞的场景
  • MyROCKS在不开启压缩时,若出现单表数据量大于5G,无论从存储上还是读写性能,均不如选择MySQL57
  • MyROCKS的默认ZLIB压缩效果,与预期差距很大,暂不做建议。

四、其他测试细节步骤:

1、软硬件配置:

描述

详细参数

硬件

TS90机型: 2个12核CPU256G内存12*800G SSD万兆网卡

软件-数据库1

MyRocks(基于MySQL5.6)

[mysqld]basedir=/data/webroot/myrocksandmysql57/myrocksdatadir=/data/webroot/myrocksandmysql57/myrocks/var/port=3701socket =/data/webroot/myrocksandmysql57/myrocks/tmp/mysql.sockpid-file =/data/webroot/myrocksandmysql57/myrocks/var/mysql.pidmax_connection=10000rocksdbdefault-storage-engine=rocksdbskip-innodbdefault-tmp-storage-engine=MyISAMbinlog_format=ROWcollation-server=latin1_bintransaction-isolation=READ-COMMITTEDrocksdb_max_open_files=-1rocksdb_base_background_compactions=1rocksdb_max_background_compactions=8rocksdb_max_total_wal_size=4Grocksdb_max_background_flushes=4rocksdb_block_size=16384rocksdb_block_cache_size=32Grocksdb_table_cache_numshardbits=6# rate limiterrocksdb_bytes_per_sync=4194304rocksdb_wal_bytes_per_sync=4194304rocksdb_rate_limiter_bytes_per_sec=104857600 #100MB/s# triggering compaction if there are many sequential deletesrocksdb_compaction_sequential_deletes_count_sd=1rocksdb_compaction_sequential_deletes=199999rocksdb_compaction_sequential_deletes_window=200000rocksdb_default_cf_options=write_buffer_size=128m;target_file_size_base=32m;max_bytes_for_level_base=512m;level0_file_num_compaction_trigger=4;level0_slowdown_writes_trigger=10;level0_stop_writes_trigger=15;max_write_buffer_number=4;compression_opts=-14:1:0;block_based_table_factory={cache_index_and_filter_blocks=1;filter_policy=bloomfilter:10:false;whole_key_filtering=0};level_compaction_dynamic_level_bytes=true;optimize_filters_for_hits=true;memtable_prefix_bloom_bits=41943040;memtable_prefix_bloom_probes=6;prefix_extractor=capped:12rocksdb_override_cf_options=cf_link_pk={prefix_extractor=capped:20};rev:cf_link_id1_type={prefix_extractor=capped:20}#ali tunningrocksdb_skip_unique_check=1rocksdb_commit_in_the_middle=1rocksdb_write_disable_wal=1rocksdb_max_background_flushes=40rocksdb_max_background_compactions=40

软件-数据库2

MySQL5.7.13

[mysqld]basedir = /data/webroot/myrocksandmysql57/mysql57datadir = /data/webroot/myrocksandmysql57/mysql57/var/port = 3700 server_id = 110socket = /data/webroot/myrocksandmysql57/mysql57/tmp/mysql.socklog-error = /data/webroot/myrocksandmysql57/mysql57/var/mysql.errinnodb_compression_level=9default-storage-engine=INNODBpid-file = /data/webroot/myrocksandmysql57/mysql57/var/mysql.pidskip-external-lockingkey_buffer_size = 2048Mmax_allowed_packet = 128Mmax_binlog_size=1024Mmax_connect_errors=99999999999sort_buffer_size=8M#thread_stack = 192K#thread_cache_size = 8user = webrootmax_connections = 20000sort_buffer_size = 4Mjoin_buffer_size = 4Mquery_cache_limit = 1Mquery_cache_size = 16Mexpire_logs_days = 10max_binlog_size = 100M innodb_buffer_pool_size=20480Minnodb_thread_concurrency = 8innodb_flush_method = O_DSYNCinnodb_flush_log_at_trx_commit = 0innodb_lock_wait_timeout=50innodb_log_files_in_group = 4innodb_log_file_size = 256Minnodb_log_buffer_size = 32Minnodb_file_per_table = 1innodb_table_locks = 0innodb_read_io_threads=48innodb_write_io_threads=48innodb_thread_concurrency=1000interactive_timeout=86400skip-name-resolveslow_query_log=1enforce_gtid_consistency=ongtid_mode=on#thread_handling=pool-of-threads#thread_pool_size=10# Remove leading # to set options mainly useful for reporting servers.# The server defaults are faster for transactions and fast SELECTs.# Adjust sizes as needed, experiment to find the optimal values.# join_buffer_size = 128M# sort_buffer_size = 2M# read_rnd_buffer_size = 2Msql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO

2、测试工具:

mydbtest是阿里开源的一个数据库压测工具,支持定制化SQL和表结构。

示例配置文件: option name mysql_test loop 25000 user mydbtest/mydbtest@10.62.19.103:3700:mysqlslap declare a int 10 30000 id0 char 1 32 id1 char 1 32 charcol1 char 512 1024 intcol1 int 1 10000000 intcol2 int 1 10000000 intcol3 int 1 10000000 begin insert into tmp_nocompress set id0 = :id0 ,id1 = :id1 , intcol1 = :intcol1 , intcol2 = :intcol2 , intcol3 = :intcol3 ; insert into tmp_lz4compress set id0 = :id0 ,id1 = :id1 , intcol1 = :intcol1 , intcol2 = :intcol2 , intcol3 = :intcol3 ; end

使用方法:./mydbtest_linux64.bin query=conffile degree=200

参考文档

https://github.com/facebook/mysql-5.6/wiki/Build-Steps https://github.com/facebook/mysql-5.6/wiki/MyRocks-advantages-over-InnoDB

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

MySQL删除数据的简单尝试 (r7笔记第98天)

在Oracle里面对于数据清理,如果是非分区表,目前我经常的处理思路是下面三个。 第一种是中规中矩,做好备份,然后开始清理,当然这种情况只是说明数据清理的部分,...

31450
来自专栏数据和云

MySQL 8.0.12 有什么新内容?

今年4月份,MySQL突然直接从8.0.5跳过多个版本号到8.0.11,直接宣布8.0.11 GA,告诉大家说,这个版本已经可以到线上用了。

13610
来自专栏杨建荣的学习笔记

海量数据迁移之传输表空间(一) (r5笔记第71天)

在自己接触的很多的数据迁移工作中,使用外部表在一定程度上达到了系统的预期,对于增量,批量的数据迁移效果还是不错的,但是也不能停步不前,在很多限定的场景中,有很多...

24670
来自专栏杨建荣的学习笔记

一则orabbix报警的分析(r6笔记第65天)

最近使用zabbix监控之后,都会在凌晨收到1台数据库服务器的报警短信,报警的内容为: No data received from Orabbix 这个错误其实...

33880
来自专栏PingCAP的专栏

TiDB 2.1 GA Release Notes

2018 年 11 月 30 日,TiDB 发布 2.1 GA 版。相比 2.0 版本,该版本对系统稳定性、性能、兼容性、易用性做了大量改进。

18700
来自专栏沃趣科技

sysbench的lua小改动导致的性能差异

最近在配合某同事做一项性能压测,发现相同数据量、相同数据库参数、相同sysbench压力、相同数据库版本和sysbench版本、相同服务器硬件环境下,我和同事的...

15930
来自专栏智能大石头

在XCode中如何使用高级查询

对于一个框架来说,仅有基本的CURD不行,NewLife.XCode同时还提供了一个非常宽松的方式来使用高级查询,以满足各种复杂的查询需求。 (本文同样适用于其...

20060
来自专栏数据和云

细致入微:Oracle中执行计划在Shared Pool中的存储位置探秘

这两天我一直在想一个问题,那就是 Oracle 的执行计划到底存储在什么地儿?它会是一种什么样的格式? 这里我试图对这个问题做一点我自己认为的解释,这个解释可能...

32650
来自专栏杨建荣的学习笔记

物化视图刷新结合ADG的尝试 (r8笔记第47天)

最近开发提了几个需求,需要把几个线上的分布式的表整合到统计系统中方便统计,看来分久必合,合久必分,当时的分开考虑,肯定没有想到以后会整合起来,这 可对我们是一些...

398100
来自专栏idba

死锁案例之七

死锁,其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋...

6920

扫码关注云+社区

领取腾讯云代金券