rocksdb环境下NVMe SSD测试结果分享

近年来，经典的关系型数据库仍然占着霸主地位，Memblaze很多研究是针对MySQL等关系型数据库进行的，比如《混合介质的多命名空间管理优化MySQL数据库性能》中提到的混合介质的多命名空间管理，就是一项无需MySQL改动配置便可以在开启Doublewrite的同时降低NVMe SSD写放大，提高性能和寿命的技术。关系型数据库盛行，但是数据库市场也并非一成不变，随着NoSQL，特别是以TiDB为代表的NewSQL数据库的实际应用越来越多。

诞生于Big Data时代的RockDB

互联网是NoSQL应用最多的行业，Facebook、谷歌以及国内的阿里、网易都走在NoSQL研究和应用的前列，而在NoSQL发展之路上，NVMe SSD必不会缺席。以RocksDB为代表的高性能K/V数据库引擎就擅长于挖掘闪存的读写潜力。另一方面，诞生于Big Data时代的RocksDB，也是为远大于内存容量的海量on-disk数据而优化的，这样的设计使其适合考察存储介质的性能。

RocksDB是Facebook公司在2013年基于LevelDB的K/V引擎数据库引擎，受Apache Cassandra 和Apache HBase的启发，以开源的形式发布的。RocksDB着重强调了面向高性能存储介质、multi-core CPU的设计理念；带来了诸如多线程Compaction；低mutex锁以及Column Family等诸多LevelDB中没有的特性。

这篇文章我们就通过几个RocksDB测试来一窥NVMe SSD在NoSQL场景中的性能表现，并对其中涉及到的多队列调用等技术做一个解读。

CPU：AMD 1stGen Zen (aka Naples)
EPYC 7351P 16-Core Processor 2.4GHz with HT
内存：128 GB DDR4-2666 DRAM
数据库：RocksDB 5.8.8
操作系统：CentOS 7.4（gcc 4.8.5 ）
** 对比测试中采用的SSD **
Plaze5 700 series 4TB （U.2形态)
某主流品牌800GB SATA SSD （6Gb/s）

测试第一阶段使用随即写方式对数据库写入500GB数据并获取存储设备性能数据，第二阶段则是8：2的混合随机读写测试。结果展示包括RocksDB自带的db_bench采集的数据库吞吐数据以及iostat的硬盘性能数据。此外，这次测试也采用了RocksDB默认的LeveledCompactionStrategy (LCS) 策略；并关闭了压缩功能。

第一阶段：数据库_随机写(无压缩)

第一阶段测试中，使用随机写的方式对RocksDB写入500 GB数据，总计 5.12亿 K/V item； 我们首先使用了 thread=16的并发压力；并开启了Compaction。
测试结果如下：
SATA: 360.2 MB/s (如下图所示，从 %iowait, avgqu-sz,w_await 都看到了SATA SSD已经饱和的迹象）

NVMe SSD写带宽达到了448.4 MB/s，对于一款NVMe SSD来说，这样的带宽性能并不高，从w_await 和 %util来看，NVMe SSD吞吐能力仍有较大的空间，要进一步提高性能还需要对负载压力及CPU等组件的信息进行综合分析。

在此，所以我们逐渐加码压力， 在threads=28 的条件下，看到了NVMe SSD更高的写吞吐能力数据。（SATA SSD在threads=16时已经触及性能峰值，所以不再执行本轮测试。）

从iostat抓到的四条记录看，写带宽最低值534MB，最高值650MB/s，而从w_await和%util来看，NVMe SSD还有较大的潜力可以挖掘。（相信通过使用新一代或者更高端的AMD的CPU将获得更高的系统性能，在此暂不做深入讨论。）

第二阶段：数据库_8:2 混合随机读写（无压缩）

上一阶段我们已经造完了500GB数据，第二阶段首先使用threads=16的并发压力，对这5.12亿 K/V Item进行混合随机读写测试，并记录该任务的完成时间。

SATA ： 12.673 micros/op 78908 ops/sec ; 完成时间： 112 min
NVMe 3.037 micros/op 329234 ops/sec; 完成时间 ： 26 min

读写混合在生产环境中十分常见， NVMe带来的时间上的节省也因此有极大的现实意义; 越早一刻完成compaction就有越多的Peak IO性能时段可以交付给数据库。
NVMe SSD性能碾压SATA SSD的因素有很多，多队列调用是其中之一。从下面火焰图的结果中也可以清晰的看到NVMe使用了 blk-mq-make-request 多队列调用；而SATA只能调用原有的单队列。SATA只能支持单队列IO操作(generic_make_request)的问题被这个场景鲜明的展示了出来。

NVMe SSD的高并发与多核CPU结合使得系统性能有了质的提升。从RocksDB的角度讲，LSM数据结构在高频read的时候会触发background compaction;特别是RocksDB这样实现了multi-threaded compaction的K/V型数据库来说， NVMe的多队列multi-queue特性很适合这样的场景； 相比之下 单一队列的SATA应付这样的场景就非常的吃力。
接下来还是用iostat看下两个盘的表现。
SATA SSD在测试中的iostat截图

NVMe SSD在测试中的iostat截图

可以看到NVMe SSD的带宽超过了1200 MB/s。（iostat取值有一定的随机性，但是仍能看到NVMe SSD与SATA SSD性能质的差异。）
展望未来，RocksDB6.x系列性能还在持续改善，另一方面基于4.18内核的RHEL8.0也带来了诸多I/O性能的提升，AMD的Zen架构的多NUMA架构也有了很多进展。而这些改变多数更有利于发挥NVMe SSD为代表的高速存储设备的性能优势。未来NoSQL数据库大行其道必然不能缺少这样一个协同前进的生态。