闪存在这几年存储领域发展非常快，应用也越来越广泛，如何能更好的使用闪存，本次分享讲一些闪存相关的优化和应用。
-
数据库
-
NoSQL
-
分布式存储
-
CDN
-
公有云存储
综合上面几种场景看，闪存主要适合有比较高的随机IO需求和带宽需求的场景。场景选择上，也是要发挥闪存的长处。目前上面业务中 未来几年发展比较快的会是在公有云存储这一部分。下图就是某厂商云盘对比，可以看到闪存的价格已经很接近机械硬盘了，而单从每IOPS成本看，性价比会更高。
闪存概述
固态硬盘，不过可以从广义理解，从2010年开始在互联网行业大规模应用，性能和稳定性已经得到大规模集群线上验证，应用场景已经非常广泛。当然闪存的IOPS比传统机械硬盘高几个数量级，但是更核心的还是在延迟降低上，优势更大。
上图就很好的说明了，闪存在访问延迟上的提升。
提到闪存，不得不提到闪存里非常基础的组件NAND。NAND分类现在也是非常多。
我们为什么要做测试呢？
-
了解产品
-
了解自己
-
优化自己
-
优化成本模型
所以说面对如此多的厂商和产品，如何做到更高效的测试 是一个很重要的问题。虽然现在大家都开始转向云服务，直接接触硬件产品并不多，但是云厂商的测试依然是很重要的一部分。
测试很Low吗？
-
测试很简单？
-
没科技含量？
-
测试很无聊？
上图是我们需要了解的存储技术栈。
测试准则：
-
明确目标
-
高效
-
完备性
-
可量化
-
可对比
-
产出
测试过程：
-
明确测试需求
-
明确测试目标
-
选择测试工具和测试模型
-
制定测试计划
-
测试过程跟踪
-
测试数据验证
-
测试报告
测试工具：
-
IO层面：fio、sysbench、iometer、dd等
-
OLTP：sysbench，TPC－C
-
辅助工具：tcpcopy、tcprstat、pt-log-player
SysBench：
-
开源的多线程性能测试工具
-
支持CPU IO Mutex OLTP等测试
-
可以lua脚本定制测试用例
-
常用的insert select和oltp三种场景
测试痛点：
-
重复工作很多
-
标准不统一
-
测试周期很长
-
人工成本高
-
测试期间异常处理
-
测试数据处理和测试报告
解决痛点首先就是规范化，主要是以下几方面：
-
测试目标标准化
-
测试工具标准化
-
测试流程标准化
-
测试报告标准化
自动化测试流程：
-
自动化测试框架
-
基于Python
-
包含整体标准测试流程
-
覆盖主流测试工具
-
数据处处理和生成报表
-
定制测试计划
下图是测试流程图
自动化的好处也是显而易见的：
-
大大节省了人力
-
提高测试效率
-
测试的更加完整
-
有精力做更深入的测试优化
测试闪存需要注意的几点：
-
我们需要的性能是steady state
-
OP
-
NAND
-
全盘写
-
测试时间不能太短
-
性能抖动
-
监控
MySQL测试的一些问题：
-
测试数据集大小，至少要过亿
-
和内存buffer比例，要看在小cache下的性能
-
物理读
-
事务复杂度
-
多表并发
系统层面的一些注意点：
-
文件系统：Ext4 xfs
-
IO调度算法
-
IO cpu affinity
-
Scsi-mq/blk-mq（新内核特性）
InnoDB压缩测试：
-
InnoDB内置压缩
-
基于zlib库
-
理论可以达到50%左右的压缩比
-
但是性能有损失
-
CPU时间换存储空间
-
对SSD寿命有好处
-
如何用好呢？
-
基于我们之前的测试过程，我们可以得到结论，InnoDB压缩比在50%左右，对写入性能损失比较大， 损失比例在70%左右。根据这个结论，我们就可以针对我们线上业务选择是否需要使用InnoDB压缩。
TokuDB：
-
MySQL的一个存储引擎，支持事务 ACID 特性
-
支持多版本控制（MVCC）
-
基于Fractal Tree Index，非常适合写入密集场景
-
高压缩比
-
原生支持Online DDL
-
主流分支都支持
-
收费转开源
这是我们测试结果，可以看到TokuDB更好的压缩比和更好的写入稳定性，当然代价就是更高的CPU消耗。
总结
-
现在不再是性能为王的时代
-
真正了解自己需求才是更重要的
-
发掘闪存性能，软硬件结合
-
拓展闪存应用空间
-
做真正有价值的事情
-
如何做到更好的软硬件结合（其实现在硬件是超前于一些软件的）
以此图结尾，不要只活在当下，要勇敢的接受新技术，勇于试错，当然试错成本和收益也要评估和可控的。其实很多技术理解透彻了，可能并没有别人说的“邪恶”。