从一到无穷大 #48：Vector Bucket，S3如何把向量玩成新范式？

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

引言

对业务场景的极致洞察力和对于新兴技术的跟进可以催生新的产品形态。

存储这样的基础产品在稳定后可预期的不会有像移动互联网，虚拟货币，LLM这样的爆炸性的增长，所以自然要在基础产品之外更多的伸开自己的触手，这也就出现了时序抢AP，AP抢时序；关系型抢非关系型，非关系型抢关系型。

S3这样的基础服务也终究是按捺不住寂寞，开始向上扩展了，如果说目录桶和数据处理（我注意到最近COS上线了工作流的接口）的出现是革命的第一枪的话，那么Table Bucket和Vector Bucket的出现就已经是明着向计算引擎之外的所有组件宣战了，所有使用对象存储的系统都可能被吞并一部分市场，这样来看，S3对于对象存储的定位已经从扁平的namespace扩展到一个iaas层多模存储了，从以前的成为万物的基础存储层到现在独立对接部分垂类场景，把其他产品收的降冷增值钱全拿过来，自此，我觉得3S(Simple Storage Service)已经不太合适了，我建议改名为XSS（Multi Model Storage Service）或者GSS（General Storage Service）或者CosmosDB（不是）。

举一反三：

1. TimeSeries Bucket：Apache Iceberg加上特化的Compact，ingester和GC的逻辑
2. Search Bucket：直接把ES搞进来
3. Graph Bucket：Index作为图数据存储，内部做降冷，引入中心元数据存储
4. Fast KV Bucket：数据只存索引
5. Spatial Bucket：和Vector一样加上索引

头脑风暴，在Windows Azure Storage[19]中我们知道对象存储由逻辑层，索引层和数据层组成；对象存储通过放宽传统文件系统的POSIX语义，简化索引与数据之间存储关系的设计，解决了传统分布式文件系统元数据受限的问题，满足了海量低成本的存储需求。

前两年到现在流行的数据库，存储多模化，本质上是在公司层面节省开发运维人力。而Windows Azure Storage[19]对象存储索引本身也是一种Range KV模态，特化服务于对象存储[19]，如果将多模存储作为对象存储的索引，基于此提供多模型的特化存储引擎，这样实现上面举一反三就只剩下如何低成本的提供各种垂类服务了。

先让我们来看看S3 Vector Bucket的核心卖点：

1. 低成本： sub-second级别查询性能，Serverless，单桶500亿向量存储（1000*5000W），在性能和成本之间实现平衡。
2. 向量检索：非结构化数据向量检索（包括图像、视频、音频和文本）
3. 适合访问不频繁的向量场景：Amazon OpenSearch Service 提供实时应用程序所需的高 QPS 和低延迟向量搜索，而 S3 向量则通过提供成本优化的数据基础以及针对长期存储和低频数据访问优化的查询性能来补充这一点。
4. AWS AI 服务原生集成：OpenSearch Service，Bedrock Knowledge Bases ，Amazon SageMaker Unified Studio 的原生集成

其实我司COS的MetaInsight也支持对文件进行聚合查询和语义查询，其支持创建Dataset，并在其中创建索引，然后就可以发起聚合查询[21]和各种特定场景的查询了，比如图像检索，人脸检索。这也许就是掌握行业标准的好处。

对于我熟悉的领域这种产品形态为什么我没想到？

笔者去年曾研究过一段时间存储产品和向量检索的可能性，而且去年已经想到了KV产品本身加上向量检索的业务场景，但是是从Paas产品去考虑的，更多的聚焦的是：

1. 当前的VectorDB有什么不足，我们应该如何解决（成本高，向量支持数量有限）
2. 当前已有的哪些业务可以通过向量检索赋能（KV模态）

S3协议护城河坚不可摧的念头还是太过深入，但是如果可以早一点注意到2024.12.3 AWS re:Invent 大会发布的Table Bucket，我认为当时我们可以联想到这一步的。

Product Overview

Interface

典型数据行如下：

{“key”: “v1”, “data”: {“float32”: embeddings[0]}, “metadata”: {“id”: “key1”, “source_text”: texts[0], “genre”:“scifi”}},
{“key”: “v2”, “data”: {“float32”: embeddings[1]}, “metadata”: {“id”: “key2”, “source_text”: texts[1], “genre”:“scifi”}},
{“key”: “v3”, “data”: {“float32”: embeddings[2]}, “metadata”: {“id”: “key3”, “source_text”: texts[2], “genre”:“family”}}

主体包括： key + 向量 + metadata
metadata包括：键值对，包括可检索的和不可检索的，其中存储向量化前的元数据

其实从接口上看就是一个向量数据库了。

提供如下的API：

Performance

数据来源[7]:

• Vector buckets per AWS Region in an account: 10,000
• Vector indexes per vector bucket: 10,000
• Vectors per vector index: Up to 50 million
• Dimension value per vector: 1 to 4,096
• Total metadata per vector: Up to 40 KB (filterable + non-filterable)
• Total metadata keys per vector: Up to 10
• Filterable metadata per vector: Up to 2 KB
• Non-filterable metadata keys per vector index: Up to 10
• Write requests per second per vector index: Up to 5
• Request payload size: Up to 20 MiB
• Vectors per PutVectors API call: Up to 500
• Vectors per DeleteVectors API call: Up to 500
• Vectors per GetVectors API call: Up to 100
• Top-K results per QueryVectors request: Up to 30
• Vectors listed per page in a ListVectors response: Up to 1,000
• Vector buckets listed per page in a ListVectorBuckets response: Up to 500.
• Vector indexes listed per page in a ListIndexes response: Up to 500.
• Segment count for parallel listing: Up to 16

很牛逼，单桶支持500亿向量，但是目前元数据支持的太小，

一般产品的Best Practices都是我们来猜其细节实现的好方法。

[9]中提到：

Designed to provide S3 level elasticity and durability for storing vector datasets with sub-second query performance, S3 Vectors is ideal for applications that need to build and grow vector indexes.

1. 插入与删除向量：为了避免 API 请求过载（429 TooManyRequestsException），并获得最佳吞吐量与效率，每个向量索引每秒最多支持约 5 次 PutVectors 或 DeleteVectors 请求，batch 500 条，以减少请求次数并提高整体速率。
2. 查询向量：Your application can achieve hundreds of QueryVectors, GetVectors, or ListVectors requests per second per S3 vector index. 若出现限流错误，需在客户端实现重试机制，并控制请求发送频率。
3. 跨索引水平扩展：当单一向量索引容量或性能成为瓶颈时，可以将向量数据按业务维度或租户拆分到多个向量索引，均衡查询负载。
4. 多租户访问隔离：利用 IAM 与 S3 存储策略在逻辑上为不同租户或团队划分访问权限：，即每个租户配置向量索引，需要避免为每个租户创建独立桶，This approach helps maintain data isolation and simplifies management by removing the need to create separate buckets for each tenant.
5. 配置非可过滤元数据 向量索引支持「可过滤」与「非可过滤」两类元数据字段。对于仅用于引用、无需查询过滤的字段（如原始文本块），应设置为非可过滤元数据，以减少索引开销并提升查询效率。

上面的描述我们可以得到的关键信息如下：

1. 单索引写删：qps 5次，每个batch最多携带500个向量
2. 单索引查询：qps百级别
3. 隔离：索引之间互相独立
4. 倒排索引：meta数据中可过滤的数据项添加了倒排索引

当然官方数据并不严谨，因为给出的性能没有提到召回率，维度，索引量级等关键向量检索信息，而且我注意到几个细节：

1. 查询接口并不能指定召回率
2. 创建接口不能选择索引类型
3. 距离函数支持较少，只支持Cosine和Euclidean
4. 向量存储费用（vector data, key, and filterable metadata）仅为基础对象存储的三倍左右

其次这个性能和索引量级不可能是用现在faiss等流行的内存索引库，[12]中可以看到diskann的性能和官方给出的也不符合，目前也没有搜到其是如何实现的向量检索，这个价格肯定是把向量索引，倒排索引和数据存储在数据层了。

所以我倾向于是S3设计了一种机制，把倒排索引和向量索引分块存在数据层了，然后检索的时候先拉扫描这部分数据，然后再去查metadata。

Pricing

按照我在[22]中对目录桶实现的猜测，目录桶的存储价格不应该这么高，但基本可以确定vector bucekt的数据不是简单的封装了一层向量检索库，而出基于对象存储存储层重新设计了向量索引。

结语

说来巧合，昨天因有事而请了一天半的假，今天下午才赶到公司，在昨天晚上回深圳的车上看到S3发布的这么一个有意思的特性，遂用昨天晚上和今天晚上的时间完成了这篇随笔。

写这篇文章目的有三：

1. 一方面是确实是自己熟悉的领域，希望可以输出一些我的思考
2. 第二是希望看到文章的同行可以一篇文章清楚这个特性
3. 第三则是带有私心，希望可以赶上热点

手写纯技术文章在这个年代并不是一个投入产出比很高的事情，后面再写更多的是会取悦自己。

参考：

1. Amazon S3 Vectors上线，向量数据查询成本直降90%
2. Amazon S3 Vectors发布！向量数据查询成本直降90%
3. Working with S3 Vectors and vector buckets
4. TairVector简介
5. s3vectors-embed-cli
6. Amazon S3 Vectors API
7. S3 Vector Bucket Limitations and restrictions
8. 腾讯云Vector DB 使用限制
9. S3 Vectors best practices
10. 向量数据库领域，最近有哪些研究热点问题？
11. ann-benchmarks
12. diskann性能
13. Unveiling AWS S3 Vector: Revolutionizing AI Data Storage and Retrieval for Developers
14. Amazon S3 pricing
15. Announcing Amazon S3 Vectors (Preview)—First cloud object storage with native support for storing and querying vectors
16. Amazon S3 Vectors feature
17. Amazon S3 Vectors - Store and query vectors at scale in S3
18. 尝试“Amazon S3 Vectors”
19. Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency
20. The NIST Definition of Cloud Computing
21. 数据万象 简单查询
22. 从一到无穷大 #47：浅谈对象存储加速