​可计算存储技术对 SSD 和数据库的影响分析(上)

2022-08-15 00:00:00 数据 数据库 压缩 压缩比 容量


本文是 2022/7/29 在DOIT和华科计算机学院联合举办的2022全球闪存峰会SSD 固态存储技术论坛上的分享内容的文字总结,主要是介绍可计算存储在SSD和数据库领域的创新实践原理,适合数据库运维、研发领域人员。线上分享由于时间有限,有些原理没有多说。这里文章会稍微多说一些。




可计算存储背景


近十年来,数据的产生和使用出现了爆发式的增长,全球的数据规模远远超出存储产能。而随着摩尔定律的失效,CPU性能提升速度也减缓,面对日益增长的海量数据,算力紧张已经是一些客户迫在眉睫的问题。
当传统的计算和存储的处理方式很难满足数据增长的需求时,的办法就是通过创新来提升计算和存储的效率。具体做法就是让计算分流。比如说把AI的运算分流到GPU、TPC和FPGA等高效的计算引擎里,把网络相关的繁重运算分流到智能网卡芯片里。在存储领域,SSD的容量和性能都得到很大的提升,给服务器的CPU带来更大的挑战。这时候我们可以把部分“计算”功能下推到存储层面。这就是可计算存储的诞生背景。对于互联网大企业和云厂商而言,可计算存储也是企业存储降本增效的有力方案。



可计算存储的目标就是大幅提升应用及基础设施的附加值。具体亮点有:

·提升SSD的可用容量和读写性能,提升单机的存储容量和处理性能。

·降低企业存储的TCO。这个是很多大中型客户的主要诉求。

·使用对上层应用完全透明,不需要应用改造。



可计算存储,英文称呼是Computational Storage Drives,后面简称CSD,本质上也是SSD。只不过是在SSD里引入了一个计算引擎。可计算存储重新定义了存储和计算的软硬件边界。可计算存储究竟如何,在实践时要回答下面几个问题:

·CSD 存储设备内的计算能力如何?

·CSD能带来的空间和性能收益多大?

·上层应用跟CSD存储层协同设计复杂度如何?


后面我们将通过案例来解答这些问题。




SSD 使用特点


由于CSD主要场景是数据库,为方便数据库研发和运维人员了解CSD,这里先回顾一下标准的SSD的一些使用特点。这里主要是详细介绍一些设计原理,不会涉及太多硬件电路原理,所以也不会枯燥。



首先SSD跟机械盘不同,存储介质是闪存颗粒(又称NAND 颗粒)。先看看NAND的特性。


NAND 特性

NAND的小管理单位是Page,大小一般是4KB,没有扇区(Sector)概念。NAND跟机械盘扇区一个大的不同就是不支持原地更新。NAND 颗粒的操作主要是三种类型:读(Read)、编程(Program)、擦除(Erase),后两者对应常说的写操作。Program就是写入实际数据,但是只能在一个空的Page上写,所以一个Page被Program一次后就不能做第二次,除非这个Page被Erase为空Page。后面这个操作又叫空间回收。如果同一份数据要修改,SSD的做法是将新数据写到新的Page里。如果应用反复更新同一笔数据,那SSD内部就会不断的写到新Page,并且产生了很多老版本的数据。从应用角度,老版本数据是的,但在SSD内部,还占用着NAND 资源。所以老数据也需要回收机制。有些朋友可能会看出,SSD这个写特点跟LSM Tree的写很像。


SSD的这种更新我们也称为异地更新(out-of-place-update)。但是上层应用(文件系统或数据库)从未感知到这一点,这要归功于SSD架构里一个重要模块:闪存转换层(Flash Translation Layer,简称FTL)。这个后面再单独介绍。


NAND颗粒第二个特性是Read和Program的小单位是Page,Erase的小单位是Block。这是SSD的硬件设计特性决定的。Page大小一般是4KB,Block由很多Page组成,具体数量每个品牌的NAND可能有些不同,一般大小在几MB左右。由此带来的影响是在时延上,Read时延会小于Program(小一个数量级,10倍以上差异),Program时延小于Erase(大概有几倍的差异)。再引申一点说,NAND的读性能很容易受写影响,尤其是Erase操作。当然在SSD层面,可能会看到写时延比读时延要低,那是因为SSD内有DRAM缓存,SSD的写只要写到内部DRAM缓存就会返回(注:DRAM有电容保护,不用担心SSD掉电丢数据。)。当SSD读写压力很高的时候,后端NAND读写压力也会上去,前面分析的读受写影响的这个结论还是成立的。



