S3 正在吞噬一切：AI 时代的基础软件架构革命

如果你关注过去两三年涌现的新一代数据基础软件项目，会发现一个惊人的共性：无论是搜索引擎、向量数据库、时序数据库、OLAP、流式计算还是日志分析平台，它们几乎都选择了同一个架构基底：S3 对象存储。

这不是巧合。先看看正在发生什么。

从搜索到数据库：S3 成为新一代基础软件的共同选择

TurboPuffer：S3 原生向量搜索

TurboPuffer 是第一个完全对象存储原生的向量数据库，所有数据默认存储在 S3。Cursor 用它为每个代码库建立独立的 S3 namespace，数千万 namespace 同时存在，不活跃的几乎零成本，整体降本 95%。Notion 在上面存储了 100 亿+ 向量，节省了数百万美元。

Quickwit：直接在 S3 上做全文搜索

Quickwit 证明了一个听起来不太可能的事情：可以直接在 S3 上执行全文搜索，而且速度很快。它用 Rust 基于 Tantivy（Rust 版 Lucene）构建，自定义了索引格式使得关键搜索路径仅需 3 次随机 seek，并通过一个 hot-start bundle 实现了 70ms 的 S3 冷启动。搜索节点完全无状态，任何实例可以应答任何查询。性能数据令人印象深刻：1PB/天的索引速度，50PB 数据上的亚秒级搜索。相比 Elasticsearch，存储成本节省 90%。Quickwit 于 2025 年初被 Datadog 收购。

InfluxDB 3.0：抛弃自研本地存储，全面转向 S3

InfluxDB 的重写是时序数据库领域最戏剧性的案例。InfluxData 彻底抛弃了自研的 TSM 存储引擎，用 Rust 从头重写，采用 “FDAP 栈”（DataFusion + Arrow + Parquet + Flight）。数据以 Parquet 文件存储在 S3 上，服务器完全无状态，在 Kubernetes 中以无状态 Pod 运行。存储成本比 2.x 版本降低了 75%。

ClickHouse Cloud：从本地磁盘到共享对象存储

经典的 ClickHouse 将数据存储在本地磁盘上，每个副本维护自己的完整数据拷贝——高性能，但扩缩容意味着大量数据迁移，多副本也带来高昂的存储成本。ClickHouse Cloud 用全新的 SharedMergeTree 引擎彻底改变了这一点：所有数据存储在共享对象存储（S3）上，计算节点不再持有数据副本，完全无状态。2025 年又构建了 Distributed Cache 层，让计算节点彻底摆脱本地磁盘依赖。扩缩容变成了加减无状态 Pod，不再有数据再平衡。

SlateDB：把 LSM-Tree 直接建在 S3 上

SlateDB 是一个用 Rust 编写的云原生嵌入式 KV 存储引擎，定位类似 RocksDB，但从零开始为对象存储设计。它将 LSM-Tree 的全部数据——MemTable flush 出的 SST 文件、索引、元数据——直接写入 S3，本地不保留任何持久化状态。通过批量写入降低 PUT 成本，通过内存 block cache + bloom filter + 本地 SST 缓存优化读取延迟。SlateDB 为有状态流处理、Serverless 函数、持久化执行等场景提供了一个极简的构建基元：嵌入你的进程，数据自动持久化到 S3，享受 11 nines 的持久性和无限存储容量。

Hydrolix：S3 上的实时日志分析，81 倍压缩比

Hydrolix 专注于极致的压缩和查询性能，所有数据存储在 S3 兼容对象存储上。它的 HDX 压缩引擎实现了 81 倍的典型压缩比（398 TiB → 4.91 TiB）。在 2025 年超级碗期间为 FOX 提供实时分析：峰值 17.4 GB/s 摄入（等效 1.4 PB/天），550 亿条记录，5-10 秒从数据产生到可查询。

为什么在 S3 上构建下一代基础软件

搜索引擎、向量数据库、时序数据库、OLAP、KV 数据库、可观测性——如此多不同品类的项目做出了同一个选择，背后一定有共同的驱动力。答案藏在传统数据系统的存储架构中。

本地磁盘：耦合之痛

传统数据系统——无论是 Kafka、Elasticsearch 还是 ClickHouse——都把数据存储在本地磁盘或挂载的块存储（如 AWS EBS）上。这种设计在单机时代运行良好，但在云原生时代却成了沉重的包袱。

