数据库管理-第204期数据库的IO掉速，也许是SSD的锅（20240615）

最新推荐文章于 2024-07-29 17:17:32 发布

胖头鱼的鱼缸（尹海文）

最新推荐文章于 2024-07-29 17:17:32 发布

阅读量981

点赞数 25

分类专栏：数据库文章标签：数据库

本文链接：https://blog.csdn.net/yhw1809/article/details/139705639

版权

数据库专栏收录该内容

61 篇文章 1 订阅

订阅专栏

数据库管理204期 2024-06-15

数据库管理-第204期数据库的IO掉速，也许是SSD的锅（20240615）

数据库管理-第204期数据库的IO掉速，也许是SSD的锅（20240615）

作者：胖头鱼的鱼缸（尹海文）
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。
除授权转载并标明出处外，均为“非法”抄袭

近期在一些朋友的非专业存储的全闪存储环境中，出现了一个有趣的现象：

当数据量急速上升的过程中，整个数据库的IO的性能反应会有一个较大规模的下降，需要一段时间才能恢复IO性能
当全闪存储整体存储空间使用量达到一定百分比后，数据库反应出来的整体IO会有一定下降且不稳定，一般需要提前做横向扩展并平衡数据

出现上面情况，数据库本身排查一般不会发现问题，那么换个思路，从SSD的角度来看看，为什么会出现这个问题。

1 SSD物理结构

不同于机械磁盘（HDD），通过磁头在磁盘刻录/读取信息，这需要去物理寻址。SSD的的运行方式就有点不同，SSD的核心主要有两部分：主控和闪存颗粒:

主控芯片：通过M.2、U.2或PCIe接口使用PCIe总线与CPU直连或通过主板芯片组从CPU“继承”的PCIe总线与CPU相连；并将数据写入SSD的闪存颗粒中，从闪存颗粒中读取数据；融合数据存储、清理垃圾等工作
闪存颗粒：实际存储数据的地方

（这里说明一下，一般来说服务器CPU可用的直连CPU的PCIe使可以支撑足够多的PCIe NVMe SSD的；通过主板芯片组扩展的PCIe通道一般为桌面级CPU，因存在共享通道，性能略低于直连CPU）

2 SSD颗粒类型

说起闪存颗粒类型之前，得先说一下闪存颗粒的最小存储单元，其实就是一个非常古老的硬件结构：浮栅晶体管，简单来说就是通过存储不同数量的电子（一般最多可存储7个电子）来判断存储的数据内容。然后通过海量的浮栅晶体管来存储数据，关于其他的组件就暂时放下不说了。
目前主流的存储颗粒有MLC、TLC、SLC：

SLC：一个浮栅晶体管可存储1bit数据，可存储两个内容：0-3个电子为1，4-7个电子为0
MLC：一个浮栅晶体管可存储2bit数据，可存储4个内容：0-1个电子为11，2-3个电子为10，4-5个电子为01，6-7个电子为00
TLC：一个浮栅晶体管可存储3bit数据，可存储8个内容：0个电子为111，1个电子为110，2个电子为101，3个电子为100，4个电子为011，5个电子为010，6个电子为001，7个电子为000

从容量来看：SLC < MLC < TLC，越往右同样数量的浮栅晶体管可以存放更多数据，这也导致了越往左成本越高
从性能来看：SLC > MLC > TLC，越往左一个浮栅晶体管需要操作的次数更少，也不需要更加精确的电子控制；同时也需要更多的浮栅晶体管来存储相同大小的数据，多个浮栅晶体管可并行写入加速
从寿命来看：SLC > MLC > TLC，越往左单个浮栅晶体管擦写操作更少；越往右，浮栅晶体管出现需要融合数据的概率越大

3 DRAM & SLC Cache

首先，我们来算算，使用不同类型的闪存颗粒存放1TB数据大概需要多少个浮栅晶体管：

SLC：1024×1024×1024×1024
MLC：1024×1024×1024×1024/2
TLC：1024×1024×1024×1024/3

不需要计算结果，即便是TLC都是需要海量的浮栅晶体管来存放1TB数据。那么海量的浮栅晶体管存放数据，肯定不可能一个一个去检索，这里就需要FLT(FLash Translation Layer)表来记录逻辑数据和物理位置之间的关系。那么这个FLT放哪呢？怎么加速查询？这里一般来说主要有两种方案。

3.1 DRAM

这里可以在SSD中添加一个DRAM来存放FLT表：

众所周知，DRAM的IO性能是远高于闪存颗粒的，DRAM缓存FLT是可以极大提升检索数据物理位置映射的效率。另一方面，DRAM也可以作为写入缓存，以解决MLC、TLC的写放大问题(说白了就是排队累积对应量的数据再写入闪存颗粒，减少单个浮栅晶体管的空间浪费避免空间回收和融合出现)。

3.2 SLC Cache

尤其是使用TLC颗粒的SSD，可以通过将一部分TLC浮栅晶体管模拟成SLC模式，来缓存FLT表和写入缓存。

使用这种方式会增大主控的维护压力，而且会写入模拟SLC的数据最终会转换至TLC中，且数据量的整体提升会压缩模拟SLC的数量，这样一是会降低维护FLT和写入缓存的性能，另一方面会放大模拟SLC转换TLC操作量。最终当没有模拟SLC剩余时，SSD的性能会下降的十分明显。同时这种方式性能肯定比不过SSD内置DRAM。

3.3 其他方式

在主控芯片中添加一块不大的区域缓存常用的FLT表信息
闪存颗粒中划分固定区域模拟SLC模式来缓存部分常用的FLT表信息和写缓存
向机器主内存借用一块区域来存放部分常用的FLT表信息
等

4 缓外降速

一般来说企业级SSD都会使用SLC闪存颗粒+较大的DRAM来兼顾寿命与性能，但是这样往往价格会高不少。经过观察发现，文章一开始出现问题的环境为了兼顾成本往往使用的是SSD是较小DRAM或者是模拟SLC缓存的民用级SSD。那么当数据暴增超过缓存容量时，会出现降速的现象，甚至会处罚浮栅晶体管的类型转换；当整体容量足够大时，SSD也会因为失去缓存而出现性能问题。