可计算存储: 透明压缩与SSD寿命

更高效的生产力势必替代原有的生产力和生产关系。从大型机和小型机的分区技术，再到x86虚拟化和现在风头正劲的容器和容器编排技术，都着力于提高应用的部署密度，提升计算资源的利用率，最终降低持有成本。存储领域也不例外，纵观Flash的历史：

SSD持续在企业关键应用落地并大规模部署。从MLC，TLC再到QLC，容量逐渐增大成本逐渐降低，但基于SSD技术的实现原理，寿命问题也愈发突出。

如图为JEDEC中描述WAF如何计算的例子，此Block包含64个Page（256 sectors），假设当需要更新Page1~Page3（8 sectors）数据，假设算法为:

1. 拷贝所有page0~page63到DRAM;

2. DRAM中更新Page1~Page3;

3. 擦除此Block并回写DRAM数据;

众所周知，闪存颗粒存在擦写次数的限制，所以在衡量SSD寿命时，通常会以TBW（或DWPD）为衡量依据。写放大导致了闪存颗粒擦写次数的“放大”，进一步降低寿命。有如下计算公式:

同时，随着写入量的增加，坏块的出现概率也会提升。对于可靠性，比较重要的衡量指标为UBER（不可修复的错误比特率），用来度量在应用错误纠正机制后依然产生的每比特读取的数据错误数量占总读取数量比。

UBER描述的是出现数据读取错误的概率，该值越低越好。下图描述UBER随写入数据量增加的线性关系：

• 0~600，UBER一直为0

• 600~800，此时由于写入量的持续增加，形成少量坏块，UBER从0缓慢增加到0.003

• 800~1000，更多颗粒的失效与写放大对于颗粒擦写的叠加导致剩余NAND颗粒更容易形成坏块，从而导致增加不多的写入量，UBER也急剧增加，此时数据读取错误率陡增。

总之，对于常常承载企业关键业务的SSD来讲，考虑可靠性，不仅关注写入量，随着擦写次数增加，造成的读取错误也是企业级应用不可接受的。TBW和UBER不应该单独讨论，就像在数据库领域Recovery Time Objective (RTO) 和 Recovery Point Objective (RPO)总是同时出现，只谈数据服务的恢复时间，又或者一味强调数据零丢失，都是耍流氓。当然业界也在提高SSD存储颗粒的擦写次数、GC算法方面持续发力，同时，结合可计算存储的透明压缩，也为SSD寿命及稳定性的提升带来了新的方向。

如图为JESD219，基于同样的负载模型，使用企业级常用的3.2TB/3.84TB/6.4TB SSD容量测试，数据压缩比1:1/1.2:1/2:1/2.13:1/3.7:1/9:1逐渐增大，持续10000分钟并记录写放大的数据。从测试结果可见

1. 所有模型在持续测试一段时间后会到达稳态，此时写放大趋于稳定；

2. 同为3.2TB SSD，数据压缩比从1:1/1.2:1/2.13:1/9:1，写放大骤减，3.84TB及6.4TB SSD结果类似；

JESD219考虑的已经很充分，但如果想要更接近应用负载，还需要更进一步。以数据库场景为例，使用MySQL，借助Sysbench制造读写压力（OLTP混合读写oltp_read_write、数据集2TB），可以观测到其IO模型（基于eBPF跟踪IO）和JESD219还存在较大差异：

1. I/O大小，73%的I/O集中在16~31kbytes，其原因为InnodDB数据页默认为 16KB。15%的I/O集中在1KB以下是由于redolog默认以512 bytes 进行I/O操作；

2. 数据热度，在sysbench测试中，以离散I/O为主，尽量均衡访问完整2TB数据集；

当然，这完全可以通过魔改JESD219脚本更有针对性的模拟应用负载，这里不做展开。