计算和存储被锁死在一起。 你无法单独扩展计算能力或存储容量。需要更多的查询并发？你不得不增加节点，每个节点又带来一份数据副本。存储快满了？你要么加磁盘（如果还有槽位），要么加节点然后经历漫长的数据再平衡。

数据副本带来巨大浪费。 为了高可用，传统系统通常在本地磁盘上维护 3 个数据副本。这意味着存储 1TB 的有效数据，实际需要购买和管理 3TB 的磁盘空间。而这 3 份数据需要由系统自己负责同步和一致性维护——副本落后了要追赶，副本不一致了要修复，节点挂了要重新复制。你为存储的每一个字节付了三倍的钱，同时还要承担副本管理的全部运维复杂度。

节点故障恢复慢且不可预测。 一个节点挂了，新节点加入后需要从其他副本复制完整的数据，期间服务降级甚至不可用。数据量越大，恢复越慢——TB 级别的数据恢复动辄数小时。运维团队半夜被叫起来处理的那些事故，根源往往就在这里。

块存储：贵，且不够弹性

云上的块存储（EBS/Persistent Disk）解决了部分问题——至少单块磁盘不会因为硬件故障而丢数据。但它依然昂贵，而且容量需要提前规划。块存储和计算实例仍然是绑定关系——一块 EBS 只能挂载到一个 EC2 实例，计算和存储依然无法独立伸缩。

更尴尬的是数据冗余问题。块存储底层确实有自己的副本机制来保证单块盘的持久性，但这只是存储层的实现细节，并不能替代业务层对跨节点、跨可用区高可用的需求。Kafka 不会因为 EBS 底层有副本就不做 ISR 复制——它仍然需要在多个 broker 之间维护自己的数据副本来保证业务连续性。结果就是冗余被做了两遍：块存储底层做了一遍，业务层又做了一遍。你为冗余付了双份钱，却要自己承担应用层复制的全部复杂度。

先行者：Snowflake 的启示

这波“基于 S3 构建一切”的浪潮，很大程度上源于一个项目的成功示范——Snowflake。

2012 年，Snowflake 的三位创始人（两位来自 Oracle，一位来自 Vectorwise）问了一个问题：“果从零开始设计一个梦想中的数据仓库，它应该是什么样的？”他们的答案是：计算和存储必须彻底分离，数据存储在 S3 上，计算节点独立弹性伸缩。

这在当时是一个大胆的决定。2012 年的 S3 还是一个相当“残缺”的存储——没有强一致性（覆盖写后可能读到旧版本），没有条件写入，延迟也远高于本地磁盘。Snowflake 的做法是用精巧的工程设计绕开了 S3 的所有缺陷：

• 不可变文件：写入 S3 的微分区（micro-partition）一旦创建就永远不修改。UPDATE 一行数据不是改原文件，而是生成全新文件、在元数据中标记旧文件失效。这从根本上回避了 S3 覆盖写的一致性问题——因为根本不做覆盖写。
• FoundationDB 元数据层：哪些文件属于哪个表的哪个版本，全部由一个 ACID 事务型 KV 存储（FoundationDB）管理。Snowflake 从不依赖 S3 的 LIST 操作来发现文件，一致性和事务保证完全在自己的元数据层解决，S3 只负责可靠地存储和读取不可变文件。

2015 年正式发布，2020 年 IPO——这是当时最大的软件 IPO 之一。Snowflake 用商业上的巨大成功向整个行业证明了：计算存储分离、以对象存储为基底，不仅在技术上可行，而且能创造巨大的商业价值。 此后，越来越多的数据基础设施项目开始沿着同一条路前进——而它们画出的架构图，惊人地相似。

新范式：所有人都在画的同一张架构图

当你研究这些新一代项目的架构时，会发现它们几乎都在画同一张图：

核心思想极其简单：计算无状态，存储在 S3，中间加缓存。

各个系统在这个基础架构上做的差异化，主要是缓存策略和写入优化——因为 S3 毕竟有两个固有特性需要适配：首字节延迟较高（标准 S3 约 50-100ms）和按 API 调用计费（PUT/GET 都有成本）。

写入优化的共识做法是内存缓冲 + 批量 Flush。不是每条消息或每个 key 都立刻写入 S3，而是先在内存中缓冲，积攒到一定量再作为一个大文件 flush 到 S3——全程不需要本地磁盘。SlateDB 将 MemTable 批量 flush 为 SST 写入对象存储，InfluxDB 3.0 的 Ingester 在内存中缓冲后批量生成 Parquet 文件。

