SSD 已经变快了，但在云里除外

原文 ↗ Hacker News 讨论 ↗

云端 SSD 存储通常在吞吐量和延迟上都远不如现代消费级 NVMe 硬盘，即使是在主流厂商的“存储优化”实例上也是如此。评论者把这种差距归因于架构选择，例如网络挂载或高度虚拟化的存储、保守的固件与磨损均衡策略，以及优先保证可靠性和热迁移而非原始速度的设计。讨论进一步演变为对云经济和抽象层的批评，许多人认为，对于 IO 密集型或稳定运行的负载，带本地 NVMe 的专用硬件或 colo 方案在速度和成本上都可能远胜公有云选项。

云端 vs. 裸金属与更小的服务商

  • 许多人认为，IO 密集型工作负载并不适合大型云：IOPS 和吞吐量都昂贵且会被限速；对于持续使用来说，专用服务器或带 NVMe 的 colo “便宜得多”。
  • 也有人反驳说，TCO 必须把电力、空间、带宽、备件和人员成本都算进去；对小团队而言，云服务在运维上的卸载价值可能超过硬件节省。
  • 作为 AWS 的替代方案，提到的有 DigitalOcean、Hetzner、OVH、Scaleway、UpCloud（块存储速度快）、Entrywan、OCI，以及各种托管 PaaS 选项（例如 Supabase）。也有人提到对 Hetzner 身份验证冻结的担忧。
  • 讨论中对混合部署有明显兴趣：把云用于弹性扩容和溢出流量，而将稳定、IO 密集型的工作负载放在自有或租用的裸金属上运行。

为什么云端 SSD 表现不佳

  • 一个反复出现的主题是：很多云里的“SSD”其实是网络挂载的（EBS、PD-SSD、Azure managed disks），具有：
    • 比本地 NVMe 更高的延迟。
    • 在多个租户之间共享带宽。
    • 额外的层（虚拟机监控器、固件、调度器），用峰值吞吐量换取公平性、可靠性和可预测的延迟。
  • 反方观点：所有主流云也都提供真正的本地/实例 SSD（AWS instance store、GCP Local SSD、Azure temp/cached disks），这些盘是 PCIe 直连的，但：
    • 是短暂性的（停止/迁移时数据会丢失）。
    • 速度仍然明显低于现代消费级 NVMe，原因可能是虚拟化和控制器固件的限制。

基准测试与轶事

  • 多个报告显示，消费级或小型服务器 NVMe（3–7 GB/s、约 1–1.5M IOPS、几十微秒延迟）远远超过：
    • AWS 的存储优化实例，实际每个设备大约只能提供 ~2–3 GB/s 和 ~500k 4k IOPS。
    • Azure Premium SSD，延迟为 0.4–3 ms；Azure 的本地 SSD 缓存/临时盘可达到 ~40 µs，并能大幅加速数据库。
  • 有些人还觉得云 CPU 也比纸面规格相近的机器更慢；怀疑原因是虚拟化，以及便宜 SKU 里使用了较老的代际。

延迟、架构与权衡

  • 对数据库和索引密集型工作负载而言，随机访问延迟和依赖链比原始带宽更重要；网络存储在这里会拖后腿。
  • 把本地 SSD 用作缓存（例如 Rails 的“SSD cache”、Azure 的读缓存）对许多 Web 工作负载来说，效果几乎可与 RAM 相媲美，而成本低得多。
  • 讨论还涉及：是在云里为了“planet scale”而设计，还是先用一台强力机器（SQLite/Postgres + 大量 RAM/NVMe），只有在真正需要时再增加分布式复杂性。

经济、激励与趋势

  • 一些评论者认为，云厂商通过定价和限速攫取了硬件进步（NVMe、新 CPU）的大部分收益；用户获得的每美元性能提升却很慢。
  • 人们感觉到，越来越多的系统开始向本地/混合模式回流，尤其是在大规模、数据密集型的 AI 和分析工作负载上。
  • 也有人猜测，廉价本地 SSD/ GPU 以及隐私担忧，可能会推动更多功能回到 thick client，不过移动端限制仍然是瓶颈。