我经常问的一个问题是在什么情况下,我宁愿MyRocks InnoDB。我们已经介绍了MyRocks之前我们的博客:
MyRocks性能- Percona数据库性雷竞技下载官网能的博客
保存在云中MyRocks——Percona数据库性能的博客雷竞技下载官网
但要刷新一些材料。
这一次我想要一个有趣的(真正)的数据集,这也是我前面提过:Reddit评论数据集(见大数据集:所有Reddit评论——分析与ClickHouse Percona数据库性能的博客雷竞技下载官网)。数据集仍然是可供下载http://files.pushshift.io/reddit/submissions/2022年6月,它包括所有最近的评论。
数据集的大小是很有趣,例如,2022年1月的评论118 gb和总大小是2022年上半年数据集729 gb。
有趣也是这个数据集是JSON格式的,现在MySQL提供了广泛的功能直接处理JSON文件。
例如,我们可以直接加载数据集:
mysqlsh(电子邮件保护)/ rs - util importJson /存储/瓦迪姆/ reddit RS_2022-01——表=的tableColumn = doc
为表创建:
创建表大的(医生json默认为空,idint NOT NULL AUTO_INCREMENT,
主键(id)
)
现在我们可以比较时间加载到MyRocks vs InnoDB同样的文件。
值得注意的是,我使用一个快速NVMe MySQL数据库存储,有利于InnoDB (InnoDB性能更好的快速存储,看到保存在云中MyRocks——Percona数据库性能的博客雷竞技下载官网)。
所以六个文件加载到MyRocks存储引擎:
处理124.26 GB 32091070文件1小时45分钟4.8562秒(5.09 k / s文件)
处理116.83 GB 29843162文件1小时40分钟45.0204秒(4.94 k / s文件)
处理128.81 GB 32677372文件1小时54分钟16.1496秒(4.77 k / s文件)
处理130.34 GB 33002461文件中1小时56分钟43.0586秒(4.71 k / s文件)
142.88 GB 34838318文件中处理2小时1分钟22.7340秒(4.78 k / s文件)
处理139.09 GB 34395243文件2小时4分钟49.8066秒(4.59 k / s文件)
最后在MyRocks大小238克。MyRocks使用混合LZ4 + Zstandard压缩来实现这种规模(小于原始数据集)。
相同的InnoDB存储引擎:
处理124.26 GB 32091070文件在2小时17分33.0404秒(3.89 k / s文件)
处理116.83 GB 29843162文件中2小时8分钟6.3595秒(3.88 k / s文件)
处理128.81 GB 32677372文件在2小时28分8.5292秒(3.68 k / s文件)
处理130.34 GB 33002461文件中2小时31分钟25.8357秒(3.63 k / s文件)
142.88 GB 34838318文件中处理2小时44分钟56.9327秒(3.52 k / s文件)
处理139.09 GB 34395243文件中2小时39分钟53.3889秒(3.59 k / s文件)
InnoDB的最后的大小991克。
注意:InnoDB不使用压缩在这个测试。虽然InnoDB引擎压缩功能,这不是我们通常推荐使用由于不同的问题。
MyRock平均插入在4.81 k的文件/秒,InnoDB 3.7 k文件/秒,所以有24%的增益在加载速度比较MyRocks InnoDB。
现在让我们来比较一下一些聚合查询,好处在MySQL显示我们如何处理JSON文档。
找到subreddits顶部(注释)的数量不标记为“成人只”(我没有风险包括“成人”subreddits输出…):
选择文件- >“.subreddit美元”,count(*)从大的问JSON_VALUE(医生,”美元。over_18”返回无符号)是不正确的组由1顺序问DESC限制100;
输出的第一行:
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
| doc - > " $。cnt subreddit”| |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
| | 329683 |“AskReddit”
| | 131401 |“青少年”
| | 102118 |“模因”
| | 82080 |“AutoNewspaper”
| | 66883 |“relationship_advice”
| | 64958 |“UltraAlgo”
| | 54697 |“antiwork”
| | 52531 |“NoStupidQuestions”
| | 48647 |“NFTsMarketplace”
| | 46817 |“CryptoCurrency”
和执行时间:
MyRocks:100行集(6分20.31秒)
InnoDB:100行集(8分10.29秒)
MyRocks不好的部分
充分披露:我也想展示MyRocks执行比InnoDB的一部分。为此,我将使用查询提取作者的评论。
我们需要创建一个索引,“作者”,因为这是所有存储在一个JSON文档,我们需要创建一个虚拟列“作者”:
改变表的添加列作者VARCHAR(255)生成总是像(doc - > " $。作者”);
和InnoDB这实际上是一个即时操作:
查询好,0行影响(1分22.61秒)
而对于MyRocks需要时间:
查询好了,61934232行影响(45分钟46.61秒)
所不同的是,MyRocks不支持任何“即时”DDL操作,而InnoDB。然而,我们看到,到底是“即时”操作造成重大错误和不兼容性InnoDB版本8.0.29和8.0.30(见雷竞技下载官网Percona XtraBackup 8.0.29和即时添加/删除列——Percona数据库性能的博客)所以我之前会要求额外的谨慎在InnoDB使用“即时”操作。
现在我们可以创建虚拟列上的索引:
MyRocks:
改变表的添加键(作者);
查询好,0行影响(14分37.34秒)
InnoDB:
改变表的添加键(作者);
查询好,0行影响(40分钟4.39秒)
MyRocks花了更少的时间创建一个新的索引列。说明MyRocks更糟糕的是,我将使用MySQL的穷人基准,即基准命令,如:
选择基准(50000000,(与t1(与q(选择地板兰德()* (1 + (7685162 1 + 1)c1)从作者选择*,问id = q.c1) SELECT count(*)从大的问,t1 stor.author = t1。作者限制100));
基本上,我将执行50 mln乘以一个查询从一个随机提取的评论作者。
为InnoDB执行时间(越少越好,三个不同):
1行组(2分钟14.66秒)
1行集(1分钟53.10秒)
1行集(1分钟40.18秒)
为MyRocks:
1行组(6分38.60秒)
1行集(5分钟42.83秒)
1行组(6分4.76秒)
理智的看待这个问题,因为InnoDB它导致442 k /秒的查询,和查询MyRocks 137 k /秒(压缩和write-optimized数据结构发挥作用)。我们需要强调这些结果没有网络通信。在正常情况下,会有网络延迟和两个引擎的区别将会少很多。
结论
MyRocks使一个好的用例为一个大数据集(在我们的测试我们加载¾结核病数据集)提供一个好的插入率和小压缩大小的最终产品。
压缩的缺点和write-optimized引擎,MyRocks InnoDB后面快速“索引查询”查询,这在我看来是可以接受的,但你应该评估这个用法。
附录:
硬件规格和配置:
