原文标题: ACOS: Apple's Geo-Distributed Object Store at Exabyte Scale
会议: FAST '26
作者: Benjamin Baron, Aline Bousquet, Eric Metens, Swapnil Pimpale, Nick Puz, Marc de Saint Sauveur, Varsha Muzumdar, Vinay Ari（Apple）
摘要
过去二十年间，随着移动计算和互联网流媒体的兴起，Apple 的用户规模和服务范围显著扩大。伴随这一增长，数据存储的体量和种类急剧增加，涵盖备份、个人照片和视频，到音乐库、电视节目和直播流。本文介绍 ACOS——Apple 的对象存储系统，其设计旨在通过支持广泛的内容类型和访问模式，满足面向用户和内部服务的特定需求。ACOS 已在生产环境运行十余年，存储数十艾字节（EB）的对象，每天处理数十亿次请求。凭借同时采用本地复制和区域复制机制的地理分布式架构，ACOS 具备高成本效益、高可扩展性、高可用性和高持久性。对生产部署的评估展示了其吞吐量和延迟性能，以及对硬件和数据中心故障的韧性。本文呈现 ACOS 的设计与演进，评估其在生产环境中的性能，并展示其支持 Apple 当前存储需求和未来增长的能力。
1 引言
在 Apple 内部，iCloud、近年来的 Apple TV 等服务需要强健的存储基础设施。全球数亿用户每天依赖这些服务来创建、分享和消费各类数字内容。为此，Apple 需要一个能够以高成本效益和可扩展方式管理对象的地理分布式存储系统。
存储和服务这些对象面临独特的挑战。首先，系统必须高效处理对象大小的极端差异，从数十 KB 的小型元数据和缩略图，到数 GB 的大型视频。其次，Apple 用户规模的增长意味着存储数据量和请求速率的持续增加。这种快速增长放大了对可扩展系统的需求——该系统需要能够以最小开销无缝扩展容量和吞吐量，同时不造成性能下降或过高成本。最后，用户期望数据安全且始终可访问，这要求系统具备安全性、高持久性和高可用性。
需要存储大量对象的公司通常依赖大规模对象存储 [3, 6, 9, 10, 16, 28, 29]。为确保数据可用性和持久性，这些对象存储大量采用各种数据复制机制，包括全量对象复制以及纠删码（Erasure Coding）方案，如 Reed-Solomon 码和本地重建码（Local Reconstruction Codes, LRC）。虽然大多数对象存储部署在单一区域，但一些大型公司采用跨多个区域的地理复制 [9, 13, 28, 29]，以提供更高的可用性和持久性。
本文描述 ACOS 两个连续版本的设计与实现——Apple 的生产对象存储系统已运营超过十年，管理多个 EB 的数据，同时每日处理数十亿次请求。ACOS 支持多种数据类型，包括照片和视频等用户生成内容以及面向分析的内部数据集。该系统围绕三个主要目标进行设计：(i) 确保高可用性和数据持久性以维持不间断的数据访问并防范多种故障场景；(ii) 优化成本效益以经济地管理海量数据，同时保持较低的运营开销；(iii) 提供可扩展性以无缝应对存储需求和流量需求的持续扩张。
ACOS 1.0 通过利用本地复制和区域复制机制奠定了地理复制架构的基础，保证了所存对象的可用性和持久性。本地复制依赖分布式 (12,2,2) LRC [16]（近期改用 (20,2,2) LRC）确保对数据中心内磁盘、主机和机架故障的韧性。区域复制依赖全量对象复制确保对数据中心故障的韧性。ACOS 2.0 通过使用 XOR 编码增强了区域复制——这是一种比全量对象复制更节省存储的复制方案，使整体复制因子（Replication Factor）降至 1.5。凭借统一的部署架构，ACOS 2.0 能够无缝扩展至多 EB 级容量并支持 Apple 服务的持续增长。本文的主要贡献包括：
- ACOS 两代系统的设计——一个 EB 级地理复制对象存储，采用高效的两层编码（本地 LRC 加区域 XOR 校验）。
- ACOS 经过十年生产部署后的评估，包含两代系统的性能对比。
- 在两代系统之间无缝迁移数据、优化延迟以及大规模运营对象存储的经验教训。
本文其余部分组织如下：第 2 节详细介绍 Apple 内部不同的工作负载；第 3、4 节分别描述 ACOS 的两代设计与实现；第 5 节从请求延迟、持久性和可用性机制等维度对比两代系统性能，证明 ACOS 达成了设计目标；第 6 节讨论延迟优化、两代系统间的迁移以及可用性与持久性的成本权衡；最后第 7 节介绍相关工作，第 8 节总结全文。
2 工作负载
Apple 的终端用户使用 iCloud、Apple Maps、Apple TV、Apple Music 等具有多样化存储需求的服务。例如，用户可能在 iCloud 中存储照片，或正在收看 Apple TV 剧集。这些不同的使用场景构成了 ACOS 的工作负载——ACOS 直接或间接地为终端用户以及内部平台或服务提供内容服务。
ACOS 在 Apple 的数据中心运行，是将内容存储和分发给终端用户的云服务生态系统的一部分，如图 1 所示。ACOS 本身不提供缓存机制，但某些请求（如下载对象）可能经过内容分发网络（Content Delivery Network, CDN），因此只是间接与 ACOS 交互。其他请求（如上传照片等对象）则直接与 ACOS 交互。此外，一些网络接入点（Points of Presence, PoP）可能与 ACOS 交互，以在靠近终端用户的位置处理和服务延迟敏感内容，例如视频转码。
作为多租户系统，ACOS 旨在满足面向用户和内部工作负载的多样化需求，所有这些工作负载都要求高可用性和持久性。每种工作负载在上传（字节）、下载（字节）和删除（操作次数）方面具有特定的对象大小分布和访问模式，如表 1 所示。
iCloud 是 ACOS 的关键工作负载，需要存储大量终端用户内容，包括照片、视频、邮件和设备备份 [38]。吞吐量和延迟需求因内容类型不同而有所差异。例如，设备备份在设备端异步处理，对吞吐量和延迟要求较低；而照片，尤其是视频，则需要更高的吞吐量和更低的延迟。访问模式具有日间周期性，也随一年中的时间段变化，在各类内容的高峰期（如假期期间大量拍照时）出现峰值。在这些峰值事件之外，照片和视频在存储后立即有较高的下载和删除率，而备份的下载频率则相对较低。
Apple Music、Apple TV 等媒体服务通常存储数 GB 或更大的大型文件，需要将其分割成多个部分以实现高效的并发上传和存储。媒体服务存储的内容只增不减，不断添加新的媒体文件。内容从不被删除，且读取频率较低，因为这些服务使用 CDN 缓存内容以降低终端用户的延迟。
Apple Maps 包含各种内容，从地图和 3D 视图到分析工作负载，具有不同的访问模式。地图和 3D 视图位于 CDN 之后，因此下载频率较低，几乎从不删除；而分析工作负载则被频繁删除和下载。其他内部工作负载从分析任务到长期存储不等，因此具有广泛多样的访问模式。
Apple 内部对象存储源于在同一数据中心内以低延迟存储大量战略性数据的需求，涵盖法律文档、生产数据到媒体数据（包括图像缩略图）。这一初始需求推动了第 3 节介绍的 ACOS 1.0 的设计。然而，近年来为支持 Apple 不断增长的云服务而扩大存储容量的需求，催生了 ACOS 2.0——第 4 节介绍的统一且高成本效益的解决方案。
3 ACOS 1.0
ACOS 1.0 是 Apple 于 2013 年部署的第一代高可用、高持久性对象存储系统。它向内部服务暴露兼容 AWS S3 的 API。该存储系统在地理位置分离的两个区域以主主（active-active）配置运行，任一区域都能接受来自客户端应用的读写请求。系统将对象作为加密存储（encrypted-at-rest）的数据 blob 存储在磁盘上，并分布于存储层的众多节点中。
3.1 Store 概述
一个 Store（由两个 Stamp 组成的存储单元）由位于不同地理区域的两个 Stamp（独立存储服务单元）组成，每个 Stamp 是部署在数据中心的独立存储服务。Store 为客户端提供唯一的数据存储和检索端点。Stamp 由一组机架组成，包含计算主机和存储主机。计算主机运行 ACOS 1.0 应用程序，包括请求处理器（Request Handler）、协调器（Coordinator）应用、限速器（Rate Limiter）应用和负载均衡器（Load Balancer）。存储主机运行存储层，并与 JBOD（Just a Bunch of Disks，磁盘组）相连。图 2 展示了 Stamp 及其主要组件的布局。
不同的 DNS 端点指向特定的 Stamp 或两个 Stamp。DNS 负载均衡将客户端请求分发到各负载均衡器。负载均衡器面向公网，具有公网 IP，将流量均匀分配到 Stamp 内的所有请求处理器。每个负载均衡器作为公网 TLS 终止点，在将请求路由到请求处理器之前进行处理。这防止了直接服务器返回（Direct Server Return, DSR），因为请求处理器必须通过负载均衡器发送响应。请求处理器是无状态服务，接受 AWS S3 APIs [1] 的子集，负责校验和计算、加密/解密。请求处理器对照认证系统验证请求签名，并对照限速器应用验证客户端配额。限速器是一个分布式服务，通过强制执行每客户端速率限制来保护 Stamp 各组件。
请求处理器连接到存储层以存储和检索客户端对象。存储层负责向磁盘写入和从磁盘读取数据，通过纠删码提供 Stamp 内复制。协调器应用负责数据放置、检测存储层中不健康的节点，以及发起和管理修复和垃圾回收流程。最后，元数据（Metadata）系统持久化对象元数据，包括其在存储层节点内的位置、复制状态以及客户端应用特定信息。元数据系统由 Apache Cassandra [39] 支撑。
ACOS 1.0 各应用程序之间的连接使用 TLS 加密，每个应用程序维护到其他应用程序的连接池。这避免了重复建立连接，最大程度减少了引入高 CPU 开销和网络延迟的 TLS 握手次数。
3.2 存储层
存储层提供有状态的持久数据存储，部署在专用存储主机上，每台主机连接到由 HDD 组成的 JBOD。
对象以 blob 形式与部分元数据和校验和一起存储在容器（Container）中。一个对象由客户端应用标识符、Bucket 和路径的组合唯一标识。客户端应用可以不分片地上传单个对象，也可以逐部分上传多部分对象。请求处理器通过将大于单个容器的任意大小对象透明地分割成固定大小的部分来处理它们（实践中，最大部分大小设为 64 MiB）。这些部分随后存储在容器中，对客户端应用屏蔽了底层存储机制。
容器是一个大型文件（4 到 32 GiB），容纳多个对象。容器被归组在集群（Cluster）内，如图 3 所示。集群中的每个容器最初被五路复制（图 3a）。来自客户端 PUT 操作的对象被写入复制集群，直至其达到容量上限，随后进行封存（Sealing）流程。封存流程删除数据容器的副本，并生成校验（Parity）容器，使用本地重建码（LRC）纠删编码 [16] 创建封存集群（图 3b）。(12,2,2) LRC 由为组织在两个条带（每个条带六个数据容器）中的 12 个数据容器生成两个本地校验容器和两个全局校验容器组成。封存流程完成后，集群中的所有容器对写操作不可变。复制集群在包含已删除对象时被封存，以考虑删除宽限期。作为 Stamp 内复制机制，(12,2,2) LRC 编码可以在 86.15% 的情况下恢复每个集群四个容器故障，在其余情况下恢复三个容器故障。ACOS 1.0 最初使用 (12,2,2) LRC 编码布局进行 Stamp 内复制。为进一步降低复制因子，后来引入了 (20,2,2) LRC 来存储新对象。
接收客户端请求的请求处理器将对象以 256 KiB 大小的数据块流式传输到复制容器。复制容器使用基于 ZAB [34] 的自定义分布式事务日志进行数据流传输，但使用 Raft [30] 算法进行 Leader 选举，并有专为对象存储服务优化的特性：(i) 最小化多块对象的刷盘次数；(ii) 跟踪中止的部分写入对象。Leader 副本接收来自请求处理器的数据块，将每个块写入其事务日志文件，同时将块转发给其他四个副本。每个副本将事务日志文件刷盘。一旦法定数量的副本存储了完整对象，Leader 通知请求处理器，后者在完成请求前将包含对象位置的元数据持久化。
3.3 容器生命周期
协调器应用编排集群的整个生命周期，从在磁盘上创建和放置，到垃圾回收以及数据修复。
放置（Placement）。 协调器应用运行放置流程，持续创建复制容器集群作为对象写入的目标。该流程维持稳定数量的可写集群以适应输入数据的速率。为最大化可用性和持久性，放置流程考虑故障域，将特定集群的容器放置在不同的磁盘、主机和机架上，从而降低硬件故障的影响。为最大化磁盘吞吐量，放置流程确保容器均匀分布在所有磁盘上。
压缩（Compaction）。 接收到删除请求后，请求处理器在对象元数据中设置墓碑（tombstone）。对象宽限期过后，该对象被视为已删除。随着对象被删除，协调器应用运行垃圾回收流程——压缩（Compaction）来回收空间。协调器应用定期识别待压缩的集群，按已删除数据量排序，并为已删除数据最多的集群调度压缩任务。存储应用随后启动压缩。存储应用将容器重写到新文件，跳过已删除的对象。完成后，存储应用使用 LRC 纠删编码重新计算校验容器，类似于封存流程。
修复（Repair）。 在集群的整个生命周期内，存储层中的磁盘会发生故障，产生数据持久性风险。为降低这一风险，集群需经历类似封存流程的修复过程，在不同磁盘上重建丢失的容器数据。容器故障的两大主要原因是：(i) 硬件故障；(ii) 数据损坏。
针对硬件故障的修复发生在磁盘、主机或机架宕机时。每个进程定期响应来自协调器应用的健康检查请求。一旦从存储应用检测到故障，协调器应用在 30 分钟宽限期后触发修复，以避免在主机重启或软件发布等瞬态故障事件中进行不必要的修复。
针对数据损坏的修复对应磁盘故障，通常由磁盘年化故障率（Annual Failure Rate, AFR）来量化。系统有多种定期持久性机制来检测磁盘数据损坏：(1) 异步进程扫描所有元数据，对照元数据中存储的对象校验和验证完整的对象完整性；(2) 存储应用上的另一进程扫描磁盘上的每个容器并验证段（Segment）校验和。一旦检测到磁盘故障，容器立即被修复。
3.4 数据可用性
每个 ACOS 1.0 Store 依赖两个 Stamp 进行数据冗余，为客户端数据提供更高的可用性和持久性。为确保 Stamp 故障时的数据可用性，每个 Stamp 中的存储应用持续将存储的客户端数据异步复制到另一个 Stamp。在此异步过程中，存储应用扫描磁盘上所有已存储的容器，将所有待复制的对象写入另一个 Stamp。一旦对象完成复制，存储应用便以复制后的对象位置更新其元数据。这一复制流程使我们能够通过将 Stamp 设置为故障转移（failover）状态来执行 Stamp 级别的维护操作。处于故障转移状态时，Stamp 将所有客户端请求代理到另一个 Stamp，确保数据持续可用。
处理客户端 GET 请求的请求处理器同时利用基于 LRC 的 Stamp 内复制和跨 Stamp 的异步复制。请求处理器首先尝试从容器中检索数据。在发生故障或超时的情况下，请求处理器执行降级读（Degraded Read），尝试从不同来源读取对象。它首先尝试利用本地 LRC 校验然后全局 LRC 校验解码对象数据。作为最后手段，请求处理器回退到从另一个 Stamp 检索对象，并返回对象或在失败时返回错误。在每个潜在数据源被启动时，已有来源继续运行，对象数据一旦可用即立即流式传输回客户端，无论来源为何。
3.5 局限性
尽管 ACOS 1.0 已有十年生产使用经验，但其可扩展性受到若干因素的严重制约，具体表现为存储成本高、Store 生命周期复杂难管理、以及元数据系统难以同时提供强一致性和高性能。
存储成本高。 ACOS 将全量跨 Stamp 复制与 (20,2,2) LRC 编码相结合，整体复制因子为 2.40。利用 Apple 基础设施的全部潜力，在不同地理区域的多个数据中心间采用更高效的编码方案，可进一步降低复制因子。
Store 生命周期。 由于 Store 具有固定的、独立的存储容量，客户端资源可能跨越多个 Store，使客户端难以管理多个端点、凭证、容量预留以及配额。停用老旧 Store 需要逐对象迁移到另一个 Store，这是一个缓慢而复杂的操作，涉及繁琐的配置和验证步骤。
全局可扩展性。 ACOS 1.0 中使用的元数据系统存在若干局限，如热点（hot-spotting）、LIST 操作性能低下、缺乏操作谓词支持以及跨 Stamp 一致性不足。这些局限使得 ACOS 难以扩展为跨多个数据中心的统一数据存储系统。
4 ACOS 2.0
ACOS 2.0 是 ACOS 1.0 的演进版本。它提供统一端点，减轻运维负担，同时通过将数据复制因子从 2.40 降至 1.50 来降低每字节存储成本。凭借可扩展的设计，ACOS 2.0 允许对客户端应用透明地添加存储容量和吞吐量。表 2 和图 4 总结了 ACOS 1.0 和 2.0 之间的主要差异。
ACOS 2.0 保留了第 3 节介绍的基于 Stamp 的结构，并将其扩展到多区域部署架构。在当前生产部署中，ACOS 2.0 跨越五个区域，靠近客户端工作负载。一个区域是托管在数据中心中的一组 Stamp。一个 Stamp 可以存储约 500 PiB（拍字节）的原始数据。
4.1 跨区域分段
与 ACOS 1.0 在 Store 的两个 Stamp 之间完全复制数据不同，ACOS 2.0 将所有对象分割成四个连续等大小的数据段，并通过对所有数据段进行按位 XOR 操作计算一个校验段。此操作允许客户端处理器从其他四个段重新生成任意段（包括校验段）的任意部分。这种对象分段方式使复制因子达到 1.5，同时确保在单个区域发生故障时的高可用性，代价是首字节时间（Time to First Byte, TTFB）有所增加。我们在第 4.3 节提供了更多关于复制因子计算的详细信息。
如图 5 所示，客户端处理器将来自 PUT 请求的传入对象分割成数据段和校验段，分发到部署中每个区域的区域段处理器。每个 PUT 请求（包括分块编码请求）必须在请求头中提供对象长度，以便在分段之前确定每个段的大小。接收段的处理器将其段发送到存储层，存储在复制容器中。
对于多部分对象，ACOS 2.0 将每个部分视为完全独立的对象，与 ACOS 1.0 的机制相同。ACOS 2.0 将每个部分分割成段。提交操作生成包含所有关联部分段位置的元数据。
客户端处理器通过获取所有四个数据段来处理完整对象的 GET 请求。如果某个段暂时不可用，客户端处理器使用校验段和其余数据段重建该段。这使 ACOS 2.0 能够在部分部署中断的情况下仍能处理 GET 请求。
对于对象范围的部分读取 GET 请求，客户端处理器首先尝试读取对应请求范围的数据段。例如，对于 100 字节的对象，每个段为 25 字节分布在所有五个区域。当客户端请求该对象的前 10 个字节时，客户端处理器只会获取第一个数据段的前 10 个字节。但如果该段不可用，则客户端处理器获取每个剩余段的前 10 个字节以重建请求范围。
4.2 一致性元数据系统
将段分布到各个区域需要一个保证跨区域强一致性的元数据系统。当客户端 PUT 请求进入区域 A 时，在任何其他区域处理客户端 GET 请求的客户端处理器必须能够立即访问该元数据。
ClassVI 是我们自研的元数据系统名称，类似于支撑 ACOS 2.0 的 BigTable [5]。它以 RocksDB [25] 作为本地存储引擎。ClassVI 与 ACOS 2.0 部署在相同的区域，每个区域均包含元数据副本，以确保与用户数据相同的持久性，并提供对元数据的低延迟访问。
虽然 ClassVI 不提供多行分布式事务保证，但它使用 Raft 共识算法维护所有行级读写操作的强一致性。为改善延迟，ClassVI 允许对本地区域中的单个副本执行读操作。然而，这种性能优化以单副本读的最终一致性为代价。
当客户端 PUT 请求完成所有段的存储后，客户端处理器将包含所有段位置的对象元数据写入 ClassVI。段位置包含在磁盘上定位存储数据所需的所有信息，包括集群标识符、容器索引以及对象在该容器内的偏移量。
当客户端处理器收到客户端 GET 请求时，处理器从 ClassVI 检索对象元数据，并根据段的可用性，将每个包含的段位置发送给段处理器以获取所需的段。
4.3 高可用性系统
ACOS 1.0 为客户端 GET 请求提供强可用性保证，能够承受一个 Stamp 内每个容器集群最多四个节点故障，甚至整个区域故障，具体机制包括 Stamp 内的降级读和跨区域副本。如第 3 节所述，这些机制使复制因子达到 2.40。
ACOS 2.0 能够处理单个区域故障，使得仍可使用校验段处理客户端 GET 和 PUT 请求。如果两个或更多区域不可用，则无法处理需要不可用段的客户端 PUT 或 GET 请求，此时客户端处理器向客户端返回错误。在此降级模式下，客户端处理器仍可处理仅涉及元数据系统的请求，因为这些请求不需要在存储层存储或获取任何客户端数据。
当数据段不可用时，客户端处理器可通过使用 XOR 操作处理客户端 GET 请求。客户端处理器可以通过获取其余四个段（即三个数据段和一个校验段）来重建任何缺失的数据段。
对于客户端 PUT 请求，客户端处理器将段请求发送到所有目标区域，如果至少四个段成功存储则完成请求。客户端处理器仍会尽力尝试在客户端 PUT 请求处理过程中存储最后一个段，如果尝试成功，则更新对象元数据中的段位置。
每个存储应用都有一个进程，异步迭代容器以识别缺少段的对象。该进程 (i) 从元数据系统检索对象的可用段位置，(ii) 获取段数据，(iii) 使用 XOR 操作重新生成缺失的段数据，(iv) 将生成的段存储在远程区域中。为最小化获取段的开销，该进程仅在五个区域中的两个上运行，这保证了段的存在。为进一步最小化此异步复制流程的开销，客户端处理器在处理客户端 PUT 请求时始终尝试存储所有段。如果某个段存储时间过长（例如目标存储主机遇到网络问题或磁盘问题），客户端处理器完成请求，复制流程异步重新生成剩余段。
4.4 多租户可扩展设计
在 ACOS 1.0 中，当大型客户端应用需要扩展其容量超过单个 Store 的容量时，必须在多个 Store 中申请容量。这对客户端来说是一大痛点，因为他们不得不处理多个端点、凭证、速率限制。此外，数据管理（例如在 Store 间均衡、移动和复制数据）由客户端负责。
ACOS 2.0 的一项重大改进是其统一端点——存储和检索数据的唯一入口点。该端点是一个 DNS 记录，提供指向部署内负载均衡器公网 IP 地址的 A 记录。我们的内部 DNS 权威服务器动态计算负载均衡器的 IP 地址，以最小化客户端与负载均衡器之间的网络延迟。例如，如果客户端想从区域 A 向 ACOS 2.0 发送请求，DNS 权威服务器将提供区域 A 中负载均衡器的 IP 地址。我们通过向主端点 DNS 记录添加或删除负载均衡器 IP 地址的 A 记录，来反映部署中的变化（例如添加或删除 Stamp）。
随着部署的可扩展性，每个区域的 Stamp 数量在部署生命周期内不断增长。因此，较旧的 Stamp 将比较新的 Stamp 先填满数据。ACOS 2.0 有多种机制来平衡所有 Stamp 上的数据，以实现磁盘 IOPS 和已用空间方面的均匀资源利用率。
在客户端 PUT 请求期间选择 Stamp 时，客户端处理器使用权重来确定每个段的目标 Stamp。在每个 Stamp 上，一个异步定期任务计算可用磁盘容量并将信息报告给协调器应用。一个独立服务汇聚磁盘容量信息并为每个区域推导 Stamp 权重。
除 Stamp 权重外，ACOS 2.0 还采用再平衡器（Rebalancer）服务，在区域内的 Stamp 之间移动现有数据。再平衡器将已封存数据容器和校验容器的文件级副本发送到目标 Stamp 中的目标存储节点。由于避免了事务日志写入的磁盘 I/O 和容器封存期间纠删码的 CPU 开销，这是跨 Stamp 移动数据最快且 I/O 强度最低的方式。我们需要再平衡器来处理部署中 Stamp 的上线和下线：再平衡器可以将数据从较旧的 Stamp 移动到较新的 Stamp，清空较旧的 Stamp 或释放容量以平衡请求和存储数据的负载。
最后，ACOS 2.0 中的限速器采用了新架构，包含两个限速器服务：(i) 对象分段前使用的部署级限速器；(ii) 对象分段后使用的 Stamp 级限速器。这些服务类似于第 3.1 节中描述的 ACOS 1.0 限速器应用。部署级限速器通过在每个 Stamp 中部署实例来执行预定义的客户端应用速率限制，保护整个部署免受负载突增的影响。Stamp 级限速器通过限制客户端和内部流量操作（包括客户端请求和异步段复制）来保护每个 Stamp 的存储资源。
5 生产结果
本研究通过一系列测量来评估两个在线生产系统 ACOS 1.0 和 ACOS 2.0 的性能。由于两个系统都是地理复制的，本次评估重点比较关键性能指标，特别是请求延迟、持久性和可用性机制。我们从跨所有主机的一个月实时流量中收集结果，捕获大量真实工作负载以确保研究发现的统计显著性。
5.1 请求延迟
我们的评估使用两个服务端请求指标。
-
首字节时间（TTFB）。从收到传入的客户端 GET 请求到向客户端发送响应第一个字节的时间。这包括元数据操作延迟、磁盘上读取第一个字节的时间以及传输第一个字节的网络时间。
-
完整对象延迟。从收到传入客户端请求到向客户端发送响应最后一个字节的时间。这涵盖元数据操作延迟、磁盘上读取或写入数据的时间以及传输数据的网络时间。
虽然我们在服务端测量指标，但在接收数据或在客户端处理器与客户端之间传输响应时，客户端对完整对象请求延迟可能有显著影响。我们测量客户端 GET 请求的 TTFB，因为该指标与对象大小以及客户端和我们的出口网络吞吐量限制无关。
由于 ACOS 1.0 到 ACOS 2.0 的迁移，主要工作负载已迁移到 ACOS 2.0，这解释了两个系统之间客户端应用数据的一些差异。特别地，图 6a 提供了 ACOS 1.0 和 ACOS 2.0 中 PUT 和 GET 请求对象大小（字节）的累积分布函数（CDF）。在两个系统中，GET 请求的对象大小均小于 PUT 请求，因为工作负载使用范围读取请求来检索对象的子集。然而，ACOS 2.0 中 GET 和 PUT 请求之间对象大小的差异更大，这是由于工作负载迁移的结果。
在图 6 中，我们还提供了比较两个系统性能的请求延迟和 TTFB 指标。图 6b 显示两个系统之间的 GET 请求 TTFB 相似，ACOS 2.0 的 TTFB 略大。观察到的差异主要是由于 ACOS 2.0 中对象段的分布式特性——由于客户端位置和请求范围，我们可能需要在返回 GET 请求第一个字节之前获取远程段。在 ACOS 2.0 中，99.99995% 的请求中，获取元数据只需要非一致性读取，与 ACOS 1.0 没有延迟差异。我们在第 6.2 节提供了更多关于延迟优化（包括元数据预取）的详细信息。
在图 6c 和 6d 中，我们比较了 ACOS 1.0 和 ACOS 2.0 对两种代表性对象大小（1 MiB 和 10 MiB）的完整对象 GET 和 PUT 请求。PUT 对象请求的延迟在 ACOS 1.0 和 ACOS 2.0 之间相似，因为在两个系统中，客户端处理器都直接将客户端数据流式传输到复制容器。在 ACOS 2.0 中，客户端数据的服务端缓冲允许客户端处理器并行发送 PUT 段请求。相反，ACOS 2.0 的 GET 请求延迟更大，这是因为需要时间从远程区域获取所有段数据，两个系统之间观察到的 50 ms 延迟差异对应于两个区域之间的平均网络延迟。
5.2 持久性和可用性
在图 7 中，我们测量了不同可用性和持久性机制的性能，以及对 ACOS 1.0 和 ACOS 2.0 的 GET 请求延迟的影响。
在 ACOS 1.0 和 ACOS 2.0 中，区域间的数据复制都保证了系统在区域故障时的持久性和数据可用性。ACOS 1.0 的复制过程对每个对象异步进行，而 ACOS 2.0 在 99.99% 的情况下复制作为 PUT 请求流程的一部分完成。因此，异步复制过程仅涉及 0.01% 的对象，其中 99.8% 在复制容器中，其余 0.2% 在封存容器中。图 7a 显示两个系统的复制滞后（Replication Lag）CDF，即 PUT 请求完成与对应复制过程成功运行之间的时间差。在 ACOS 1.0 中，复制过程在对象存储在一个 Stamp 后立即开始，90% 的对象在 10 秒内完成。从图中可以看出，由于需要异步复制的段很少，ACOS 2.0 中的段复制滞后比 ACOS 1.0 中的对象复制滞后小几个数量级，这体现了 ACOS 2.0 在持久性方面的主要优势之一。
图 7b 显示了跨区域可用性机制对 ACOS 2.0 完整对象 GET 请求延迟的影响：(i) 无段重建，(ii) 有段重建，(iii) Stamp 故障转移期间的段重建。区域间的段重建在 p90 处产生 0.3 ms 的计算开销。无 Stamp 故障转移的重建显示 GET 延迟增加 10 毫秒。另一方面，Stamp 故障转移期间的段重建对高于 p60 的百分位数的 GET 延迟影响最高达 50 毫秒，这是因为客户端处理器需要从更远的区域获取段，导致更大的数据中心间延迟。
图 7c 显示了 Stamp 内可用性机制对 ACOS 2.0 段 GET 请求延迟的影响：(i) 使用校验容器重建不可用封存数据容器的降级读，(ii) 从封存数据容器读取，(iii) 从复制容器读取。LRC 重建的计算开销在 p90 处为 2 ms。使用封存数据容器和校验容器的降级读在 p50 以下显示段 GET 延迟增加 30 ms，在 p50 以上显示更大的增加（数百毫秒）。在使用校验重建段数据时，LRC 机制优先使用本地校验，并在配置的 500 ms 超时后回退到全局校验。这会影响高于第 75 百分位的请求。
6 讨论
本节讨论我们在大规模运营存储系统超过十年过程中遇到的挑战，包括系统间大量数据的迁移、性能考量，以及可用性和持久性的权衡。
6.1 从 1.0 到 2.0 的迁移
随着 ACOS 2.0 作为 ACOS 1.0 替代品的引入，我们需要将数据迁移到新部署。虽然部分客户端自行管理迁移，但我们承担了在多个 Store 中转移剩余数据的大规模工作。我们按以下连续阶段规划了迁移。
-
客户端应用迁移。 将客户端特定信息传输到目标部署：凭证、配置参数、速率限制和存储配额。
-
对象迁移。 使用基于存储应用的流程将单个对象异步传输到目标部署。此流程类似于第 3.4 节描述的复制过程，将每个对象发送到新部署，按第 4.1 节描述的方式存储为段。对象迁移在源 Store 仍在处理客户端请求时进行。
-
对象验证。 验证迁移数据完整性的异步存储应用流程。它通过计算和比较校验和以及验证元数据字段，确认每个对象的数据和元数据正确传输到目标部署。
-
请求代理。 一旦所有现有对象完成迁移，源 Store 的客户端处理器将客户端请求重定向到目标部署的请求处理器。在此阶段，对象迁移和验证流程继续在源 Store 上运行，处理新摄入或修改的对象。
-
DNS 切换。 一旦对象迁移和验证完成，我们更新客户端面向的 Store 端点的 DNS 配置。这涉及将 CNAME 记录从源 Store 的 DNS 域修改为指向目标部署的 DNS 域。
此次迁移历时数年，迁移了数个 EB 的数据。整个过程对客户端应用透明，没有停机时间，同时继续处理客户端请求，并在任何时间点保证数据的可用性和正确性。
6.2 延迟优化
由于 ACOS 2.0 的地理分布式架构，与前一系统相比，我们观察到完整对象的 GET 请求延迟和 TTFB 有所增加。在迁移之前，我们致力于将服务端延迟降低最多 60%，客户端延迟降低最多 87%，以最小化工作负载从 ACOS 1.0 迁移到 ACOS 2.0 时的延迟影响。我们在客户端 GET 请求的三个不同阶段进行了改进：DNS 地理路由、元数据预取和段区域偏好。
DNS 地理路由（DNS geo-routing）。 使用 DNS 地理路由将客户端请求路由到五个 ACOS 2.0 数据中心中最近的一个。这确保了客户端到我们服务器的最短路径，但导致各区域之间的流量不均衡。只要所有区域都能处理其流量，我们允许这种不均衡存在。当某区域流量接近预定阈值时，DNS 系统的安全机制会将多余流量路由到其他区域。除了 ACOS 2.0 的通用端点外，我们还为延迟敏感流量配置了一个端点，预留给特定低流量用例，不受安全机制影响。我们还为非延迟敏感流量配置了一个端点，用于以轮询方式在各区域间均衡流量。
非一致性元数据读取后的预取（Prefetch after inconsistent metadata read）。 除一致性读取外，ClassVI 还提供快速的非一致性读取，由同一数据中心内的副本提供服务，在第 99.9 百分位的延迟为个位数毫秒。由于对象元数据仅在客户端 PUT 请求和再平衡期间发生变化，且 ClassVI 快速传播更新，非一致性读取在大多数情况下返回正确的元数据。我们利用这一点乐观地从磁盘预取数据：收到客户端 GET 请求时，请求处理器立即触发一致性和非一致性元数据读取。当非一致性元数据读取完成后，触发段读取。当一致性元数据读取稍后完成时，请求处理器比较两个元数据。如果匹配，则开始向客户端流式传输数据。如果不匹配（目前约 0.001% 的请求会发生这种情况），请求处理器丢弃预取的数据，并使用正确的元数据发送段 GET 请求。
段区域偏好（Segment regional preference）。 读取对象时，请求处理器可以选择对象五个段中任意四个的组合。我们的数据中心相距数百至数千英里，位于北美大陆的两侧。与其随机选择四个段，请求处理器会选择位于网络往返时间最小的数据中心中的段。在大多数情况下，这意味着将读取校验段并需要进行 XOR 重建。这有少量 CPU 开销，但避免了缓慢的跨国网络传输。
6.3 负载均衡器绕过
ACOS 2.0 因对象分段而实现的 Stamp 间吞吐量增加，暴露了现有负载均衡基础设施的瓶颈。具体而言，Stamp 负载均衡器无法处理放大的流量。
面对这一限制，以及受成本和数据中心空间的约束，涉及添加负载均衡器和机架顶部交换机的硬件解决方案被认为不可行。因此，我们采用了针对 Stamp 间通信绕过负载均衡器的策略，这减少了这些组件上的流量。绕过负载均衡器有一些缺点，因为请求处理器不得不重新实现负载均衡器提供的一些功能，例如健康监控或处理到服务请求处理器实例的大量连接。尽管增加了这些复杂性，绕过负载均衡器带来了客户端请求延迟的降低：p50 改善 22%，p90 改善 32%，p95 改善 26%。
6.4 持久性和可用性权衡
我们在下面描述持久性、可用性和复制的模型和假设，在表 3 中针对不同 LRC 编码和布局组合进行了总结。该表突出了实现更高持久性和可用性与因数据复制产生的存储成本开销之间的权衡。
持久性。 计算和比较存储系统持久性的经典方法是从马尔可夫链模型推导出数据丢失平均时间（Mean-Time-To-Data-Loss, MTTDL），由 Gibson [11] 引入并在许多工作 [9, 15, 16, 18, 36] 中复现。图 8 显示了两个 MTTDL 马尔可夫链模型：(i) Stamp 内集群中 (20,2,2) LRC 的本地模型；(ii) XOR-5 的区域模型。MTTDL 被定义为从初始状态到数据丢失（Data Loss, DL）状态的平均时间，即 XOR-5 为 4，(20,2,2) LRC 为 24。在两个模型中，设 λ 表示单个容器或段的故障率，ρᵢ 表示从一个缺失容器或段到健康状态的修复率。
在本地模型中，状态表示可用容器（数据/校验）的数量。故障率 λ 对容器故障建模，而 ρᵢ 对已故障容器的检测和修复建模。(12,2,2) 和 (20,2,2) LRC 以概率 pd = 0.8615 恢复四个故障容器，以概率 (1-pd) 恢复三个 [16]。容器故障源于硬件故障和数据损坏（第 3.3 节）。
为简单起见，模型假设故障率 λ 服从指数分布，这是一种常见近似 [9]，尽管现实中年化故障率（AFR）存在变化 [18]。它还假设由于容器跨机架放置导致的故障不相关，从而降低了共享机架级故障的影响。模型聚焦于封存集群，因为存储临时数据的复制集群影响可忽略不计。修复时间使用指数分布建模，假设跨机架带宽不限制修复。
在区域模型中，每个状态表示可用段或对象的数量（对于 ACOS 1.0）。λ 是从本地模型 MTTDL 推导出的故障率，代表区域内 LRC 保护失败。ρᵢ 结合了本地模型的容器修复率和区域间的对象复制率。例如，在 XOR-5 中，初始状态 s4（四个区域中的四个段）在 ρ4 率下转换到 s5，此时第五个段完成复制。
我们使用典型参数来计算系统的持久性。本地模型使用保守故障率 λ = 0.02，相比 Backblaze 的 1.35% 平均磁盘 AFR [2] 和 ACOS 观测值。区域模型使用 λ = 1/MTTDLlocal。两个模型都使用修复率 ρᵢ = ρ = 1/T，T = 365.25 天，用于容器/段的检测、修复或复制，类似于 [9]。表 3 显示了年度 MTTDL 值。ACOS 1.0 的 (12,2,2) LRC 与 ACOS 2.0 XOR-5 的 (20,2,2) LRC 相比，实现了更好的持久性，同时满足"11 个 9" SLA [1]。
可用性。 对定期健康检查的响应能力定义了一个区域的运行状态；如果区域无法响应，则认为该区域不可用，直到响应能力恢复。如果两个或更多区域同时不可用，ACOS 将转换到不可用状态。我们对多区域可用性建模，假设每个单独区域的目标可用性为 Ar，例如 Ar = 0.99999 对应 99.999% 服务级目标（SLO），即"五个 9"。单个区域的相应不可用性为 1-Ar。
假设区域故障在构成系统的 N 个区域（例如 ACOS 1.0 的 N = 2，ACOS 2.0 的 N = 5）中是独立事件，并发不可用区域数 k 服从二项分布。我们区分降级和不可用状态。
降级状态： 如果恰好有一个区域不可用（即 k = 1），则系统被视为降级。此状态影响对非完全复制对象的访问，并积累需要复制到不可用区域的对象和段的积压。降级概率 Pdegraded 由公式 (1) 给出：
P_degraded = P(X=1) = C(N,1) × (1-Ar)¹ × Ar^(N-1) (1)
不可用状态： 如果两个或更多区域同时不可用（即 k ≥ 2），则系统被视为不可用。在此状态下，客户端无法访问其数据，也无法存储新对象。不可用概率 Punavailable 是公式 (2) 给出的 k = 2 到 N 的概率之和：
P_unavailable = P(X≥2) = Σ(k=2 to N) C(N,k) × (1-Ar)^k × Ar^(N-k) (2)
表 3 给出了降级和不可用状态的年度持续时长。随着存储数据所用区域数的增加，年度降级和不可用持续时长也随之增加。
复制。 回顾 ACOS 通过在不同层次使用复制机制来为客户端请求提供高可用性，具有不同的复制因子：(i) Stamp 内的本地复制，复制因子为 RFlocal；(ii) 跨区域的区域复制，复制因子为 RFregional。ACOS 的整体复制因子为 RF = RFlocal × RFregional。
本地复制使用 (k, l, r) LRC，由 l + r 个校验容器和 k 个数据容器组成，整体复制因子为 RFlocal = (k + l + r) / k。在我们的案例中，ACOS 1.0 使用的 (12,2,2) LRC 和 ACOS 1.0 及 2.0 使用的 (20,2,2) LRC，复制因子分别为 1.33 和 1.2。
区域复制在两个系统中有所不同。ACOS 1.0 使用全量对象复制，复制因子 RFregional = 2。相比之下，ACOS 2.0 使用按位 XOR 复制，仅含单个校验段，复制因子 RFregional = N / (N-1)，其中 N 为区域数，例如 RFregional,XOR-5 = 1.25。
表 3 给出了整体复制因子。ACOS 2.0 的复制因子低于 ACOS 1.0，这影响了其降低存储成本的设计。使用更多存储区域，复制因子下降，直接降低了每字节成本。对于 Apple 的 ACOS 2.0，综合考虑工作负载对持久性和可用性的要求、数据中心位置限制以及成本因素，我们选择将 (20,2,2) LRC 编码与 XOR-5 布局配合使用。
7 相关工作
ACOS 建立在数十年分布式存储系统的基础上，从基础文件系统到现代地理复制对象存储，并融合了纠删码和元数据管理等领域的进展。
生产对象存储。 对象存储从基于云的商业产品到开源和内部部署各有不同。商业解决方案如 Amazon S3 [1]、Google Cloud Storage [12]、Azure Blob Storage [26]、IBM Cloud Object Storage [17] 和 Oracle Cloud Infrastructure Object Storage [31] 提供按需付费的存储，可从字节扩展到拍字节。MinIO [27] 和 Ceph [41] 是本地拍字节级部署的开源替代方案。多家公司描述了与 ACOS 类似的内部对象存储。LinkedIn 展示了 Ambry [29]（地理分布式、不可变对象），Yahoo! 描述了 Walnut [6]（统一云对象存储）。Google 文件系统（GFS）[10] 是 Google Cloud Storage (GCS) [14] 的前身，在商用硬件上展示了可扩展存储。微软的 Windows Azure Storage [4] 是通用对象存储服务。Meta 的存储从 Haystack [3]（小型照片）演进到 f4 [28]（温数据，纠删码）和 Tectonic [32]（统一 EB 级），突显了大规模挑战。与 Tectonic 类似，ACOS 以统一 EB 级存储为目标，同时增加了地理复制功能。
地理复制对象存储。 ACOS 的设计以地理复制为核心，确保数据可用性和灾难恢复。OceanStore [23] 为全球规模持久存储奠定了早期基础。Ford 等人分析了使用全量复制在两个区域的全球分布式环境中维护可用性的权衡 [9]。Ambry [29] 明确针对地理分布，主要面向最终一致性的不可变数据。与 ACOS 类似，Meta 的 f4 [28] 对多区域温数据使用基于地理复制的 XOR 纠删码方案。Pando [40] 探索跨区域纠删码以提高存储效率，代价是更高的延迟。最后，Mesa [13] 依赖健壮的地理复制策略。
元数据管理。 尽管采用地理复制，ACOS 仍提供强一致性，类似于 AWS S3、Google Cloud Storage 和 MinIO。ACOS 将对象元数据存储在 ClassVI——一个针对低延迟 SSD 访问优化的分布式键值存储，类似于 BigTable [5] 和 Cassandra [24]。ClassVI 也是地理分布式的，并在区域间保持强一致性，类似于 Spanner [7] 和 Dynamo [8]。将元数据分离到专用、可扩展的服务中是一种常见做法，以 Google 的 GFS 使用 Bigtable、后来的 Colossus 使用 Spanner 为例。我们的元数据数据库方法与 Ambry [29] 和 MinIO [27] 等系统不同，后者的元数据与对象并置，导致元数据密集型工作负载具有不同的性能权衡。
纠删码复制。 与许多大规模系统一样，ACOS 使用纠删码实现高持久性和存储效率 [9]。虽然 Reed-Solomon 码 [35] 是基础，但系统通常使用变体如本地重建码（LRC），由 Windows Azure Storage [16] 推广并被 Meta [28, 36] 和 Google [33] 采用。LRC 通过本地校验容器减少修复带宽和 I/O。ACOS 采用 (20,2,2) LRC，平衡存储开销、持久性和修复。先前工作使用类似的宽条带纠删码，以修复带宽为代价降低复制 [15, 21]。ACOS 通过封存将数据从复制过渡到纠删码，这是优化冷热数据存储成本的常用技术。类似的磁盘自适应编码方案根据数据温度或磁盘故障率调整冗余 [19, 20, 22, 37]。
8 结论
本文描述了 ACOS——一个为满足 Apple 特定工作负载需求而设计的对象存储系统。在生产环境中运行超过十年，ACOS 在跨多个数据中心的地理分布式环境中以低延迟和高吞吐量高效处理请求。凭借第二代系统，ACOS 将复制因子从 2.40 降至 1.50，同时保持对磁盘、主机、机架和数据中心故障的高持久性和容错能力。
随着我们准备过渡到下一代硬件（特别是更大容量的磁盘），一个重大挑战在于持续应对存储和检索数据量的不断增长，同时最小化维护操作消耗的磁盘 IOPS 开销。
致谢
作者感谢 FAST'26 的审稿人提供的深刻反馈，感谢我们的牧羊人 Juncheng Yang，以及 Aditya Umrani、Mohit Talwar、Suri Medapati 和 P.P.S. Narayan 提供的深思熟虑的意见和讨论。我们也感谢 ACOS 的创始成员——Bernard Gallet、Nick Puz 和 David Hemmo——以及 Bernard Gallet 和 Ed Nightingale 对 2.0 版本的愿景。感谢 SRE、ClassVI 和客户成功团队，以及 ACOS 的历届贡献者和当前团队成员：Andrey Trubachev、Edward Karpovits、Guillaume Rose、Ilker Yaz、Julien Lesaint、Jun Roh、Maxime Derobillard、Mohini Borse、Nate Li、Nathan Moreau、Partha Krishnamurthy、Thomas Peyrard 和 Yaniv Pessach。
参考文献
[1] Amazon Web Services, Inc. Amazon Simple Storage Service (S3). aws.amazon.com/s3, 2026.
[2] Backblaze. Disk Reliability Dataset. www.backblaze.com/cloud-stora…, 2024.
[3] Doug Beaver, Sanjeev Kumar, Harry C Li, Jason Sobel, and Peter Vajgel. Finding a Needle in Haystack: Facebook's Photo Storage. In USENIX OSDI, pages 47–60, 2010.
[4] Brad Calder et al. Windows azure storage: a highly available cloud storage service with strong consistency. In ACM SOSP, page 143–157, 2011.
[5] Fay Chang et al. Bigtable: A Distributed Storage System for Structured Data. ACM Transactions on Computer Systems, 26(2), June 2008.
[6] Jianjun Chen et al. Walnut: A Unified Cloud Object Store. In ACM SIGMOD, pages 743–754, 2012.
[7] James C. Corbett et al. Spanner: Google's Globally-Distributed Database. In USENIX OSDI, page 251–264, 2012.
[8] Giuseppe DeCandia et al. Dynamo: Amazon's Highly Available Key-Value Store. In ACM SIGOPS SOSP, page 205–220, 2007.
[9] Daniel Ford et al. Availability in Globally Distributed Storage Systems. In USENIX OSDI, pages 61–74, 2010.
[10] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System. In ACM SOSP, pages 29–43, 2003.
[11] Garth Alan Gibson. Redundant Disk Arrays: Reliable, Parallel Secondary Storage. PhD thesis, UC Berkeley, Dec 1991.
[12] Google. Google Cloud Storage. cloud.google.com/storage, 2026.
[13] Ashish Gupta et al. Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing. PVLDB, 7(12):1259–1270, March 2014.
[14] Dean Hildebrand and Denis Serenyi. Colossus under the hood: A peek into Google's scalable storage system. cloud.google.com/blog/produc…, 2021.
[15] Yuchong Hu et al. Exploiting Combined Locality for Wide-Stripe Erasure Coding in Distributed Storage. In USENIX FAST, pages 233–248, 2021.
[16] Cheng Huang et al. Erasure Coding in Windows Azure Storage. In USENIX ATC, pages 15–26, 2012.
[17] IBM. IBM Cloud Object Storage. www.ibm.com/products/cl…, 2026.
[18] Saurabh Kadekodi et al. Tiger: Disk-Adaptive Redundancy Without Placement Restrictions. In USENIX OSDI, pages 413–429, 2022.
[19] Saurabh Kadekodi et al. PACEMAKER: Avoiding HeART Attacks in Storage Clusters with Disk-Adaptive Redundancy. In USENIX OSDI, 2020.
[20] Saurabh Kadekodi, KV Rashmi, and Gregory R Ganger. Cluster Storage Systems Gotta Have HeART: Improving Storage Efficiency by Exploiting Disk-Reliability Heterogeneity. In USENIX FAST, pages 345–358, 2019.
[21] Saurabh Kadekodi et al. Practical Design Considerations for Wide Locally Recoverable Codes (LRCs). ACM TOS, 19(4), November 2023.
[22] Timothy Kim et al. Morph: Efficient File-Lifetime Redundancy Management for Cluster File Systems. In ACM SOSP, page 330–346, 2024.
[23] John Kubiatowicz et al. OceanStore: An Architecture for Global-Scale Persistent Storage. SIGPLAN Not., 35(11):190–201, November 2000.
[24] Avinash Lakshman and Prashant Malik. Cassandra: A Decentralized Structured Storage System. ACM SIGOPS OSR, 44(2):35–40, April 2010.
[25] Meta Platforms, Inc. RocksDB: A Persistent Key-Value Store for Flash and RAM Storage. rocksdb.org, 2013.
[26] Microsoft. Azure Blob Storage. azure.microsoft.com/en-us/produ…, 2026.
[27] MinIO, Inc. MinIO: High Performance Object Storage. min.io, 2026.
[28] Subramanian Muralidhar et al. f4: Facebook's Warm BLOB Storage System. In USENIX OSDI, pages 383–398, 2014.
[29] Shadi A Noghabi et al. Ambry: Linkedin's Scalable Geo-Distributed Object Store. In ACM SIGMOD, pages 253–265, 2016.
[30] Diego Ongaro and John Ousterhout. In Search of an Understandable Consensus Algorithm. In USENIX ATC, page 305–320, 2014.
[31] Oracle Corporation. Oracle Cloud Infrastructure Object Storage. docs.oracle.com/en-us/iaas/…, 2026.
[32] Satadru Pan et al. Facebook's tectonic filesystem: Efficiency from exascale. In USENIX FAST, pages 217–231, 2021.
[33] Korlakai Vinayak Rashmi et al. A "hitchhiker's" Guide to Fast and Efficient Data Reconstruction in Erasure-Coded Data Centers. In ACM SIGCOMM, pages 331–342, 2014.
[34] Benjamin Reed and Flavio P. Junqueira. A simple totally ordered broadcast protocol. In LADIS, pages 1–6, 2008.
[35] I. S. Reed and G. Solomon. Polynomial codes over certain finite fields. Journal of SIAM, 8(2):300–304, 1960.
[36] Maheswaran Sathiamoorthy et al. XORing Elephants: Novel Erasure Codes for Big Data. PVLDB, 6(5):325–336, March 2013.
[37] Zhirong Shen et al. A Survey of the Past, Present, and Future of Erasure Coding for Storage Systems. ACM TOS, 21(1), January 2025.
[38] Alexander Shraer et al. CloudKit: Structured Storage for Mobile Applications. PVLDB, 11(5):540–552, January 2018.
[39] The Apache Software Foundation. Apache Cassandra. cassandra.apache.org/, 2026.
[40] Muhammed Uluyol et al. Near-Optimal Latency Versus Cost Tradeoffs in Geo-Distributed Storage. In USENIX NSDI, pages 157–180, February 2020.
[41] Sage Weil et al. Ceph: A scalable, high-performance distributed file system. In USENIX OSDI, pages 307–320, 2006.
