MySQL数据库场景下的NVMe SSD应用与优化

在DB-Engines Ranking的榜单上，Oracle、MySQL和SQL Server前三的地位仍是不可撼动的。作为一家专注于NVMe SSD设计研发的厂商，Memblaze关注的是NVMe SSD在数据库中的应用及系统优化。近日召开的DTCC2019上，Memblaze产品部朱磊的演讲就围绕着MySQL的Doublewrite原理以及PBlaze5的优化方案展开。

成为系统瓶颈的Doublewrite buffer

关系型数据库将原子性、一致性、隔离性和持久性（ACID）作为事务的四大基本属性，数据库日志、存储引擎等等核心组件的设计都围绕着事务的四个基本属性展开，Doublewrite就是为了保障掉电等极端情况下数据一致性的。

MySQL的InnoDB的page size一般是16KB，其数据校验也是针对这16KB来计算的，MySQL数据库通常使用O_DIRECT方式绕过文件系统cache直接写后端NVMe SSD。所以MySQL将16KB IO通过NVMe Driver发送到NVMe SSD，但是NVMe SSD在处理16KB IO时可能根据各个SSD Vendor的算法会并发拆分为4个4KB IO处理。当系统意外掉电会破坏这一操作的原子性，会有IO没有写完而造成的partial page write（部分页写入）风险。

当开启Doublewrite buffer，MySQL会将内存中Doublewrite buffer的数据先写到共享表空间中，然后再写到磁盘上的数据文件。当系统掉电时，即使数据库的一个page没有完整的写入磁盘，InnoDB也可以从共享表空间的doublewrite space中找到该页的一个最近的副本，将其复制到数据page，再应用redo log，完成数据恢复操作。

从Doublewrite原理可以直观的发现这一技术带来了近2倍的写操作，以此降低数据不一致的风险，但也会降低系统性能，另一方面，传统的doublewrite buffer被所有buffer pool instances和flusher threads所共享，这也会导致的性能瓶颈问题。
但是由于磁盘性能低，所以基于磁盘的数据库系统对于Doublewrite buffer带来的性能下降并不敏感，而且磁盘寿命也不会因此受到严重影响。但对于SSD而言，这个延迟造成的系统性能瓶颈效应十分明显，并且会降低SSD的使用寿命，Memblaze给出了相应的解决方案。本文接下来就会重点以Percona数据库场景为例解读Memblaze的混合介质的多命名空间管理技术。

混合介质的多命名空间管理

多命名空间是NVMe SSD一项基础而重要的技术，双端口等功能都高阶功能都需要基于多命名空间实现。在DTCC2019大会上，朱磊介绍了Memblaze的混合介质的多命名空间管理解决方案，通过拓展多命名空间（Multi-namespace）的功能，NVMe SSD可以实现对 DRAM/NAND 等不同存储介质的统一管理。如此便可将将MySQL的共享表空间放置在SSD内速度较高的内存（或者其他高寿命高性能的介质）中，而数据文件（.ibd）还仍然存在NAND上。而两个区域通过不同的namespace进行隔离。
具体实现如下图。

（可以将Doublewrite space或者整个ibdata1放在高寿命高性能介质中，建议UNDO SPACE从ibdata1中分离出来单独存储在NAND NS空间）

当前DRAM介质Namespace和NAND介质Namespace被SSD统一的FTL管理,同样提供Block接口给Host端, 这个方案最大程度了简化了应用对DRAM Namespace的使用,方便用户对不同应用使用不同介质的Namespace。

Percona：改良后的Doublewrite buffer技术

在验证测试之前，需要介绍一下MySQL数据库发行版Percona对传统Doublewrite buffer进行改良形成的Parallel Doublewrite Buffer。Percona给每一个buffer pool instance私有的doublewrite buffers，1个buffer pool instances会分配2个 doublewrite shards, 每个shards近1MB。

一个flusher线程只能访问一个shard，shard完成flush是独立的,这样消除了锁,并且可以并发的flush,此时瓶颈只在于异步IO完成的速度。Percona Doublewrite space已经被单独分离为一个文件(非tablespace)，这个文件包含所有buffer pool instances对应的shards，每个shards有不同的offsets。
在下一步的测试中也会基于Percona的Parallel Doublewrite Buffer进行配置。