NAND颗粒第三个特性是有使用寿命,具体就是Erase的次数有限。如TLC SSD NAND颗粒可反复擦写次数大概几千次,QLC则是几百次。这是NAND颗粒的特性决定的(QLC容量更大),SSD内部的主控模块还会有自己的设计去全局统筹NAND 颗粒的使用,从而大化SSD的使用寿命。其中一个统筹策略就是垃圾回收(Garbage Collection,又称GC),GC 就涉及到块擦除。这个主要是决定回收哪些NAND块。第二个统筹策略是磨损均衡(Wear Leveling,又称WL)。这个主要是将一些热数据块(擦除次数很多)上数据搬迁到一些冷数据块(擦除次数很少)上,以尽可能拉平不同NAND块的使用寿命。GC和WL 都是主控的逻辑,跟FTL也有关系。GC和WL活动会占用NAND里带宽资源,所以对应用的读写活动会有一些负面影响。这就是为什么SSD 使用一段时间进入稳态后性能会下降一些。


FTL

FTL有很多功能,这里分享对其中一个功能的理解。由于SSD 后端NAND颗粒不支持原地更新,只支持异地更新。而以前的文件系统和上层应用习惯了机械盘的原地更新机制。所以FTL就负责起应用IO的目标地址的转换,具体就是Logical Block Address(简称LBA)到Physical Block Address(简称PBA)。当应用更新同一笔数据(同一个LBA地址),后端NAND颗粒的PBA地址会不断变化,FTL会不断更新后端的PBA地址,上层应用就感知不到这个。FTL 在做LBA到PBA的映射时,映射的长度通常也是一样的,即等长映射,是1:1映射。


不过随着SSD技术的发展,上面这些也不是一成不变的。
如在可计算存储里,应用IO写入的数据在经SSD主控写入到后端NAND之前会被压缩,所以实际存储空间会比数据原始大小要小很多。也就是LBA到PBA的映射是变长映射,是N:1映射(N>1)。这个变化讲起来简单,却给SSD和上层应用带来很大变化。后面会继续深入的展开。
FTL要做的映射对于SSD是必须的,但FTL模块不一定非要在SSD内部,虽然大部分SSD是这么做的,但是大部分SSD也都也为此付出代价,就是SSD的写放大和NAND颗粒寿命问题。NAND颗粒的Erase是以Block为单位,大部分时候Block上可能同时包含有效数据和数据。Erase之前需要将有效数据读出再写入到新的Block里新的Page(这就是数据搬迁),然后才能将整个老的Block擦除,老的Block里所有Page都变成空的状态。有效数据搬迁后,FTL也会更新对应的PBA地址。GC和WL活动都会触发Erase动作,也就是会触发有效数据的搬迁。这个成本会算在写入上。SSD会统计LBA写入的数据量以及后端PBA写入的数据量,后者除以前者就是SSD的写放大指标(Write Amplification Factor,又称WAF)。SSD寿命跟可Erase的次数有关,所以我们通过不同的WAF可以粗略比较寿命的状况(是好还是坏)。实际寿命是通过在SSD生命周期内每天可以全盘写入的次数(Drive Write Per Day)来衡量的,DWPD的测量计算会用到WAF。
近几年流行的ZNS SSD 技术从Open Channel SSD发展过来,实现将FTL从SSD内部上移到主机端,实现应用自己控制SSD后端NAND的读写,从而大程度的规避SSD的写放大和寿命问题。当然它的代价就是应用软件要重新设计,适合研发实力很强的大型企业。这个产品理念还不错,目前业界还在探索中。这个以后再探讨。
就CSD而言,FTL跟标盘一样,在SSD内部。


写放大

再聊聊写放大。上面说的写放大,具体是指SSD的写放大,通俗的说实际产生的IO比应用原始的IO数据量的比值。SSD的写放大通常是很高的,在5以上。写放大的负面影响一方面是寿命,另外一方面也就是性能了。因为Erase时延大,且占用NAND内部带宽。