读取优化的共识做法是多级缓存。热数据留在内存，冷数据从 S3 读取。TurboPuffer 称之为“河豚效应”（Pufferfish Effect）——数据从 S3 的 ~500ms 膨胀到内存的 <10ms，越频繁访问的数据越快。ClickHouse Cloud 构建了 Distributed Cache 层，将缓存从单机内存扩展为集群级共享缓存，让计算节点可以完全无盘运行。

对象存储经济学：一个数量级的成本节省

这场迁移背后最强的驱动力，是一笔简单的算术。

以 AWS 为例，EBS gp3 块存储的单价是 $0.08/GB/月。但这只是起点——传统数据系统通常需要维护 3 个数据副本来保证高可用，实际存储成本变为 $0.08 × 3 = $0.24/GB。再考虑到块存储需要提前规划容量、预留空间应对增长，实际利用率通常只有 50% 左右，有效成本进一步翻倍：$0.24 ÷ 50% = $0.48/GB。

而 S3 标准存储的价格是 $0.02/GB/月。持久性（11 nines）和跨可用区冗余内建在这个价格里，不需要额外副本。容量按需使用，不存在利用率浪费。

$0.48 vs $0.02——仅存储一项，差距就是 24 倍。

但成本优势不止于存储单价。更深层的节省来自于架构简化：

• 无需跨 AZ 复制：数据只写入 S3 一次，S3 自身提供 11 nines 持久性和跨 AZ 冗余。而传统数据系统在 AWS 上的跨 AZ 复制流量往往是很大的隐性成本项。
• 无需容量预规划：S3 容量无限，按需付费。不再需要为峰值预留磁盘空间，不再有“磁盘快满了”的告警。
• 无需管理数据副本：计算节点无状态，不存储数据。增减节点不触发数据迁移或再平衡。
• 运维复杂度降维：无状态节点意味着故障恢复就是启动一个新 Pod。没有分区再平衡，没有副本追赶，没有一致性修复。

行业数据显示，基于 S3 的架构相比传统方案可以带来一个数量级的总成本节省。

代价与适用性：谈谈取舍

S3 架构并非没有代价。诚实地说，它引入了两个需要正视的取舍。

延迟

标准 S3 的首字节延迟在 50-100ms，远高于本地 SSD 的微秒级延迟。即使是 S3 Express One Zone，也只是降到了个位数毫秒，依然比本地 SSD 慢得多。

这意味着：如果你的核心需求是亚毫秒级延迟（如高频交易、游戏后端），纯 S3 架构目前还不是最优选择。

但对于绝大多数场景——数据管道、日志分析、可观测性、AI 向量搜索、流式计算——亚秒级的延迟完全在业务可接受的范围内，而精心设计的缓存策略还能将延迟进一步降低。TurboPuffer 的热查询 p50 仅 8ms，ClickHouse Cloud 通过 Distributed Cache 让查询体验接近本地磁盘。

各项目在延迟取舍上的选择，本身也构成了一个有趣的设计空间谱。有的项目接受数百毫秒延迟换取极致简单性和低成本，有的通过更复杂的多级缓存加速将延迟控制在更低水平，比如 Neon 用四层缓存确保查询不直接触及 S3，体验接近原生 PostgreSQL。

API 成本

S3 按 API 调用计费——PUT 约 $5/百万次，GET 约 $0.4/百万次。如果不加优化，高频小对象读写会导致 API 成本远超存储成本。

所有成熟的 S3 原生系统都通过批量化来解决这个问题：将多次写入合并为一次大文件上传（SlateDB 的 MemTable 批量 flush、InfluxDB 3.0 的 Ingester 批量生成 Parquet），将多次读取合并为一次大块 fetch（Quickwit 的 hot-start bundle、TurboPuffer 的 cluster 级 batch read）。

基于 S3 构建的挑战

需要强调的是，选择 S3 作为基底确实很大程度简化了底层存储的设计与实现，但是在 S3 上构建有竞争力的高性能数据系统也远比想象中困难。延迟特性、API 计费模型、一致性窗口、大小对象的性能差异——这些都需要精心设计和仔细权衡。缓冲策略怎么定、缓存层次怎么分、数据格式怎么选、故障恢复路径怎么走，每一个决策都直接影响最终的成本效益和系统可靠性。更关键的是，这些工程决策不能脱离具体的领域场景——搜索引擎的索引访问模式、时序数据库的写入特征、消息系统的消费模式，每个领域都有自己独特的约束和取舍。S3 提供的是一个极具潜力的基础设施原语，但把这个潜力转化为生产级的系统，既需要扎实的工程能力，也需要对领域问题的深刻理解和实战积累。

