zoukankan      html  css  js  c++  java
  • 闪存存储特性以及数据库相关优化思路

    闪存存储特性以及数据库相关优化思路

    http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=402040501&idx=1&sn=f0134db82b630a05c68403fbb93645c0&scene=0#wechat_redirect

    闪存存储当前越来越多的应用于企业级环境,特别是提升数据库性能方面。本次分享主要介绍闪存的特性,闪存的劣势及其解决机制,以及采用闪存存储时数据库的一些优化思路。

    目录

    • 闪存的特性

    • 闪存的劣势及其解决机制

    • 数据库场景测试

    一.闪存的特性

    凡是采用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造成的问题,但是Double write也会带来两个问题,性能惩罚和对SSD的磨损增加。

     

    我们按照上面的场景在我们的闪存卡上进行了测试。

    在安全性层面,只要Metadata Journal+Double write或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年后,性能可能只有原来的一半或者更低,性能波动也会频繁出现。

  • 相关阅读:
    Apache Kylin v3.0.0-alpha 发布
    Apache Kylin在美团点评的应用
    Kylin 架构模块简介
    Kylin 1 背景、历史与使命
    谈MongoDB的应用场景
    Linux 内存Cache和Buffer理解
    Linux 下查看内存使用情况方法总结
    mongodb 集群配置文件
    MongoDB bindIp 与 bindIpAll
    MongoDB 权限认证
  • 原文地址:https://www.cnblogs.com/MYSQLZOUQI/p/5097538.html
Copyright © 2011-2022 走看看