闪存存储当前越来越多的应用于企业级环境, 特别是提升数据库性能方面. 本次分享主要介绍闪存的特性, 闪存的劣势及其解决机制, 以及采用闪存存储时数据库的一些优化思路.
目录
闪存的特性
闪存的劣势及其解决机制
数据库场景测试
一.闪存的特性
凡是采用 Flash Memory 的存储设备, 可以统称为闪存存储. 我们经常谈的固态硬盘(SSD), 可以由 volatile/non-volatile memory 构成, 其实固态硬盘的范畴是大于闪存的, 只是当前的固态硬盘大多数采用闪存介质, 所以很多时候我们默认固态硬盘就是闪存盘.
除了闪存以外, 还有其它多种快速存储技术, 如 DRAM ,NVRAM, MRAM and Spin-Torque(自旋力矩磁阻式随机存取内存), Carbon Nanotube( 碳纳米管 ), Phase Change Memory(相变内存),Memristor ( 忆阻器 )等等.
未来存储设备的创新其实就是存储材料的创新, 这也是国外很多初创的半导体公司一个研发的方向.
从半导体的角度来看, 闪存属于非易失性存储, 但是属于不可靠介质. 因为闪存是采用电子驱动, 因此具有电子元器件所固有的缺陷, 电子泄露, 衰减等等.
决定闪存存储大规模应用的主要因素是量产规模, 稳定性以及经济性.
闪存设备随着使用时间和数据量的增长, 坏块会逐渐增加, 会产生大量的 ECC Error, 这时设备性能和可靠性会大幅度下降, 对应用性能和数据安全带来影响. 闪存产品在使用过程中往往会存在性能衰减和可靠性下降的问题. 这里提醒一下, 如果我们使用闪存产品, 一定要使用工具监控闪存产品的健康状态, 防止老化, 数据丢失.
通过对闪存产品的良好设计和质量控制, 也可以避免性能衰减和可靠性下降的问题, 但是往往会带来成本的增加和性能的下降(相比于直写闪存).
对于企业级应用而言, 稳定是第一位, 其次是易用性, 第三才是性能. 闪存设备的性能相比于应用的需要是足够的.
闪存在企业级以及数据中心的应用, 实际上也是依赖于互联网以及大数据的兴起.
互联网的分布式架构以及多副本保护机制, 消除了集中式存储的瓶颈, 满足了海量用户以及应用的请求, 带来了更高的性能需求. 同时多副本的保护机制, 又解决了闪存作为不可靠介质可能带来的数据存储安全的问题.
但是由于闪存的可靠性问题, 其实互联网客户也是有选择地在特定业务上使用闪存, 并不是在所有业务上都使用闪存设备.
有的时候我们还会发现意外断电后, 闪存设备故障, 这往往是由于电路保护机制不完善或固件 bug 造成的.
二. 闪存的劣势及其解决机制
在使用闪存设备的时候, 我们需要考虑的问题要比使用磁盘多.
当前我们碰到的很多问题是, 相比于 IOPS, 闪存比磁盘性能高上几十甚至上百倍, 但是我们将数据放置到闪存上, 性能提升并没有这么高, 甚至没有提高.
原因是闪存主要解决的是 IO 性能问题, 并且主要随机写的性能, 而顺序读写性能并不如多块磁盘汇聚之后的性能.
Linux 文件系统
以 Linux 为例, Linux ext4 属于日志型文件系统, 为了保护数据安全, 通过 Journal 机制提供一致性保护. 那么我们在部署过程中可以将 Journal 日志放置到闪存上, 可以提升 IO 性能. 因为应用的 IO 操作还是通过 OS 层面完成的, 因此 OS 层面的 IO 性能提升也可以带来应用性能提升.
另外, 操作系统以及应用的 IO 层往往是针对磁盘的特性进行了优化, 这些优化往往不适用于闪存设备, 甚至还有副作用. 例如 OS 层面 IO scheduler 有三种模式, CFQ,Deadline 和 noop, 其中前两种模式是针对磁盘低 IO 特性和物理寻道机制进行优化的, 例如做 IO 合并, 寻道算法等等, 会有默认的等待严实以等到更多的 IO block 进行合并和处理. 对于闪存而言, 是不存在寻道处理的, 因此前两种处理机制反而会造成延时增加. 如果我们在系统中使用了 SSD, 需要将 IO scheduler 调整为 noop 模式.
三. 数据库场景测试
刚才谈到为了保证数据安全, 我们需要在 Linux 采用 Journal 模式, 但是 MySQL 也有 double write 的机制, 我们需要怎么既保证数据安全, 又不会增加过多的机制造成性能下降. 我们在我们的闪存产品上做了这方面的测试.
上面是 mySQL 的写入机制. 当系统意外断电时, 数据库 16K 的页面可能没有完成, 就会出现 partial write, 而 partial write 会造成数据库损坏.
MySQL 的 Double write 就是为了解决 partial write 造成的问题, 但是 DW 也会带来两个问题, 性能惩罚和对 SSD 的磨损增加.
我们按照上面的场景在我们的闪存卡上进行了测试.
在安全性层面, 只要 Metadata Journal+DW 或 Metadata Journal+Data Journal, 都可以保护数据库数据的安全, 也就是意外掉电数据不会损坏, 数据库可以正常启动, 数据不丢失.
但是在 CPU bound 的情况下, 前个组合的性能衰减 (8%) 要小于后面的保护组合 (10%). 如果是在 IO bound 的情况下, 前个组合的性能衰减(10%) 要小于后面的保护组合(34%). 但是 DW 下的数据写入量会比后者增加 23%, 也就是会增加 SSD 的磨损. 这个是我们在应用时需要注意的.
另外, 我们在做 DB2 的测试时也发现几个问题:
闪存存储在非分区表的简单的查询统计条件的查询方面具有明显的优势和性能提升, 性能提升 3 到 4 倍, 但是在分区表的统计和加限制条件的查询方面的性能提升并不明显. 而且对相应的复杂的存储过程的统计计算未能体现出优势. 这可能是由于分区表设计机制主要是面向磁盘性能优化, 在闪存上反而有负面影响.
另外我们在 Oracle 数据库上应用闪存测试时发现, 带子查询的多表关联查询语句的存储过程的调用性能表现很差, 查看 AWR 发现大量的 cache latch, 出现长时间等待, 而在磁盘存储上没有这种情况. 我们分析是由于闪存的性能比磁盘高很多, 造成 cursor 数据量大, 缓存内的 latch 冲突增加. 通过增大 share pool 和将复杂查询处理简化为多个小查询处理可以解决这个问题, 性能也得到明显提升.
Q & A
Q1 : 请问闪存和磁盘的比较中 MTBF 是什么意思?
A1:MTBF(Mean Time Before Failure), 失败前平均工作时间. 闪存其实是没有 MTBF 的概念的, 因为闪存有擦写次数的限制, 数据擦写到一定数量后, 闪存介质就会物理性地损坏, 闪存的寿命是可以通过监控使用状况推算出来的. 而磁盘的损坏其实是概率, 会有 MTBF 指标.
Q2 : 请问在测试 db2 的时候, 是 dpf 环境, 还是单机?
A2: 单机.
Q3:mysql 是基于 xfs 测试的吗?
A3:Mysql 测试时是基于 ext4 的.
Q4: 闪存产品有没有不同的系列, 类似传统的高中低端存储那样的分类?
A4: 闪存也分高中低的, 用于企业级高性能的一般以 PCIe NVMe 卡的形式为主. 其实闪存产品的质量标准还有很多细分, 这里就不细说了.
Q5: 请问能谈谈 Spacex 用的闪存产品吗?
A5:SpaceX 用的是我们嵌入式闪存产品, 和我们企业级闪存采用同样的技术架构和闪存颗粒. 主要用于控制代码存储和运行状态数据存储.
Q6: 请问您有测过云主机的 ssd 吗?
A6 : 云主机的 SSD 基本上都采用 SATA SSD, 当前云计算平台在数据库应用方面还是个弱项. 我们下一步计划在 ceph 分布式存储上进行数据库测试, 这也是尝试在云计算平台上运行关键数据库应用.
Q7: 写放大, 和抖动的问题现在已经改善了很多吧?
A7 : 写放大和抖动问题是考验闪存厂商的一个关键指标, 在产品设计的时候就要考虑. 各家处理的方式都不一样. 我们能做到最大的 WAF 是 6. 而在性能抖动方面自认为处理最好的是我们的产品, 因为性能抖动主要是由垃圾回收处理和磨损平衡处理引起的. 而我们采用的分区擦除算法和三重磨损平衡算法是完全基于对闪存颗粒底层的特性了解和经验积累. 另外 SSD 还有一个很大的问题是性能衰减. 使用 1,2 年后, 性能可能只有原来的一半或者更低, 性能波动也会频繁出现.
来源: http://stor.51cto.com/art/201804/570942.htm