S3 自身也还在进化

值得关注的是，S3 本身仍在持续进化，每一次升级都为基于 S3 构建的系统打开新的可能性。

回想 Snowflake 在 2012 年起步时，S3 对覆盖写入和删除操作只提供最终一致性（eventual consistency）——覆盖写后可能读到旧版本，删除后对象可能仍然可见，LIST 操作可能遗漏刚写入的文件。Snowflake 不得不自建 FoundationDB 集群来管理元数据一致性，用不可变文件设计从根本上回避覆盖写问题。Netflix 在 2014 年写了 s3mper，用 DynamoDB 作为一致性校验层来弥补 S3 LIST 的不一致；AWS 自己为 EMR 做了 EMRFS Consistent View，Cloudera 为 Hadoop 生态做了 S3Guard——方案如出一辙，都是在 S3 前面加一层 DynamoDB 元数据来追踪文件状态。整个行业——包括 AWS 自己——都在为 S3 的一致性缺陷买单。

此后，S3 经历了三次关键升级：

• 2020 年：Strong Read-after-Write Consistency。 S3 开始对所有读取和列表操作提供 strong read-after-write consistency——写入或删除成功后，任何后续的 GET 和 LIST 都保证返回最新状态。上述所有 workaround 一夜之间变得不再必要。
• 2023 年：条件写入（Conditional Write）。 S3 引入了条件写入原语——只有在对象不存在或未被修改时才执行写入，否则返回失败。这让 S3 上可以直接实现乐观并发控制，许多场景下不再需要外部锁服务或共识协议。TurboPuffer 用一个 JSON 文件在 S3 上构建了分布式队列，Turso 依赖 S3 条件写入实现多区域 SQLite 协调。
• 2023 年：Express One Zone。 将首字节延迟从 ~100ms 降至个位数毫秒，让更多对延迟敏感的场景也可以构建在对象存储之上。

每一次升级都不只是性能参数的改善，而是 解锁了之前不可能的架构模式——read-after-write consistency 让 S3 能够作为 Source of Truth，条件写入让无外部协调的分布式系统成为现实，Express One Zone 让实时场景进入射程。S3 作为基础设施原语的能力边界还在持续扩展，基于它能构建的系统种类和场景也在不断拓宽。

写在最后

回看历史，存储能力的跃迁往往引发上层架构的重塑。硬盘带来了随机访问能力，使得数据不再只能顺序扫描，直接催生了关系型数据库和 B-tree 索引；SSD 将随机读延迟从毫秒级降到微秒级，IOPS 提升了几个数量级，让 KV 分离（WiscKey）、大规模并发随机读等之前在 HDD 上不实用的设计成为现实，催生了一批面向 SSD 特性优化的新型存储引擎。

而从块存储到对象存储，是一次更深层的变革。它改变的不仅是性能参数，而是存储的基本模型——容量从有限变为无限，冗余从应用层自建变为基础设施内建，成本从预置付费变为按需计量。这些变化叠加在一起，正在催生一代全新的无状态、弹性、低成本的数据基础设施。

Snowflake 在 2012 年率先证明了这个方向的可行性和商业价值。如今，数据库、搜索引擎、时序数据库、向量数据库、可观测性平台——一个又一个品类已经完成了向 S3 原生架构的转型。而 S3 自身还在持续进化，让这条路越走越宽。

变革已至：在杭州，见证消息流新范式

我们也在将同样的架构理念应用于消息系统领域。作为云原生消息基础设施的开拓者，EMQ 多年来不仅在思考如何构建一个更快的 Broker，更在试图重新定义计算存储分离在消息处理场景下的终极形态。

2026 年 3 月 20 日杭州，我们将在 EMQ Tech Day 上正式对外发布这一全新产品。

在现场，我们将深度拆解这款产品的底层架构，揭秘其如何通过彻底的计算存储分离架构，将 S3 的无限容量与极低成本引入消息领域，帮助用户告别昂贵的块存储与复杂的扩缩容数据再平衡，在享受极致性价比的同时，实现海量消息的无感弹性与无限留存。

有些未来，值得现场亲见。