谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf

上传人:哈尼dd 文档编号:3335393 上传时间:2019-08-13 格式:PDF 页数:54 大小:1.12MB
返回 下载 相关 举报
谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf_第1页
第1页 / 共54页
谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf_第2页
第2页 / 共54页
谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf_第3页
第3页 / 共54页
谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf_第4页
第4页 / 共54页
谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf_第5页
第5页 / 共54页
点击查看更多>>
资源描述

《谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf》由会员分享,可在线阅读,更多相关《谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超.pdf(54页珍藏版)》请在三一文库上搜索。

1、谈谈PCIe ssdPCIe ssd在数据库优化中的作用在数据库优化中的作用IIII之颠覆性创新之颠覆性创新 Apr 2015 Shannon Systems 宝存科技 关于摩尔定律关于摩尔定律 由于基于Flash闪存存储设备的出现;处理器,内存和存储设备终于都可 以遵循摩尔定律实现快速的发展. 12 核心核心, 24 线程线程 3.2Ghz DDR4 DRAM2133MHz 768GB 2U 500K IOPS, 9us 延迟延迟 50TB 裸容量裸容量 2U 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 容量 性能 安全性 应用成本 Flash 存储起到的作 用 基于基于Hos

2、tHost的的PCIe FlashPCIe Flash存储的优化与方案存储的优化与方案 超大容量高可用Flash存储(Ultra-capacity and highly available Flash) 原子写(Atomic Write) Redo log 优化(Redo log optimization) 大容量大容量FlashFlash存储存储(Ultra Capacity Flash Storage)(Ultra Capacity Flash Storage) 常规方案: HBA 软RAID 缺点 不支持Flash存储设备的高级特性, 比如Trim, S.M.A.R.T信息等. 性能损耗

3、 容错性差,风险高, 如意外掉电数据安全性问题,连续故障等. 大容量大容量FlashFlash存储存储(Huge Capacity Flash Storage)(Huge Capacity Flash Storage) 轮转式校验数据存储, 最多可有一个SSD故障 由于没有校验数据缓存,数据的随机写入会导致: 在系统层面,写放大系数一定大于2(过大). 更快速的寿命损耗. 会出现”写洞”现象, 影响数据一致性. 6 RAID5RAID5处理随机数据写入的步骤处理随机数据写入的步骤 4K 随机写第一步: 写入待写数据 7 当磁盘当磁盘A被数据填满时被数据填满时,会发生写放大现象会发生写放大现象

4、RAID5RAID5处理随机数据写入的步骤处理随机数据写入的步骤 4K 随机写第二步:读取原校验数据 8 RAID5RAID5处理随机数据写入的步骤处理随机数据写入的步骤 4K 随机写第三步:计算出新的校验数据 9 Random writes in RAIDRandom writes in RAID- -5 5 4K 随机写第四步:更新校验数据 10 大容量大容量FlashFlash存储存储(Huge Capacity Flash Storage)(Huge Capacity Flash Storage) 由于 RMW(read-modify-write), RCW(read-reconstr

5、uct-write) 导致 了物理双写, 使整个Array 的WAF(写放大因子) 远远大于2 在 RMW, RCW 过程中如果系统出现其他故障可导致交验数据更新不成 功, Write Hole(写洞) 现象产生, 带来数据一致性问题. 大容量大容量FlashFlash存储存储(Huge Capacity Flash Storage)(Huge Capacity Flash Storage) 随机写性能不是随着阵列中的磁盘数量线性增长. 12 8 盘 (RAID-5) vs 4 盘 (RAID-5) PCIePCIe- -RAIDRAID PCIePCIe- -RAIDRAID 目的: 满足应

6、用程序的大容量需求 避免单点故障(硬件故障,多发性Flash芯片失效,主控失效等.) 解决传统的RAID5阵列写性能极差的问题 解决传统的闪存盘阵列会有很大的写放大现象. 解决传统SSD硬盘性能稳定性和性能一致性不足的问题 目标目标: : 在系统中提供一个集大容量在系统中提供一个集大容量, ,高性能和高可靠性的逻辑块设备高性能和高可靠性的逻辑块设备. . PCIePCIe- -RAIDRAID 技术关键点: 软件FTL层 跨设备FTL层 基于PBA的RAID 采用2维RAID,以达到最大的保护效果 PCIePCIe- -RAIDRAID Host-Based 将FTL的实现从Flash存储设备