写放大不光是在SSD内部有,在数据库内部也多处存在。比如说BTree数据库,数据库存储都是定长块,有8KB、16KB等等。当应用想修改块内部分数据时,数据库需要读入完整的块,然后在内存中修改,再后面刷写到存储上。如为了修改1个KB 的数据,实际落盘时写了8KB,那这个写放大就是8。这里还没有统计数据库的WAL Logging带来的写。实际上传统关系型数据库多是BTree模型,其写放大都是很厉害的。这些数据库的瓶颈大多是在IO,跟写放大也有点关系。
LSM Tree数据库的写放大则小很多。以Rocksdb为例,应用每次写请求都是顺序写,会以追加模式写到数据文件中。每次IO 修改多少数据,实际产生的写IO数据也基本差不多。这就是LSM Tree在写放大方面比BTree 要好很多的地方。所以LSM Tree类数据库产品,都会声称对SSD友好。跑LSM Tree数据库时,SSD的性能和寿命会更好。当然凡事不会只有好处没有代价。LSM Tree的追加写模式导致读请求的时候额外IO会很多,为了减少读IO,LSM Tree数据存储会分层存储,每一层会合并下一层相同数据的多次IO。Rocksdb默认分7层,OceanBase默认分三层。同样的数据依然可能会存在写多次。TiDB就对Rocksdb做了个优化,当短时间内写入大量数据时,可以绕过下面几层直接写入到高层,也是为了降低数据库层面的写放大。
一般来说,数据库层面降低写放大,SSD层面的写放大也会得到极大的改善。对于传统的BTree类数据库,这个确实会是一个缺点。在学术界也有很多弥补方法。其中一个思路就是在数据库数据落盘之前,使用一块缓存,将BTree的随机写转化为顺序写,也能达到降低SSD写放大的目的。这个需要对数据库改造。


OP 空间

还有一个影响写放大因子的因素就是NAND剩余空间。NAND的更新是异地更新,所以不断的需要新的Page来容纳写入。而老版本数据的回收是有延迟的,这个就让空间利用率看起来很低,容易被用户吐槽。
SSD 的解决方案是会保留一定比例的NAND容量不对用户可见,但是应用写入的时候是能用上这部分空间。这部分空间叫Over Provision,简称OP空间。通常OP的比例有 7%和 22% 两种。比如说一个4TB的SSD盘(这里1 TB=109 Byte),通常实际可用容量是 3.84 TB 或 3.2 TB两种。


需要注意的是,实际查看块设备大小,3.84TB 的SSD可用容量显示为 3.5 T。后面这个T严格写应该是 TiB (1 TiB=210 Byte))


