作者:胖头鱼的鱼缸(尹海文)
Oracle ACE Pro: Database(Oracle与MySQL)
PostgreSQL ACE Partner
10年数据库行业经验,现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星,ITPUB认证专家、专家百人团成员,OCM讲师,PolarDB开源社区技术顾问,HaloDB外聘技术顾问、OceanBase观察团成员,青学会(青年数据库学习互助会)外部顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号,非著 名社恐(社交恐怖分子)
公众号:胖头鱼的鱼缸;CSDN:胖头鱼的鱼缸(尹海文);墨天轮:胖头鱼的鱼缸;ITPUB:yhw1809。
除授权转载并标明出处外,均为“非法”抄袭
近期在一些朋友的 非专业存储的全闪存储环境中,出现了一个有趣的现象:
出现上面情况,数据库本身排查一般不会发现问题,那么换个思路,从SSD的角度来看看,为什么会出现这个问题。
不同于机械磁盘(HDD),通过磁头在磁盘刻录/读取信息,这需要去物理寻址。SSD的的运行方式就有点不同,SSD的核心主要有两部分:主控和闪存颗粒:

(这里说明一下,一般来说服务器CPU可用的直连CPU的PCIe使可以支撑足够多的PCIe NVMe SSD的;通过主板芯片组扩展的PCIe通道一般为桌面级CPU,因存在共享通道,性能略低于直连CPU)
说起闪存颗粒类型之前,得先说一下闪存颗粒的最小存储单元,其实就是一个非常古老的硬件结构:浮栅晶体管,简单来说就是通过存储不同数量的电子(一般最多可存储7个电子)来判断存储的数据内容。然后通过海量的浮栅晶体管来存储数据,关于其他的组件就暂时放下不说了。
目前主流的存储颗粒有MLC、TLC、SLC:



从容量来看:SLC < MLC < TLC,越往右同样数量的浮栅晶体管可以存放更多数据,这也导致了越往左成本越高
从性能来看:SLC > MLC > TLC,越往左一个浮栅晶体管需要操作的次数更少,也不需要更加精确的电子控制;同时也需要更多的浮栅晶体管来存储相同大小的数据,多个浮栅晶体管可并行写入加速
从寿命来看:SLC > MLC > TLC,越往左单个浮栅晶体管擦写操作更少;越往右,浮栅晶体管出现需要融合数据的概率越大
首先,我们来算算,使用不同类型的闪存颗粒存放1TB数据大概需要多少个浮栅晶体管:
不需要计算结果,即便是TLC都是需要海量的浮栅晶体管来存放1TB数据。那么海量的浮栅晶体管存放数据,肯定不可能一个一个去检索,这里就需要FLT(FLash Translation Layer)表来记录逻辑数据和物理位置之间的关系。那么这个FLT放哪呢?怎么加速查询?这里一般来说主要有两种方案。
这里可以在SSD中添加一个DRAM来存放FLT表:
众所周知,DRAM的IO性能是远高于闪存颗粒的,DRAM缓存FLT是可以极大提升检索数据物理位置映射的效率。另一方面,DRAM也可以作为写入缓存,以解决MLC、TLC的写放大问题(说白了就是排队累积对应量的数据再写入闪存颗粒,减少单个浮栅晶体管的空间浪费避免空间回收和融合出现)。
尤其是使用TLC颗粒的SSD,可以通过将一部分TLC浮栅晶体管模拟成SLC模式,来缓存FLT表和写入缓存。
使用这种方式会增大主控的维护压力,而且会写入模拟SLC的数据最终会转换至TLC中,且数据量的整体提升会压缩模拟SLC的数量,这样一是会降低维护FLT和写入缓存的性能,另一方面会放大模拟SLC转换TLC操作量。最终当没有模拟SLC剩余时,SSD的性能会下降的十分明显。同时这种方式性能肯定比不过SSD内置DRAM。
一般来说企业级SSD都会使用SLC闪存颗粒+较大的DRAM来兼顾寿命与性能,但是这样往往价格会高不少。经过观察发现,文章一开始出现问题的环境为了兼顾成本往往使用的是SSD是较小DRAM或者是模拟SLC缓存的民用级SSD。那么当数据暴增超过缓存容量时,会出现降速的现象,甚至会处罚浮栅晶体管的类型转换;当整体容量足够大时,SSD也会因为失去缓存而出现性能问题。
本期稍微深入探讨了一下SSD的一些内部的东西,希望给大家多一个视角。
老规矩,知道写了些啥。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31466763/viewspace-3018912/ ,如需转载,请注明出处,否则将追究法律责任。