TPCC测试验证混合介质管理方案的收益

在我们的验证测试中，共创建了了28000个数据仓库（对应测试数据量为3TB），并分别获取4、8、16、32、64个并发进程下的结果。
测试环境及基本配置

Server：PowerEdge R730xd
CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 8 Cores * 2
Memory: DDR4 96GB
Memblaze PBlaze5 910 NVMe SSDs:SSD配置1：3.84TB U.2 SSD with 3.84TB namespace * 1 (nvme0n1)
（Percona配置1：datadir=/data1, innodb_doublewrite=on, innodb_parallel_doublewrite_path=/data1/xb_doublewrite）SSD配置2：3.84TB U.2 SSD with 3.80TB namespace * 1 (nvme3n1) and 64MB DRAM Namespace *1 (nvme3n2)
（Percona配置2：datadir=/data1, innodb_doublewrite=on, innodb_parallel_doublewrite_path=/DWB/doublewrite.file）- Centos 7.4 with NVMe driver 1.0, ext4 filesystem- Percona MySQL 8.0.15

从环境配置信息可以看到，测试使用了两块PBlaze5 910 NVMe SSD，其中一块有1个namespace，另一块有两个namespace（其中一个是64MB的DRAM），Percona的配置也与SSD配置匹配起来。与预期一样，当Doublewrite被放在DRAM的命名空间上时，系统性能得到了提升、同时NAND的数据写入量有了大幅下降。下面是测试结果的展示和解读。

我们进一步得到了SSD性能提升的数据。如下：

SSD平均随机读IOPS和随机读带宽提升38.3%;
SSD平均随机写带宽提升37.1%;
SSD平均随机写带宽提升37.1%;
SSD平均随机写延迟减少52.6%。

不仅性能提升效果明显，NAND的数据写入量也得到了30%的降低，写放大直降46%。这对于NVMe SSD的寿命和性能都是一个好消息。

在Memblaze的这一混合介质的多命名空间管理的方案中，DRAM介质Namespace和NAND介质Namespace被SSD统一的FTL管理,同样提供Block接口给Host端, 这个方案最大程度了简化了应用对DRAM Namespace的使用，方便用户对不同应用使用不同介质的Namespace。

总结

当前Memblaze PBlaze5系列产品NAND Namespace的写性能在小压力下已经优化到近DRAM的性能，但是在大压力下NAND介质的性能瓶颈开始凸显。DRAM Namespace可以解决NAND Namespace的性能瓶颈，所以在大压力下TPCC MySQL将double write file放在DRAM Namespace后的性能表现极大的优化了。
就其方案实现而言，对不同介质的管理以及保证SSD的可靠性是难点。需要深入理解DRAM、NAND（未来还会有PCM等新存储介质）的特性，并结合大规模的验证测试。数据库往往是一个企业最为关键的应用，任何数据丢失和不可靠因素都是不能忍受的。
现在这一方案还并不完美，这里我们总结了方案的限制以及下一步优化方向：

由于使用了DRAM NS，所以掉电保护需要更多的电容，但当前DWB MB级别的容量需求对增加电容容量的要求不大；
DRAM为易失性介质，并且价格较贵，所以SSD一般使用较小容量的DRAM。可以考虑在SSD中使用PCM等其他非易失性介质代替DRAM, SSD统一管理PCM Namespace和NAND Namespace, 由PCM承载MySQL的ibdata1(含Double Write Buffer File,但需要剔除较大的undo log)；
对于不支持innodb_parallel_doublewrite_path设置的MySQL,需要设置datadir、innodb_log_group_home_dir、innodb_undo_directory、log_bin等目录在NAND Namespace，而放置ibdata1在DRAM或者 PCM Namespace。
关系型数据库历经数十年发展演进，已经有非常成熟的技术保障数据一致性和系统可靠性，Doublewrite buffer就是其中的代表。NVMe SSD作为新一代主流的高性能存储设备，正处于快速普及的阶段，应当针对数据库的读写机制进行深入研究，给出相应的解决方案，而非改变数据库本身的运转机制。另一方面，数据库还在不断发展，随着数据库与NVMe SSD的持续磨合，双方未来的配合将越来越默契。