7、中移至主机 统一FTL和RAID层,可以解决传统RAID存在的诸多问题 16 Conventional RAID5 of SSDs The new RAID5 architecture PCIePCIe- -RAIDRAID 2维RAID, 最大化数据保护 Demo PCIePCIe- -RAIDRAID 性能(保守): 4K RW 30W+ IOPS 4K RR 50W+ IOPS 延迟: R:80us / W:15us 冗余度/维护: PCIe RAID 5 允许一个PCIe Flash设备彻底失效. 未来有可能支持RAID10 PCIe 接口支持热备设备, 8639接口支持热插拔,热维护

8、. 综合OP可以最多释放到15%以下,更大的用户空间 PCIePCIe- -RAIDRAID 高密度 2U 服务器, 最多可以部署6张全高的PCI-E 板卡, 如 HP DL380 Gen9 50TB 裸容量, 最高40TB的用户可用容量 3U 服务器, 最多可以部署11张全高的PCI-E 板卡, 如 Supermicro Gen X9DRX+-F 90TB 裸容量, 最高80TB的用户可用容量 PCIePCIe- -RAIDRAID 优势: 大容量,高性能 全局垃圾回收GC和磨损均衡(WL) 基于PBA的RAID 构建实现, RAID5的全局写放大系数远远小于2, 更高的 Flash 寿命

9、避免RMW/RCW 避免传统RAID5所带来的性能损耗. Host-Base 的UniFTL 可以感知校验数据状态,避免”写洞”(WriteHole) 21 原子写原子写(Atomic Write)(Atomic Write) 原子操作: 读/写 Page 和 Buffer. Flash Page: Flash 的原子读取, 写入单位, 多以4K为例, 但是在现 代Flash产品中 实际多为16KB/32KB. InnoDB Page: 是InnoDB 的原子读取,写入单位. 一般为16KB. PCIe Flash Write Buffer(以Direct-IO产品为例): 主控中的SRAM,

10、 3 组,每组32KB. InnoDB Double Write buffer: 主机内存中的空间,用来存储Double Write 数据, 2MB 原子写原子写(Atomic Write)(Atomic Write) 传统硬件和操作系统不能保证 InnoDB Page 写入这一操作的原 子性 InnoDB使用Double write这个特 性来避免InnoDB Page写入不完 整的问题. Double Write 缺点: 数据写入量加倍(Bad For Flash) 增加了写入负载(不是2倍) Double write buffer (2MB) Doublewrite (1MB) Doub

