S3 老态已显

本文最初发表于 Materialized View 网站，由 InfoQ 中文站翻译分享。

毋庸置疑，S3 是一项工程方面的壮举。构建和运维一个超大规模的存储系统 需要顶级的灵活性。但是，S3 的特性集正在逐渐落后于它的竞争对手。值得注意的是，S3 缺少比较并交换（compare-and-swap，CAS）操作，而其他竞争对手均支持该操作。它还缺少多区域桶和对象追加功能。甚至连 S3 Express 的表现也难以尽如人意。

这些缺失的特性对于数据湖和离线使用场景来说并不重要。但是，新的基础设施正在使用对象存储作为它们的主持久化层，这一点让我感到非常兴奋。在这方面，S3 的特性差距将会是一个更大的问题。

前置条件（precondition）也被称为比较并交换（CAS）、条件化、如果无匹配（If-None-Match）、如果匹配（If-Match）等，该特性允许客户端仅在满足特定条件时才写入对象。客户端可能希望仅在对象不存在时才写入对象，或者仅在客户端上次读取对象后未更改的情况下才更新对象。CAS 使这一切能够得以实现。这种操作通常用于分布式系统中的锁和事务。

S3 是唯一不支持前置条件的对象存储。所有其他的对象存储均支持该功能，如 Google Cloud Storage (GCS)、Azure Blob Store (ABS)、Cloudflare Ridiculously Reliable (R2) 存储、Tigris、MinIO。

开发人员被迫使用单独的事务性存储 (如 DynamoDB) 来执行事务操作。在 DynamoDB 和 S3 之间构建两阶段写入在技术上并不困难，但它很令人烦躁，而且会导致丑陋的抽象。

当 S3 Express One Zone (S3E1Z) 刚推出时，我真的很兴奋。但是，在它上面花的时间越多，我对它就越无感。第一个问题是 Amazon 为 Express 引入的新的目录桶类型。

但问题并不局限于此。S3E1Z缺少大量的标准 S3 特性，包括对象版本的支持、桶标签、对象锁、对象标签和 MD5 校验和 ETags。完整的清单非常令人震惊。

我们不能像对待普通的 S3 桶那样对待 S3E1Z 桶。与 CAS 操作一样，开发人员必须围绕这些缺陷进行设计。而且，由于 S3E1Z 不是多区域的，开发人员需要为多个可用性区域构建群体写入（quorum writes），以获得更高的可用性。

考虑到 S3E1Z 的高存储成本 (0.16 美元 /gb)，它是 Elastic Block Store(EBS) 通用 SSD (gp3) 成本的两倍，S3E1Z 看起来更像是一个昂贵的 EBS，而且只实现了一半的 S3 API。

S3 没有双区域或多区域桶。这样的桶对于更高的可用性非常有用。谷歌在这方面提供了 广泛的可选方案。

虽然这不是强制的，但拥有更高的可用性桶当然是件好事。

我们的梦想是为开发人员提供一个具有所有这些特性的对象存储：低延迟、支持前置条件、双区域 / 多区域等等。但我们必须面对现实，工程师面临着这样的选择：放弃 S3 或围绕这些差距进行构建。

Turbopuffer 是我最喜欢的一个完全放弃 S3 的公司样例。

他们的赌注是 S3 最终会支持前置条件。这种冒险似乎是合理的，因为 Amazon 拥有所有必需的构建块 (DynamoDB 和 S3)，而且每个竞争对手都在这方面击败了他们。对于正在开发的云原生 LSM，我也下了类似的赌注。

这种方式的挑战在于云之间的网络成本。所有的云提供商都对网络出口进行收费。如果数据要传输到亚马逊网络服务 (AWS) 之外的基础设施上，那么将产生网络出口费用。但是，AWS 用户的跨云成本并没有想象中的那么糟糕。Turbopuffer 的创始人兼首席执行官 Simon Eskildsen 关于该方面写过很多文章。

这样做的好处是，Turbopuffer 构建了一个优雅而简约的设计，它 只有三个组件，即 Turbopuffer 二进制文件、RAM/SSD 缓存和 Google Cloud Storage。

对许多人来说，这似乎有些极端。另一种方法是将元数据存储在 S3 之外的事务性存储中。

一旦开启了单独的元数据平面，你就会发现它的其他使用场景。认识到 S3 是一个对象存储而不是文件系统，这是进入启蒙斜坡（在新技术或新思想出现后，人们逐渐认识到其价值和应用，开始广泛采用的过程。——译者注）的必经之路。通过采用 DynamoDB 作为元数据层，系统可以获得很多好处。

最终，是放弃 S3 还是接受它的缺点取决于系统的使用场景和设计目标。但是，如果 S3 支持前置条件并且 S3E1Z 具有统一的 API，那么这个决定将会容易得多。

声明：本文由 InfoQ 翻译，未经许可禁止转载。