
Simeon Griggs 详解数据库集群内部的网络延迟问题
来源标题:The latency inside your database
Simeon Griggs 在博文中指出,多数云数据库采用网络附加存储,磁盘位于独立服务器、经网络连接,延迟虽小但可测量。相比之下,本地附加存储的磁盘与 CPU 同机直连主板,距离更近、读写更快。网络附加存储在吞吐量、灵活性和持久性上占优,但本地磁盘在速度上更具优势。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
Simeon Griggs [@simeonGriggs] | 2026年11月3日 网络附加存储是个不错的选择,却是个糟糕的默认选项。 应用性能入门第一条:你应当让应用尽可能靠近数据库。网络上的这段距离越短,读写数据在两者之间的传输就越快。 但你知道吗,你的数据库集群内部也存在网络延迟? 最常见的情况是,云托管数据库使用网络附加存储:磁盘位于另一台服务器上,通过网络连接,延迟小得令人惊叹,但仍然可以测量到。 另一种选择是本地附加存储:磁盘与 CPU 位于同一台机器内,直接连接到主板。 网络附加存储以灵活性和持久性支撑着极其庞大的数据吞吐量。但本地磁盘更近,更近就意味着更快,更快就更好。 你正在阅读这篇博客文章所用的设备,其工作由两个独立但同等重要的部分组成:负责执行工作的处理器,以及负责保存数据的存储。噔噔。 而且极有可能这两者被装在同一块硬件里,比如智能手机或笔记本电脑。计算机一直都是这样。 互联网基础设施最初也是如此。早期的数据库服务器,比如 Sun 的 SPARC 服务器,磁盘就装在自己的机箱内或旁边的机柜里,通过 SCSI 以及后来的 SAS 线缆连接。存储和计算位于同一物理硬件中。 但单一的存储实体并不持久。RAID(廉价磁盘冗余阵列)在 1980 年代末流行起来。多块存储磁盘保持同步,若有一块损坏,就可以换上另一块。系统依靠仍在工作的磁盘维持运行,直到新磁盘追上进度。 进入 1990 年代和 2000 年代初,企业将存储放入专用阵列。SAN(存储区域网络)通过网络将存储连接到计算。但这些设备极其昂贵,而且往往由企业自行维护。 也就是租用别人的计算机。 (为简化起见,本文聚焦于 AWS 的产品,但 PlanetScale 同样运行在 Google Cloud Platform 和 Azure 上。) 最知名的云存储服务是 AWS S3(简单存储服务)。它是一个用于存储对象的键值存储。你无法将其作为块设备挂载,也无法就地修改对象的子集。 于是有了 AWS EBS(弹性块存储),它可以像磁盘一样挂载,并能按需配置。EBS 以低于前几代企业 SAN 的成本,解决了数据库等典型存储用例的需求。 像 EBS 这样的专用存储是持久的,数据会在同一可用区内的多块磁盘上复制。丢失该可用区内的任何一块磁盘都不会导致数据丢失。 请注意,正因如此,PlanetScale 会在多个可用区之间复制数据,因为单个可用区发生故障将构成数据不可用或丢失事件。 它也很灵活:你不会受限于单个卷的存储大小,增加容量只需调整同一个卷的大小。 2008 年发布时,EBS 使用的是过去企业服务器那样的机械硬盘。因此,在网络附加存储的整个历史中,机械硬盘的速度往往比网络数据传输速度更为重要。HDD 上的平均随机读取为 10-20ms,而同一数据中心内的网络往返通常为 1 毫秒或更短。 2012 年,EBS 开始用 SSD 替换机械硬盘。磁盘操作快了约 100 倍,突然间,网络延迟成了性能的最大瓶颈。 最初,换用 SSD 并没有带来你或许期待的那种免费的速度提升。 ……它确实解决了机械硬盘物理机制带来的问题。但让我们惊讶的是,系统的提升远没有我们期望的那么大…… —《持续重塑:AWS 块存储简史》,Marc Olson,All Things Distributed 为了解决这个问题,AWS 的工程师打造了新的定制硬件和一种独特的网络传输协议(SRD)。网络延迟得到了改善。 于是,在数据中心短暂的历史中,当存储比网络慢时,存储与计算被分离;而当情况反过来时,它们又因此受到惩罚。 你可以继续尝试解决问题,也可以直接消除问题。 回到我们最初的应用性能入门课。让应用靠近数据库,与让数据库的计算靠近它的存储,道理完全一样。 网络延迟是人们使用远程服务器和云存储时早已习惯的预期,但它未必非得如此。 在典型的云托管数据库场景中,你购买一个 EC2 实例来执行计算工作,并将其挂载到一个 EBS 卷上作为存储。 EBS 卷在操作系统中显示得就像一块附加的存储设备。在当前代的实例上,一块专用的 Nitro 卡会将每一次读写都变成网络请求。 对于每一个非 Metal 的 PlanetScale 数据库,你拥有的就是这样的配置,而且它运行得很好。 然而,某些 EC2 实例类型还附带本地 NVMe 磁盘,物理连接在宿主机服务器上。这些不是 EBS 卷。由于是本地附加,读写不存在网络跳转。 如果你想要的只是速度,那么把数据库及其存储放在一台自包含的实例上就完全合理。 但如果这如此显而易见,为什么却很少有人提供?因为如果没有精心的管理,风险太高。本地附加存储与计算同生共死。它的大小是固定的,数据也不会自动复制。 如果不灵活、不可靠、不持久,快也没有用。这正是我们通过 PlanetScale Metal 解决的问题。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。