这几天，Hacker News 上的有个帖子下面的网友吵翻了 。原帖是发表在 Database Architects 这个博客网站的。作者主要观点是认为基于闪存的固态硬盘（SSD）在大多数存储使用场景下已取代了磁盘。SSD 的吞吐量取决于与主机的接口速度，随着 PCIe 接口的升级，SSD 的吞吐量也增长。而云供应商的存储性能提升却相对缓慢，仍停滞在每块本地盘 2GB/s 的速度上。最先进的固态硬盘和主要云供应商提供的固态硬盘之间的性能差距，尤其是在读取吞吐量、写入吞吐量和 IOPS 方面，正在逼近一个数量级。究其原因，可能是避免 SSD 擦写寿命到期引起故障吧，也可能是缺乏对更快的存储的需求，或者担心扰乱其他存储服务的成本结构。但是这三个点并不足够解释云存储的速度仍然落后的原因。原文如下，不长，感兴趣的同学可以看看。但是比起原文，原文引发的讨论更有趣。
原文如下
《SSD 硬件速度飙升，唯独云存储未能跟上》
近年来，基于闪存的固态硬盘（SSD）在大多数存储使用情况下已大幅取代了磁盘。每个 SSD 由许多独立的闪存芯片组成，每个芯片都可以并行访问。假设 SSD 控制器跟得上，那么 SSD 的吞吐量主要取决于主机的接口速度。在过去的六年中，我们看到了从 SATA 过渡到 PCIe 3.0 再到 PCIe 4.0 再到 PCIe 5.0 的快速进化。SSD 吞吐量爆发性增长，如下图：
同时，变好的不仅仅是性能，还有成本。
开放标准（如 NVMe 和 PCIe）、巨大的需求加上厂商的内卷，为客户带来了巨大的好处。如今，顶级的 PCIe 5.0 数据中心固态硬盘（SSD），如 Kioxia CM7-R 或三星 PM1743，实现了高达 13 GB/s 的读取吞吐量和超过 270 万的随机读 IOPS。现代服务器拥有约 100 个 PCIe 通道，使得在单个服务器上使用数十个 SSD（每个通常使用 4 个通道）打满带宽成为可能。例如，在我们的实验室中，我们有一台单插槽 Zen 4 服务器，配备了 8 个 Kioxia CM7-R SSD，实现了高达 100GB/s 的 I/O 带宽！
AWS EC2 是 NVMe 技术的先驱，在 2017 年初就推出了 i3 实例，配备了 8 个物理连接的 NVMe 固态硬盘。当时，NVMe 固态硬盘仍然很昂贵。单个固态硬盘的读取（2GB/s）和写入（1GB/s）性能也被认为是当时的最先进技术。在 2019 年，又迈出了一步，推出了 i3en 实例，成本降了一倍。
自那时以来，已经推出了几种 NVMe 实例类型，包括 i4i 和 im4gn。然而，性能并没有增加；在 i3 推出七年后，我们仍然在每个固态硬盘 2GB/s 的速度上停滞不前。而 i3 和 i3en 实例仍然是 AWS 在 IO/$ 和 SSD 容量/$ 方面提供的最佳选择。我个人认为，考虑到我们在商品市场上看到的固态硬盘带宽爆发和成本降低，这种停滞不前是不可思议的。最先进的固态硬盘和主要云供应商提供的固态硬盘之间的性能差距，尤其是在读取吞吐量、写入吞吐量和 IOPS 方面，正在逼近一个数量级。（Azure 的顶级 NVMe 实例只比 AWS 略快。）
更难以理解的是，云计算在其他领域有巨大的进步。例如，在 2017 年到 2023 年同期，EC2 网络带宽爆发增长，从 10 Gbit/s（c4）增加到 200 Gbit/s（c7gn）。我只能猜一下云供应商在存储方面没有赶上步伐的原因：
- 一种说法是，考虑到每个固态硬盘的总写入次数有限，EC2 有意将写入速度限制在 1GB/s，以避免频繁的设备故障。然而，这并不能解释为什么读取带宽停滞在 2GB/s。
- 第二种可能性是，没有对更快存储的需求，因为很少有存储系统实际上可以利用数十 GB/s 的 I/O 带宽。请参阅我们最近的 VLDB 论文。只要快速存储设备尚未广泛可用，优化现有系统的动力也很小。
- 第三，如果 EC2 推出快速且便宜的 NVMe 实例存储，它将扰乱其他存储服务（特别是 EBS）的成本结构。这当然是经典的创新者困境，但人们希望较小的云供应商会迈出这一步，以获得竞争优势。
总的来说，我对这三个说法都不完全信服。我希望我们很快能看到配备 10GB/s 固态硬盘的云实例，使得这篇文章的内容过时。
Hacker News 网友的精彩评论
这个文章发到 HackerNews，就立即上了首页，并引发了激烈的讨论。大多数网友表述支持文章观点，并从不同角度声援原文。
"确实如此"篇
这位网友认为云计算的问题比原文提及的更严重，因为 IOPS 才是关键。他指出了云盘 IOPS 不足和没有暴露出存储层次结构供上层业务（例如数据库）进行优化的问题。
有网友结合自己的实际经历，认为如果每年的云计算费用已经超过了 5000 万美元，在本地环境中运行大规模私有云可能比云计算更具成本效益，在大数据和人工智能领域的一些顶尖公司已经采取了这种方式。
看来，国际上，对于下云的思考和实践比国内要迅速和果断的多。
还有网友说道，如果对 IOPS 和带宽有较高要求，且不需要弹性扩展能力，更便宜的专用服务器难道不香吗？
有人把话题发散开来，猜想这会不会是因为云厂商到目前为止还没有采用最新硬件比如新的 CPU？
不过有网友回复说 AWS 其实已经提供了相关服务，比如intel最新一代CPU "Sapphire Rapids"。
而不喜欢云厂商的网友直接指出云技术是"骗局"！
手撕 bench 篇
当然也有较真的网友真的做了 bench 测试，用数据来支持文章观点，有以下发现：
- Azure 网络延迟约为 85 微秒。
- AWS 网络延迟约为 55 微秒。
- 两者都可以做得更好，但仅限于特殊情况，例如 HPC 集群中的 RDMA NIC。
- 跨 VPC 或跨 VNET 基本相同。有些人说它非常慢，但我在测试中没有看到这一点。
- 由于不可避免的光速延迟，跨区时间为 300-1200 微秒。
- 两个云的虚拟机到虚拟机带宽均超过 10 Gbps (>1 GB/s)，即使对于最小的两个 vCPU 虚拟机也是如此！
- Azure Premium SSD v1 延迟大约在 800 到 3,000 微秒之间变化，这比网络延迟要差很多倍。
- Azure Premium SSD v2 延迟约为 400 到 2,000 微秒，这并没有好多少，因为：
- Azure 中的本地 SSD 缓存比远程磁盘快得多，我们发现Premium SSD v1 几乎总是比Premium SSD v2 快，因为后者不支持缓存。
- 同样在 Azure 中，本地 SSD缓存和本地临时磁盘的延迟均低至 40 微秒，与现代笔记本电脑 NVMe 驱动器相当。我们发现，切换到最新一代 VM 并打开数据盘的"读取缓存"可以让数据库一键加速......而且没有丢失数据的风险。
我们研究了两个云中的各种本地 SSD VM机型，例如 Lasv3 系列，正如文章提到的，性能增量并没有让我大吃一惊，但数据丢失风险让这些不值一提。
分析原因篇
对于文章结尾提到带宽被限制了的问题，也有网友找来OSDI的一篇论文《mClock: Handling Throughput Variability for Hypervisor IO Scheduling》，说 mClock 调度器（一个在不同虚拟机之间进行公平的 I/O 调度的算法，可以帮助避免"噪声邻居"问题，即一个虚拟机的高负载会影响同一物理主机上其他虚拟机的性能）可以解决这个问题。
也有网友从成本角度出发为原文总结的理由引入新观点，SSD 存储因为数据擦写放大效应会带来寿命下降的问题，而且云厂商维护海量的SSD硬件，并对它们进行升级也需要付出维护成本。
来自 Oracle Cloud Infra 的网友也补充了自己的看法，他认为可能是缺乏具体的需求反馈。
解决方案（趁机广告）篇
有网友（疑似微软员工）说，AWS 和 Azure 面对的问题是"虚拟化成本"。Azure 的下一代"Azure Boost"虚拟化技术，VM 操作系统内核直接与硬件对话，完全绕过虚拟机管理程序，单个虚拟机的 IOPS 高达 380 万，性能将得到大幅提升。
除了对原文总结的原因进行补充，也有网友分享了自己的存储解决方案：
有选择混合方案的：
也有还没调研好方案，求推荐针对小团队的 AWS 平替。热心网友（各其他厂员工）当场安利一波，比如 Hetzner、Entrywan、Supabase等。
反对的声音也有--但很少
由于作者提出来的数据是个事实，
反对者使用 AWS 博客提供的数据质疑了作者文章中说的"（AWS）在 i3 发布七年后，每个 SSD 仍保持 2 GB/s 的速度"。
当然，这组宣传数据立即引发了质疑：有个别较真网友拿刚测试好的数据直接打脸：单个 SSD 是 2.7 GB/s，虽然确实比 2GB/s 好一丢丢，但是在 4202 年来说，这一数据显然不怎么好看。
还有一类反对者说，一方面是用户对高速存储没有太多需求，另一方面，限制 I/O 速度可以允许虚拟化层在 I/O 栈上实现一些功能代码。而这些操作在"原始硬件速度"下开销太大了，无法实现。
还有人觉得这些速度上的差异对普通使用者没什么区别，文章是从 prosumer （"Prosumer" 是 "professional" 和 "consumer" 两个词的组合，用来描述专业级用户）角度出发的讨论。
结尾
当下，在降本增效的大背景下，用云的价值和成本越来越值得被重新思考和讨论，我们也能看到会有更多的厂商会选择更加多样化的基础设施的部署方案。无论是使用云盘，还是云上的 NVMe 盘，还是物理机上的 SSD 裸盘，KubeBlocks 都是可以帮助您建立更有性价比的数据库托管服务，更好更方便地管理数据库。快来试试吧。
针对这个问题，你怎么看呢？欢迎在留言区跟我们互动，也欢迎扫码加入群聊。
参考文章链接：
End
KubeBlocks 已发布 v0.8.0（KubeBlocks v0.8.0 发布！Component API 让数据库引擎组装更简单！）！KubeBlocks v0.8.0 推出了 Component API，让数据库引擎的组装变得更加简单。Addon 机制也有了重大改进，数据库引擎的 helm chart 从 KubeBlocks repo 中拆分出去，从此数据库引擎或者版本的变动已与 KubeBlocks 发版解绑。v0.8.0 还支持多版本的数据库引擎定义。Pika、Clickhouse、OceanBase、MySQL、PostgreSQL、Redis 等均有功能更新，快来试试看！
小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！
💻 官网: www.kubeblocks.io
🌟 GitHub: https://github.com/apecloud/kubeblocks
🚀 Get started: https://kubeblocks.io/docs/release-0.7/user_docs/try-out-on-playground/try-kubeblocks-on-your-laptop
关注小猿姐，一起学习更多云原生技术干货。