共计 4400 个字符，预计需要花费 11 分钟才能阅读完成。
这几天，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 都是能够帮忙您建设更有性价比的数据库托管服务，更好更不便地治理数据库。快来试试吧。
针对这个问题，你怎么看呢？欢送在留言区跟咱们互动，也欢送扫码退出群聊。
参考文章链接：
- https://databasearchitects.blogspot.com/2024/02/ssds-have-bec…
- https://news.ycombinator.com/item?id=39443679
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-p…
关注小猿姐，一起学习更多云原生技术干货。
