首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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,完成数据恢复操作。

InnoDB存储引擎Doublewrite实现原理

从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。

8个buffer pool instances分配16个doublewrite shards,近32MB

一个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)

2. Centos 7.4 with NVMe driver 1.0, ext4 filesystem

3. Percona MySQL 8.0.15

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

将Innodb parallel double write file放置在DRAM Nanmespace, 性能在64并发下提升35.49%。

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

SSD平均随机读IOPS和随机读带宽提升38.3%;

SSD平均随机写带宽提升37.1%;

SSD平均随机读延迟减少7.4%;

SSD平均随机写延迟减少52.6%。

64线程下两种SSD配置测试结果对比

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

HOST写数据量与NAND写数据量以及写放大对比

在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等新存储介质)的特性,并结合大规模的验证测试。数据库往往是一个企业最为关键的应用,任何数据丢失和不可靠因素都是不能忍受的。

现在这一方案还并不完美,这里我们总结了方案的限制以及下一步优化方向:

1. 由于使用了DRAM NS,所以掉电保护需要更多的电容,但当前DWB MB级别的容量需求对增加电容容量的要求不大;

2. DRAM为易失性介质,并且价格较贵,所以SSD一般使用较小容量的DRAM。可以考虑在SSD中使用PCM等其他非易失性介质代替DRAM, SSD统一管理PCM Namespace和NAND Namespace, 由PCM承载MySQL的ibdata1(含Double Write Buffer File,但需要剔除较大的undo log);

3. 对于不支持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的持续磨合,双方未来的配合将越来越默契。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190522A05RLW00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券