11、lewrite (1MB) 共享表空间 Page Page copy 数据文件 (.ibd) write write recovery 原子写原子写(Atomic Write)(Atomic Write) A nand block InnoDB Page Size: 16KB Flash Page Size: 32KB 对NAND Flash 闪存的页进的行读写操作都是 原子操作. 如果我们确保将每个InnoDB Page 一次性的写 入一个Flash Page(InnoDB Page Size Free Space of Flash Write Buffer 将本组Write Buffer

12、剩余空间用垃圾 数据填充, 新开一组Write Buffer 来 承接这个新的Write Request. Flush on power cut Nand page Write buffer bio bio bio 原子写原子写(Atomic Write)(Atomic Write) 有时连续的写请求会被合并为一个大 BIO(Block IO) Write Request Flash Page Size 32K 数据会不经过Write Buffer被直接写 入一个新的 Flash Page(延迟稍高). Write buffer bio bio 原子写原子写(Atomic Write)(Ato

13、mic Write) 应用原子写的条件 Write Request Size 中定义的结构体. Redo Log Redo Log 优化优化(Redo log optimization)(Redo log optimization) bio 数据结构 struct bio sector_t bi_sector; /* associated sector on disk */ struct bio *bi_next; /* list of requests */ struct block_device *bi_bdev; /* associated block device */ unsigne

14、d long bi_flags; /* status and command flags */unsigned long bi_flags; /* status and command flags */ unsigned long bi_rw; /* read or write? */ unsigned short bi_vcnt; /* number of bio_vecs off */ unsigned short bi_idx; /* current index in bi_io_vec */ unsigned short bi_phys_segments; /* number of s

15、egments after coalescing */ unsigned short bi_hw_segments; /* number of segments after remapping */ unsigned int bi_size; /* I/O count */ unsigned int bi_hw_front_size; /* size of the first mergeable segment */ unsigned int bi_hw_back_size; /* size of the last mergeable segment */ unsigned int bi_ma

16、x_vecs; /* maximum bio_vecs possible */ struct bio_vec *bi_io_vec; /* bio_vec list */ bio_end_io_t *bi_end_io; /* I/O completion method */ atomic_t bi_cnt; /* usage counter */ void *bi_private; /* owner-private method */ bio_destructor_t *bi_destructor; /* destructor method */ ; Redo Log Redo Log 优化

17、优化(Redo log optimization)(Redo log optimization) unsigned long bi_flags; /* status and command flags */ 无符号长整型, 64bit. 约定第16bit 设置为1 来标记redo log 的io 请求 EXT4_PRIO_FL=16, MySQL/InnoDB Flag BIO_RW_PRIO=16, FS/EXT4 Flag Redo Log Redo Log 优化优化(Redo log optimization)(Redo log optimization) Patch MySQL/Inn

18、oDB os_file_create_func os_file_set_nocache 设置redo log 文件为O_DRIECT 判断文件类型, 如果为OS_LOG_FILE 设置Flag, 使用ioctl将Flag交给FS flags = flags | EXT4_PRIO_FL; ioctl(file, EXT2_IOC_SETFLAGS, Redo Log Redo Log 优化优化(Redo log optimization)(Redo log optimization) Patch FS/EXT4 判断MySQL/InnoDB 传下来的flag if (EXT4_I(inode)

19、-i_flags & EXT4_PRIO_FL) 设置Flag 传给Direct-IO Driver bio-bi_flags = bio-bi_flags | (1 bi_flags & (1 100% (In Shannon Systems Lab) NOTE: 如果没有Patch MySQL/InnoDB FS/EXT4 就在Direct-IO Dirver中开启redo log optimize 特性 Direct-IO 产品性能表现会变差, 因为资源一直被预留不被使用. 开启redo log optimize 特性后, 如果直接关闭该特性. 会有非常小的几率引发一个Flash Pag

20、e 的数据一致性问题. Shannon Systems 建议在关闭之后reformat Flash Storage 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 容量 性能 安全性 应用成本 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 容量: 6.4TB/12.8TB 单设备 (大容量) PCIe RAID(超大容量) 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 性能: 原生PCIe Flash 本身具有的超高性能. 原子写(10%) redo log 优化(100%) 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 安全性: 原子写(写入完整

21、性) PCIe RAID(单点,写洞) 掉电数据保护 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 应用成本: Flash Storage 成本优化空间 高密度,大整合比 性能提升带来性价比提升 当谈及数据库应用的存储方案时当谈及数据库应用的存储方案时 容量 性能 安全性 应用成本 Q&A 上海宝存信息科技有限公司上海宝存信息科技有限公司 Shannon Systems 上海市杨浦区大连路588号宝地广场A座305室 Suite 305 Tower A Baoland Plaza 588 Dalian Road Yangpu Shanghai 200082 021-5558-018

22、1 contactshannon- www.shannon- Thanks for your time. FlashFlash存储中的存储中的LBA(LBA(逻辑地址逻辑地址) )与与PBA(PBA( 物理地址物理地址) )动态映射动态映射 传统的RAID控制器会仍然将Flash存储视为普通的传统硬盘. 存储与传统硬盘有着本质的区别,即将LBA动态映射给PBA. 51 在Flash存储中,物理块地址(PBA)是”静态”因素 可以基于”静态”的PBA来构建RAID 将FTL的实现从Flash存储中移至主机中将特别有利于基于PBA的RAID阵 列的构建. 52 存储中的非动态因素存储中的非动态因素 在在FTLFTL层构建层构建RAIDRAID的原理的原理 (1)(1) 初始状态 数字代表LBA 区块代表PBA 53 在在FTLFTL层构建层构建RAIDRAID的原理的原理(2)(2) 后续状态 数字代表LBA 区块代表PBA 54

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/环境 > 装饰装潢


经营许可证编号:宁ICP备18001539号-1