通常SSD 也提供了命令取调整实际可用容量,从而间接改为OP空间的比例。一般是往大了调整。
更大的OP空间是可以降低写放大因子。其原因是OP空间都是空Page,是可以写入的。OP空间越大,触发Erase的次数就越少。或者GC和WL 活动就可以在低峰期去执行,且数据搬迁的数量也相对要少很多。所以以前如果为了追求SSD读写性能的稳定性(即抖动比例很小,调大SSD OP空间是一种做法。代价就是牺牲一部分可用容量(因为部分容量转为对应用不可见)。
随着SSD技术的发展,这个问题也有两个解决方案。一是在ZNS SSD里,应用直接读写NAND,直接控制整块Erase,不用SSD做数据搬迁。那么OP空间也就没有意义了。那么SSD可以相对提供更大的可用容量。成本和风险就是主机端应用或者文件系统要自己管理SSD NAND的容量。这里面也会有很多挑战。目前业界也在探索。
第二个解决方案就是可计算存储,由于压缩了写入到NAND里的数据量,使得NAND的消耗速度相对标盘下降很多,间接的效果就是剩余空间(包括OP空间)看起来相比标盘要更大一些(总容量大小一样,只是CSD的NAND消耗速度更低,所以有这种错觉)。OP大,读写性能就更低更稳定。



CSD 使用特点


CSD 本质上也是一个SSD,上面说的SSD使用特点也适用于CSD。只不过会有一些变化。
CSD的不同之处是在SSD内部引入的计算引擎功能,主要功能包括:压缩和解压缩、加密和解密。这里只说压缩和解压缩,具体会在主控将数据写到后端NAND颗粒之前对要写入的数据进行压缩;反过来读取的时候从NAND颗粒读出的数据再进行解压缩。



透明压缩

CSD的压缩是在SSD内部的,是实时的压缩。因为对上层应用不可见,所以也可以称为透明压缩。说到压缩,通常容易想到两点。一是压缩能省存储空间,二是数据库或者压缩卡也可以做压缩。这里分别展开描述。


前面在介绍SSD OP空间也介绍了,CSD的容量规格跟标盘一样。如 CSD 2000 TLC有4TB和8TB 两种。4TB 的 CSD格式化后操作系统看到的容量也会是 3.5 TiB。这个代表的是 3.5 TiB的LBA地址容量,在文件系统或者SSD格式化的那一刻就确定了,后期也不会改变。
所以CSD的透明压缩时能够压缩存储空间,但不会改变操作系统里看到的盘的总空间和已使用空间。CSD压缩的是后端NAND物理容量,是有效数据占用的PBA地址的容量。PBA地址容量通常对操作系统是不可见的(因为在标盘里 PBA地址容量跟LBA地址容量是等长映射,所以以前都不关注NAND物理容量)。
所以,在CSD里,一个100GiB的数据文件,看起来还是100GiB。上层应用看到的存储接口以及返回的数据跟SSD标盘都是一样的(所以称之为透明压缩)。不一样的是在CSD内部,这个数据文件实际占用的NAND空间可能只有20GiB。我们把操作系统里看到的数据文件大小称为逻辑大小,SSD内部NAND占用的容量称为物理大小。逻辑大小跟物理大小的比值就是数据文件的压缩比。在SSD标盘里,所有文件的压缩比都是1,。在CSD里,压缩比一定大于1。有关压缩比的分析后面再展开。CSD内部的物理大小需要单独的命令查看。CSD的物理使用容量、剩余容量也需要命令查看。因为SSD标盘没有这部分,所以这部分命令自然也不是通用的。
通常应用也不需要关注数据文件的实际压缩比,或者CSD的实际物理容量使用情况。因为默认情况下NAND的物理容量是不可能用完的,这是SSD标盘的特性决定。但是CSD的透明压缩还带来了一个额外的用法,就是可以超额提供可用容量使用。这是一种扩容的用法,后面再单独介绍。


我们再接着分析透明压缩的另外一个疑问,就是跟应用压缩或者压缩卡(如FPGA)有什么区别。

首先是压缩发生的位置。如果是应用自己压缩,需要占用主机的CPU资源。影响的大小取决于压缩算法。应用常用的压缩算法有lz4、snappy、zlib、zstd。Lz4和snappy的压缩比(压缩前大小除以压缩后大小)差不多,zlib和zstd的压缩比差不多,前两者的压缩比又比后两者压缩比小,对CPU的消耗也要小。生产环境传统关系数据库一般不开压缩,怕压缩影响性能。LSM Tree数据库大多开压缩,但是在前面几层也只敢用lz4 压缩,在后面两层才用 zstd算法。因为后面几层的合并时被触发的时间不多,不会对在线交易实时影响。此外还有就是后面几层合并本身就是很影响性能,也就不在乎多占一点CPU资源了。
还有一种压缩方案是使用FPGA卡压缩,需要应用修改代码指定。这个不怎么占用主机的CPU资源,不过要额外占用IO带宽。并且加速卡需要额外占用一个PCIe插槽。单个卡的处理能力也是有上限,所以不一定能扩展使用。
随着单机存储容量的提升,应用压缩方案和FPGA卡压缩方案可能会面临一个算力瓶颈问题。CSD的透明压缩能力是以盘为单位的,当数据存储需求增长时,只需要插入更多的CSD即可。此外透明压缩也不额外占用主机的IO带宽等。


关于应用开压缩的原因还有一个推测是以前PCIe 的带宽不高,应用的读IO的带宽很可能受PCIe 限制。如果随着Gen4 服务器的逐步普及,Gen5 也在路上。未来PCIe的带宽将会极大提升。PCIe 4.0 x4 预计7.8GB/s,PCIe 5.0 x8 预计24.6GB/s 。所以从这个角度使用主机CPU去压缩读写IO的带宽不是那么的有必要。不过当PCIe通道带宽不是瓶颈的时候,SSD的吞吐瓶颈可能会在后端NAND读写带宽上。从这个角度来说,对于普通的SSD,应用压缩又有点意义。但是对于CSD,由于后端NAND实际写入带宽会被压缩,所以后端NAND带宽使用率更高,理论上可以让SSD前端实际带宽跑到更高(接近PCIe的限制)。


读写性能

再说说透明压缩对性能的影响。理论上在链路上似乎多了一个压缩和解压缩环节,会增加时延。实际上由于SSD的写入都是写到内部DRAM就返回,此后CSD会批量读取DRAM数据再压缩写到后端NAND。低并发的时候,这个压缩不会直接影响应用的写时延。高并发的时候这个影响还是有一点,不过由于SSD标盘在高并发写入的时候,由于GC和WL的影响,写的时延会变大且不稳定,而CSD却由于透明压缩隐性增大了OP(或者叫剩余空间更合适),减少了GC和WL活动,所以CSD写时延的变化相对SSD标盘而言反而很小,整体时延更低且更稳定。读方面延时本来就很低,加上有一定预取机制,解压缩环节对读性能影响也不大。



图中粗的线条是CSD,细的线条是SSD标盘。随着写比例的增长,读写总的吞吐(IOPS)会出现下降,但是CSD下降的比例比SSD标盘要小很多,相对而言性能就更好更稳定一些。上图还再次说明应用写的比例会影响读写总的性能



前面多是理论分析,关于CSD的读写性能特点我们来看更多测试数据。CSD奇妙的地方就在于性能还会随着数据压缩特性变化而变化。眼见为实。



首先看顺序写。图中横坐标是FIO测试数据的压缩比,有三类:不能压缩(压缩比是1:1),可压缩性一般(压缩比1.26:1),可压缩性很好(压缩比 2:1)。蓝色的是SSD标盘的顺序写吞吐,黄色的是CSD 3000 的顺序写吞吐。当数据压缩比为1:1的时候,CSD跟SSD标盘的写吞吐相差不大,但是当数据有一定压缩比后,CSD的写吞吐就有很大提升(增加1-2个GiB)。而SSD标盘对数据压缩比的变化没有一点反应。所以CSD 在数据可压缩的时候写入吞吐是远高于SSD标盘。这个原因主要是CSD后端NAND带宽每个IO实际带宽更低从而整体上能支持更大的前端写入带宽。


再看随机读和写。左边是随机写,右边是随机读写混合(读:写=7:3)。当数据没有压缩比的时候,CSD随机写IOPS略低于SSD标盘,但是当数据稍微有点压缩比后,CSD随机写的IOPS会提升2-5倍。随机读写也受益于随机写,有1-2倍的提升。这个原因就是前面提到的,CSD有透明压缩,GC和WL更少,对应用读写性能影响更低。在CSD里不需要刻意调大OP空间来保证性能更好更稳定。


CSD的随机读写性能优势在OLTP数据库高并发场景下,也有很大的优势。后面还会详细分析。


容量扩容

这是CSD吸引用户的一个特性。
前面提到CSD的透明压缩极大的节省了后端NAND物理容量。当数据压缩比在3:1以上时,能节省2/3的NAND容量。有些企业客户会觉得有点浪费,如果能利用这部分容量,哪怕是部分容量,也能换取整体成本的降低。前面介绍FTL的时候提到应用能看到的是CSD 的LBA地址容量。这部分在CSD格式化时就确定了。用户想利用的是后端PBA地址容量,这部分又对用户不可见。如果想用到更大的PBA地址容量,只有一个办法就是将LBA地址容量扩大。


所以,当CSD扩容2倍后原本是3.2TB 可用容量的SSD,实际能存储6.4T的数据。在操作系统里查看这个SSD看到的也是6.4TB的容量。这里需要理解的如果确定数据压缩比是2:1以上,这个CSD就确定理论上能写入6.4TB容量的数据,但是只有等到对盘扩容后,应用才能真的写入6.4TB容量的数据。不扩容,应用依旧只能写入3.2TB容量的数据,跟SSD标盘一样。
容量扩容大的好处就是降低数据每GB的成本。通俗一点花相同的价钱可以存储更多的数据,应用也不需要改造。

对数据压缩有过思考的朋友可能就会提问,如果CSD扩容后但是数据却不可压缩,那还能写入6.4TB 吗? 答案是不能。极端情况少能写入3.2TB,此后还能写一会,可能写着就会报错。此时CSD后端NAND容量(包括OP空间)已经用尽。理论上当CSD的实际压缩比低于扩容比都有这种风险。
所以,CSD扩容使用时,需要先评估业务数据压缩比。然后再设置扩容比。后者要低于前者,以防意外。实际运维的时候还需要监控CSD内部NAND使用空间。
CSD也提供了命令用于查看实际的压缩比、剩余物理容量等信息。

有些用户初次接触CSD对这种物理容量监控不太适应。其实这只是空间管理的一个动作,并不是只有CSD才这样。通常大家习惯的是文件系统管理空间。有些应用如MySQL、TiDB数据库就依赖文件系统去管理空间。而有些数据库如ORACLE、OceanBase却是自己管理空间。那么后者也就需要一个数据库空间的实际使用率的监控。这里更有趣的地方就是当数据库自己管理空间的时候,就喜欢预分配空间、以及复用空间,但是不会如实告诉下面的文件系统这部分空间的实际使用情况。在文件系统看来,所有的数据都是有效的。弊端就是在文件系统层面看数据库这种用法可能会浪费空间。
文件系统也同理。当文件系统里删除一个文件后,文件系统也不会马上通知底层存储某一段LBA地址空间数据是的。在存储层面看文件系统这用法,也觉得可能会浪费存储空间。文件系统的设计者考虑到这种情况,提供一个接口用于实时通知。比如说在文件系统mount的时候,增加选项discard。这样文件系统里删除文件的时候,文件系统能够立即发TRIM通知底层存储。当存储是SSD的时候,这个通知还是很有必要的。
SSD知道一段LBA地址后就能在后面的GC活动中释放其对应的PBA地址对应的空间,这个对SSD的性能会有提升效果。当然TRIM操作太频繁也会让存储性能下降。有个权衡的过程。CSD的使用都建议mount带discard选项。相比读写文件,删除文件的操作还是很少的。只有在类似Rocksdb这类LSM Tree数据库里,高并发写入的时候,频繁的合并会导致频繁的删除小文件。
除了mount时带上discard选项方法外,也可以主动用命令 fstrim 来释放一个目录里被删除的文件空间。


数据压缩比

后再来聊一下数据压缩比。前面提到CSD透明压缩能提升随机读写性能、对容量扩容。其前提都是书具有很好的压缩比。那么真实的业务数据压缩比到底多少呢。
这里先说一下CSD使用的压缩算法是zlib(近似level 6)。CSD3000相比CSD2000的压缩比还会高一些,取决于数据自身压缩特性。Sysbench 在mysql里生成的随机数据,在MySQL数据库里同时MySQL数据目录在CSD2000上时,这份数据压缩比大概是 1.9左右。同样方法生成的数据,据我们测算在PostgreSQL里压缩比会比在MySQL里还要高一些。

测试数据还不够有说服力,再看客户生产业务数据压缩比。

不同行业的数据压缩比还不一样,低的也有2.4;高的有4.13 。结合很多客户OLTP业务数据库在CSD 2000 上的压缩比看,我们相信客户的业务数据压缩比大于2的概率非常高。当然图片、视频类文件的压缩比估计就没有这么高了。


另外一方面,如果数据库使用了lz4压缩的话,在CSD 2000上还可能有1.56左右的压缩比。如果数据库使用了zstd压缩,在CSD 2000 上的压缩比可能就1.1不到。评估传统数据库如MySQL、PostgreSQL的数据压缩比会相对容易一些,评估ORACLE数据库的压缩比会稍微麻烦一些,因为它的表空间设计使得存储拿不到真实的数据空间使用情况。评估Rocksdb/TiDB数据库压缩比会更复杂一些,因为它的数据是分层存储(多7层),0和1层不开压缩,2,3,4层默认使用lz4压缩,5,6层使用zstd压缩。所以整体的数据压缩比取决于不同层数据量的比例。其数据库自身大小也在不断合并过程中大起大落。难评估数据压缩比的是OceanBase数据库,因为它既自己管理空间又对数据存储分层压缩(多3层)(详情参考《OB 空间分配分析》)。


后再总结一下数据压缩比的经验。数据压缩比高的时候,对读写性能、容量扩容都有很好的加成作用。数据压缩比不高的时候,对性能提升不大,但是对SSD的写放大抑制、寿命提升还是有很明显的作用。在容量更大成本更低的QLC SSD里,性能和寿命正是短板,CSD跟QLC技术结合,正好弥补了这个缺陷。

介绍完了CSD对SSD使用特点的改变,后面再继续介绍CSD对数据库使用特点的改变。考虑到篇幅很大了,留到下篇分享。

个人观点,欢迎留言讨论。






相关文章