数据库管理-第203期 阻碍数据库国产化前行的硬件（20240614）

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

也许看到本期文章的题目，会觉得，得嘞，又一个黑国产硬件的来了，但是我今天真不是来黑国产硬件的，而是吐槽一下硬件采购，下面举几个栗子。

1 有但不是全有

为了提升数据库各节点的网络交互能力，在几年前的采购意向填写中，就加入对25GE、40GE网络环境的需求。然而当硬件采购下来之后，令人欣喜的是，服务器网卡支持25GE和40GE，交换机也支持40GE，但所有光模块和光纤都是10GE的，把硬件的向下兼容做到了极致。
在分布式存储场景下，共享存储的性能就被限制在了10GE；如果有负载较大的分布式数据库场景，网络也会限制整体性能的上限，有时候也会造成分片不能太大从而浪费单机性能。

2 满足部分也是满足

“众所周知”，其实很多国产数据库对磁盘IO要求是挺高的，往往都要求服务器配置SSD，而目前一般使用的SSD主要有3大类接口（或称总线）：

• SATA接口：理论速率为6Gbps，约等于750MB/s，实际速率一般不超过600MB/s
• SAS接口：目前大多数为12Gbps，性能约为SATA接口的2倍，兼容SATA接口，实际速率一般为1200MB/s
• PCIe总线：这里就可以直接使用PCIe接口、M.2接口或者U.2接口，一般来说以X4（4通道）为一个单元（使用一个X8/X16的PCIe接口可以拆分成多个X4），在NVMe协议的加持下，PCIe 3.0 X4的实际速率可以来到3500MB/s以上，而PCIe 4.0 X4的实际速率可以来到7500MB/s以上

这里还需要注意：

• 有些M.2接口是不支持PCIe总线而是走的SATA总线的，速率最大也仅支持6Gbps
• 很多SATA SSD实际性能并不能全面赶超高转速大缓存SAS HDD，相较于PCIe NVMe SSD成本优势也不明显
• SSD除了速率的提升，IOPS的提升也不是HDD可以比拟的，PCIe NVMe SSD提升尤为显著

那么从实际需求来看，选择SAS SSD是一个相对折中的不错的选择。但是从实际服务器到货情况来看，有两个极端：要么只有2块480GB用于操作系统的SAS SSD，因为这类服务器往往是高性能CPU+大内存，用于计算，本来的计划是使用高性能共享存储来存放数据；另一种就是CPU和内存配置很一般，但有大量的SATA SSD，这种服务器更多是规划用于做类似于分布式存储或者对象存储的。
然而数据库场景即是计算密集型也是IO密集型，这就造成了采购的服务器要么没磁盘没IO，要么IO一般般计算能力还不够。

3 晚而慢

近几年的硬件发展不可谓不快，如前面提到的PCIe NVMe SSD，一块硬盘可以超过十几年前一个集群的性能；高带宽RDMA交换机的出现，100GE只是起步，800GE也不是上限；内存也从DDR4来到了DDR5，性能有带来了翻天覆地的进步…
其实前两节说的问题，都是硬件采购过程因种种原因时间较长，采购量又非常大，负责采购的人往往也不了解硬件；同时规划覆盖时间长到货周期也长，并没有考虑硬件进步速度。到下一次采购时又会出现相同的问题，周而复始，让可用的硬件一直落后于时代发展。另一方面，随着时代在进步，尤其是数据量的海量膨胀，长周期的硬件采购到后期经常出现硬件资源不足的情况，且不易缓解。
这也是为什么很多时候国产数据库测试时，特别是在测试结果不尽如人意时，会听到厂商吐槽提供的硬件不行。这个时候也许真不是数据库产品的问题，而是硬件确实很拉胯。

总结

本期吐槽了下硬件采购的种种问题。
老规矩，不知道写了些啥。