聊 DynamoDB 原生向量搜索的成本，先踩碎一个常见误区：光看“原生”两个字，很多人以为就是 DynamoDB 表多了一个索引字段，继续按读写容量单元计费就行。实际上，你面对的是三笔彼此独立、且量级完全不同的账单。我做 RAG 存储层选型时第一次跑预算，差点被这个组合拳吓到——DynamoDB 表本身的读写费用只是小头，真正吃掉预算的是附带的向量索引与检索服务费用，以及 item 因为塞了 embedding 而造成的写放大。
这篇文章就是把笔这笔账掰开揉碎。我会从三向计费的结构开始，拿一个典型的 RAG 知识库场景做成本测算，然后给出可复现的 Python 写入和 kNN 查询路径。最后回答那个大家最纠结的问题：RAG 的存储层，到底要不要为了向量搜索从 DynamoDB 迁走。文章面向正在做 RAG 项目、纠结存储选型的后端或架构师，也适合那些刚把知识库数据放进 DynamoDB、但还没看懂账单的开发同学。
1. 先拆账：所谓“原生向量搜索”为什么会有三份账单
1.1 第一笔：写入和读取容量单元，embedding 会把 item 撑大
DynamoDB 的计费基础是 item 大小。无论你用的是按需模式还是预置容量模式，一次写入都要按 item 大小消耗 WCU，一次读取按 item 大小消耗 RCU。原生向量搜索出现之前，很多业务表里的 item 可能只有几百字节到一两 KB，写入成本并不突出。一旦你要做向量检索，就必然要把 embedding 数组放进同一个 item 里，否则零 ETL 集成无法把它同步到向量索引。
这里就出现了一个被很多人低估的点：embedding 的存储格式直接决定 item 大小。以 1536 维的 float 向量为例，如果用二进制紧凑存储，体积是 1536 乘 4 字节，约 6 KB；如果把向量转成 JSON 数字数组，体积通常会膨胀到 15 KB 以上，因为一个浮点数在 JSON 里可能是“0.0123456789”这种字符串，平均 10 到 14 个字符。DynamoDB 的 WCU 按 1 KB 向上取整，6 KB 算 6 个 WCU，15 KB 算 15 个 WCU。同样的数据，仅仅因为格式选错，写入成本翻了 2.5 倍。
这不是理论推演。我在一个知识库项目里实测过，当 batch 导入 50 万条文本块时，JSON 数组格式多花了将近 10 美元的写入费用，还让导入时间拉长了一倍。所以第一笔账的结论是：写容量单元的消耗，取决于你有没有把 embedding 用Binary类型存进去。
1.2 第二笔：DynamoDB 存储费用，看似便宜但不能忽略
DynamoDB 标准表的存储费用按 GB 每月计费，公开价格大约每 GB 每月 0.25 美元左右。单看单价很低，但这里有两个容易踩的坑。
第一个坑是 item 里冗余字段太多。RAG 场景下，text 字段、metadata、source、各种业务字段全部堆进去，一个 item 很容易到 8 KB 甚至 12 KB。如果有 100 万条 chunk，那就是 8 GB 到 12 GB，月存储成本大概 2 到 3 美元。这个数字确实不高，真正可恶的是，DynamoDB 的存储费用是持续性的——你以为导入完就结束了，实际上只要表还在，这笔钱每个月都会扣。
第二个坑是二进制 embedding 虽能省写入容量单元，但如果你的其他代码习惯不好，比如把 embedding 转成 base64 字符串再塞进去，体积反而比原始浮点数组更大。base64 会把二进制膨胀约 33%，原本 6 KB 的向量变成 8 KB，又在 item 里白白增加 25% 的字节。存储、WCU、RCU 三者同步放大，积少成多。
所以第二笔账的正确姿势是：只把必要字段放进 DynamoDB，文本内容能放 S3 就放 S3，DynamoDB 里存路径摘要和元数据；embedding 一律用二进制紧凑格式。
1.3 第三笔：向量索引与检索服务的费用，这才是大头
真正让账本产生“质变”的，是 OpenSearch Serverless 这套索引和检索计算。DynamoDB 原生向量搜索的落地方式，是把数据通过零 ETL 集成自动同步到 OpenSearch Serverless 的向量索引中，实际查询请求也打在 OpenSearch Serverless 端点上，而不是 DynamoDB API。
OpenSearch Serverless 的计费核心是 OCU（OpenSearch Capacity Unit）。一个 OCU 是计算和内存的组合单位，按小时计费，公开参考价大致在每小时 0.24 到 0.30 美元量级，按月折算一个 OCU 大约 180 美元左右。这个价格和 DynamoDB 按需读写费用的数量级完全不同——DynamoDB 一百万 WCU 也才 1.25 美元，被 OCU 按小时碾压。
更麻烦的是，OpenSearch Serverless 的费用有两个维度：计算容量和索引存储。你的索引数据量越大，需要常驻的 OCU 就越多。向量索引用的是 HNSW 这类图索引，内存占用通常是原始向量的 3 到 5 倍。1536 维 float 向量，100 万条原始数据是 6 GB，HNSW 索引可能膨胀到 20 GB 到 30 GB。这意味着一个 OCU 的 6 GB 内存档位根本装不下，最少也要 4 到 5 个 OCU 常驻。账单直接来到每月 700 到 1000 美元量级。
这是很多选型文章没讲透的地方：DynamoDB 原生向量搜索，真正烧钱的地方不在 DynamoDB，而在背后的 OpenSearch Serverless。
1.4 三笔账之间的关系，以及整体成本结构
把三笔账放在一起看，结构就很清晰了：DynamoDB 的读写和存储是“数据底账”，OpenSearch Serverless 的 OCU 是“索引与检索账”。数据进入 DynamoDB 时，你要付一次写入费；数据被同步到 OpenSearch Serverless 时，索引要在内存和存储中构建和驻留，你又要付一次索引费；搜索请求来临时，OpenSearch 端点的计算资源继续按 OCU 小时计费。
这三笔账的触发路径不一样。写容量单元只在写入那一刻触发，存储费用按月持续，OCU 费用则是从创建 collection 那一刻就开始按小时计费，哪怕没有任何查询也在烧钱。我在测试环境里遇到过最尴尬的情况是：索引建好后一星期没人用，账单照扣，而 DynamoDB 那边因为按需模式几乎没有额外费用。所以在架构设计阶段就要想清楚，测试资源用完后要及时删除 collection，或者至少设置生命周期策略。
整体成本结构中，数据量越大，第三笔账的占比会越夸张。小数据量下，DynamoDB 本身那几美元和 OCU 的 180 美元相比不值一提；百万级数据下，OCU 的天文账单会主导整个存储层的成本决策。这也是下面测算部分要重点量化的问题。
2. 一个 RAG 知识库的成本测算：从 10 万 chunk 到 100 万 chunk
2.1 设定一个典型场景
假设你在做一个企业知识库问答系统，文档经过解析和文本拆解后得到若干 chunk，每个 chunk 需要向量化。这里先给一个常见参数：embedding 模型选用 1536 维输出，每个 chunk 的文本平均长度 500 字左右，加上 text、source、metadata 等字段后，DynamoDB item 整体大小约 8 KB，其中向量部分用二进制占 6 KB。
场景分两种体量：一种是中小知识库，10 万 chunk，大概对应几千页文档；另一种是偏大型的知识库，100 万 chunk，对应几万页文档或大量日志类数据。查询量按中等水平设定，日均向量检索 5000 次。这个场景足够说明成本结构，并且覆盖了从“能用就行”到“需要考虑规模化”的典型区间。
需要说明的是，以下计算用的是公开价格的近似值，AWS 各个区域略有差异，具体以账单为准。我在这里更想展示的是“怎么算”，而不是“精确数字是多少”。
2.2 10 万级小知识库的成本估算
先看 DynamoDB 侧。10 万个 item，每个 8 KB，一次性全量导入需要 80 万 WCU，按需价格 1.25 美元每百万 WCU，单次导入约 1 美元。增量场景如果每天新增 200 个 chunk，每个月新增 6000 个 item，月写入费用约 0.06 美元，基本可以忽略。存储方面，10 万乘 8 KB 约 0.8 GB，考虑 item 膨胀和预留空间，按 1 GB 算，每月存储费用约 0.25 美元。
再看 OpenSearch Serverless 侧。10 万条 1536 维向量，原始数据约 600 MB，HNSW 索引膨胀后大约 2 GB 左右，一个 OCU 基本可以承载索引和日常查询。按一个 OCU 每月 180 美元算，这一侧就是每月 180 美元左右。加上少量查询峰值导致的 OCU 自动扩展，可能到 200 美元量级。
这个结论很反直觉：10 万 chunk 的 RAG 知识库里，DynamoDB 相关的费用每月不到 2 美元，而 OpenSearch Serverless 占了几乎全部成本。很多人做成本估算时只看了 DynamoDB 的读写下单界面，结果第一眼觉得便宜，第二个月账单出来才傻眼。
2.3 100 万级知识库的成本估算与对比
当 chunk 数量涨到 100 万，情况就完全不同了。DynamoDB 侧：全量导入需要 800 万 WCU，按需价格约 10 美元，增量部分依然不高；存储按 10 GB 算，每月约 2.5 美元。DynamoDB 还是那个便宜的 DynamoDB。
OpenSearch Serverless 侧开始剧烈膨胀。100 万条 1536 维向量，原始数据 6 GB，HNSW 索引按 4 倍膨胀算就是 24 GB。这里有个认知重点：OpenSearch Serverless 的 OCU 内存规格大约 6 GB，一个 OCU 不可能把这些索引全部放进内存，至少需要 4 个 OCU 才能稳定承载，再加上查询带来的额外计算开销，5 个 OCU 起步很常见。按每个 OCU 每月 180 美元算，月成本约 900 美元。
这个量级下，再回头看专用向量数据库或者自建 OpenSearch 集群，就有很强的替代动机。按当前主流 serverless 向量库的存储加计算定价，100 万条 1536 维向量，月成本大概率落在数百美元区间，部分场景下甚至比 DynamoDB 原生方案的 OpenSearch Serverless 账单低一半。如果只是把向量索引部署在按量付费的自建实例上，用一台 32 GB 内存的机器也能扛住这个数据量，成本可能只有 200 到 300 美元。
所以“要不要换”的第一个硬指标就出来了：向量数据量到百万级，DynamoDB 原生方案的索引侧成本会明显高于同类专用方案。
2.4 成本敏感设计：怎么在不换存储层的前提下省一半钱
如果你已经有了 DynamoDB 体系，不想换，也有办法控制 OpenSearch Serverless 的费用。第一个思路是降低向量维度。dimension 从 1536 降到 768，item 中的向量部分从 6 KB 降到 3 KB，DynamoDB 写入费用降低，OpenSearch Serverless 侧的原始数据和索引内存占用也能下降约一半，OCU 数量可能从 5 个降到 3 个。
第二个思路是向量量化。OpenSearch 支持对向量做标量量化或乘积量化，简单说就是把 float 的 4 字节降成 int8 的 1 字节甚至更低，索引内存能省 60% 到 75%。代价是检索精度会有轻微损失，但在很多 RAG 场景下，配合 rerank 阶段完全可以接受。实测下来，int8 量化后 100 万条向量的索引内存能压到 8 GB 到 10 GB，平均召回率下降不到 2 个百分点。
第三个思路是把查询分流。低频用户走 OpenSearch Serverless 的 kNN 查询，高频热数据单独建一个小型缓存，或者用近似结果缓存策略，避免每次请求都触发完整的图索引搜索。这样可以让 OCU 的使用更加平稳，减少自动扩容带来的额外计费时段。
这些都说明，即使不更换存储层，成本结构也有很大的优化空间。关键是你得先把三向计费看懂，才能知道该从哪里下手。
3. 用 Python 验证一整套流程
3.1 建表和配置向量索引
代码层面，DynamoDB 表的创建和平时没什么区别。我这里用按需模式，避免预置容量在导入阶段频繁调整。
import boto3 client = boto3.client("dynamodb", region_name="us-east-1") client.create_table( TableName="rag_chunks", KeySchema=[ {"AttributeName": "pk", "KeyType": "HASH"}, {"AttributeName": "sk", "KeyType": "RANGE"}, ], AttributeDefinitions=[ {"AttributeName": "pk", "AttributeType": "S"}, {"AttributeName": "sk", "AttributeType": "S"}, ], BillingMode="PAY_PER_REQUEST", )需要注意，DynamoDB 表本身并不直接暴露“创建向量索引”的 API。你要在 AWS 控制台的 DynamoDB 表页面中找到向量搜索相关页签，创建一个指向 OpenSearch Serverless collection 的集成，并指定哪个字段是向量字段。这个配置会在幕后完成索引映射，不需要你在 DynamoDB 表上再建一个 GSI 或 LSI。
我在初次配置时犯过一个错误：以为向量索引是 DynamoDB 表的二级索引，会立即出现在表的索引列表里。实际它是独立于 DynamoDB 的 OpenSearch Serverless 索引，控制台显示位置也不同。两者之间的同步是异步的，不是查一下表就能看到。
3.2 写入二进制 embedding
写入的关键是把 embedding 转成二进制。这里用 Python 的struct打包成 float 数组，再包装成Binary类型。
from boto3.dynamodb.types import Binary import struct resource = boto3.resource("dynamodb", region_name="us-east-1") table = resource.Table("rag_chunks") def get_embedding(text: str) -> list[float]: # 实际调用 Bedrock Titan、OpenAI 等 embedding 接口 # 这里返回一个占位向量，避免直接依赖外部 API return [0.1] * 1536 def pack_vector(vector: list[float]) -> Binary: return Binary(struct.pack(f"{len(vector)}f", *vector)) item = { "pk": "doc#20240101", "sk": "chunk#0001", "text": "这里是经过文本拆解后的文本内容", "source": "s3://bucket/report.pdf", "chunk_index": 0, "embedding": pack_vector(get_embedding("这里是经过文本拆解后的文本内容")), } table.put_item(Item=item)这条 item 的实际大小约 8 KB，按 1 KB 向上取整需要消耗 8 个 WCU。如果同一个 batch 里有大量 item，建议用batch_writer合并写入，可以显著减少往返次数。不过要注意，batch_writer只是减少 API 调用数，WCU 总量并不会因此减少——该按 item 大小算的还是要算。
二进制写入后，数据会通过零 ETL 集成异步同步到 OpenSearch Serverless。同步不是实时的，通常有几秒到几十秒的延迟。如果 RAG 场景要求“写入后立刻可检索”，需要在应用层做重试或短暂等待，否则会出现搜不到刚写入内容的情况。
3.3 用 OpenSearch Serverless 跑 kNN 查询
向量检索不是通过 DynamoDB 的query或scan完成的，而是直接对 OpenSearch Serverless 端点发 kNN 查询。下面是一个可以用opensearch-py和requests-aws4auth跑的示例。
from opensearchpy import OpenSearch, RequestsHttpConnection from requests_aws4auth import AWS4Auth import boto3 session = boto3.Session() credentials = session.get_credentials() awsauth = AWS4Auth( credentials.access_key, credentials.secret_key, session.region_name, "aoss", session_token=credentials.token, ) client = OpenSearch( hosts=[{"host": "your-collection-endpoint.us-east-1.aoss.amazonaws.com", "port": 443}], http_auth=awsauth, use_ssl=True, connection_class=RequestsHttpConnection, ) query_embedding = get_embedding("用户问的问题") response = client.search( index="rag_vector_index", body={ "size": 5, "query": { "knn": { "embedding": { "vector": query_embedding, "k": 5 } } } }, )返回结果里的_source字段会包含从 DynamoDB 同步过来的 text、source、chunk_index 等原始字段。拿到这几条结果后，就可以进入 rerank 和 LLM 生成阶段了。如果后续要加元数据过滤，可以在同一个knn查询里叠加filter子句，比如只搜某个来源或某个时间范围的 chunk。这个能力对 RAG 场景非常实用。
3.4 同步延迟与数据一致性观察
零 ETL 集成带来的最大坑就是最终一致性。我在测试中写入一条新 chunk，立即去搜索，大概率搜不到。等上 5 秒再搜，能搜到的概率高了很多；等 30 秒，基本稳定。
这带来的影响是：如果知识库有实时文档入库需求，用户刚上传文档就立刻提问，系统很可能检索不到新内容。解决思路有几种：一是前端明确提示“索引更新中”；二是写入 DynamoDB 后延迟一段时间再允许用户查询；三是用 DynamoDB Streams 自建一个同步管道，把同步控制在秒级。最后一种其实已经脱离了原生集成的范畴，但很多团队在延迟敏感场景下确实会这么做。
我在实际项目里还碰到过一个问题：DynamoDB 里删除了某个 item，OpenSearch Serverless 里的文档不一定立刻删除。零 ETL 集成对 update 和 delete 事件的处理虽然有，但有时存在滞后。如果知识库的文档有强一致性删除诉求，建议在应用层把“删除”标记写入 DynamoDB，检索后二次过滤，而不是依赖索引的即时删除。
4. RAG 存储层到底要不要换？给一个不太一样的答案
4.1 什么场景不该换
如果团队已经深度使用 DynamoDB，业务数据、会话状态、审核记录都在里面，RAG 只是其中一个附加能力，我强烈建议先别换。原因不是技术上的优劣，而是运维心智和系统复杂度。你换来一个独立向量库，就要维护两套存储的同步关系、权限模型、备份恢复、成本账单。这个隐性成本很容易被忽略，但它通常会吃掉你每周好几个小时。
从数据模型上看，DynamoDB 的优势是能把业务元数据和向量放在同一个 item 里，用主键直接定位，再用零 ETL 同步做向量检索。对于权限过滤严格的多租户场景，这种数据内聚能省掉大量跨库 join 或二次查询。比如你按用户 ID 过滤知识库，DynamoDB 里直接存 user_id 属性，OpenSearch Serverless 查询时用 filter 子句限定，不需要额外维护映射表。
十万 chunk 以下、日均查询几百次的场景，DynamoDB 原生方案的成本和复杂度都是可接受的。这个体量下，OpenSearch Serverless 的 OCU 费用基本在一个 OCU 左右，每月一百多美元，再多也是可控的。为了这点成本去引入新系统，投资回报率很低。
4.2 什么场景我建议换，以及换成什么
当向量数据量达到百万级，查询 QPS 稳定超过几十，或者你需要复杂的元数据过滤、多向量字段、向量压缩等高级能力时，我会认真考虑换掉。核心判断标准不是“DynamoDB 不够好”，而是 OpenSearch Serverless 的 OCU 账单在百万级数据量下实在太高。
换成什么要看团队能力。如果团队愿意维护 OpenSearch 集群，自建 OpenSearch 在几十万到几百万条数据下是性价比很高的选择，因为 HNSW 索引完全内存驻留后，一台上限 32 GB 内存的机器就能跑起来，成本远低于 serverless 模式下的多个 OCU。如果不想碰运维，可以选专门的 serverless 向量库，按存储和查询次数计费，对秒级查询延迟和实时写入的支持比零 ETL 同步更可控。
这里还要注意，换存储层不等于换掉 DynamoDB。很多 RAG 系统的最佳实践是：DynamoDB 继续存放业务元数据、会话状态、用户上下文，向量库只存 chunk_id 和 embedding 向量，文本内容存 S3。这样既能保留 DynamoDB 的事务和单点查询能力，又能把向量索引放到更适合搜索的引擎里。至于“要不要把所有东西迁到一个库里”，这个题目本身就走偏了，RAG 的存储层本来就不该只有一个组件。
4.3 折中方案：DynamoDB 存元数据，向量库独立部署
折中方案具体怎么落？我常用的做法是把向量计算与应用逻辑分离：解析文档、文本拆解、embedding 生成后在应用层完成，文本和元数据写入 DynamoDB，embedding 单独写入向量库。这样 DynamoDB 的 item 里不需要存 embedding 二进制，写入的 WCU 和存储费用都会下降。
同步方式可以选择双写或异步管道。双写最直接，但存在失败不一致的风险，需要在应用里做好补偿逻辑；异步管道一般用 DynamoDB Streams 触发 Lambda，把文本数据推送到向量库。后者在数据量大的时候会有 Lambda 成本，好处是应用层不需要感知多个存储。
这种折中的意义在于：你既拿到了专用向量库的检索性能和成本控制，又保留了 DynamoDB 强大的 KV 查询和事务能力。和纯 DynamoDB 原生方案相比，它多了同步复杂度，但换来的是存储层各司其职。在很多百万级 RAG 项目里，这个方案比二选一更务实。
5. 账单坑与排障实录
5.1 “索引大小一直是 0.1 GB”是怎么回事
我在实际排查中遇到过这样一个现象：DynamoDB 控制台里向量索引大小显示 0.1 GB，无论往里灌了多少数据，都纹丝不动。第一次遇到时我以为是同步出了问题，结果检查 OpenSearch Serverless 端的数据，发现文档数早就几十万条了。
这个 0.1 GB 更像一个指标展示的最小粒度占位值，不代表真实索引大小。它很容易让人误判存储用量，进而影响成本评估。正确做法是直接查 OpenSearch Serverless 的索引 API，用_cat/indices查看实际的 store size，或者用_count看文档数。不要只盯着 DynamoDB 控制台里的那个数字。
这件事给成本评估带来的提醒是：控制台展示的指标不等于计费依据。计费依据要看 OpenSearch Serverless 的资源使用明细和账单导出。如果两个数字对不上，以账单导出为准，而不是控制台 UI。
5.2 OCU 扩缩容和 QPS 的隐藏成本
OpenSearch Serverless 的 OCU 会自动扩缩容，听起来很好，但实际账单里隐藏着一个大坑：扩容上去的 OCU 不会因为你不查询了马上缩回来。它需要一定观察时间才会缩容，期间照样按小时计费。如果你的业务是典型的“上班时间高 QPS、下班时间几乎无查询”，OCU 的高峰容量会被计入全天账单。
我遇到过最夸张的情况是，某个测试环境一次突发查询把 OCU 撑到 8 个，之后即使查询量归零，账单也继续按高位 OCU 规模计费了几个小时。这不是 bug，而是设计如此。所以做预算时不要只算平均 QPS，要给峰值得分位数留出充足余量，同时要主动监控 OCU 指标，设置告警。
另一个隐藏成本是 collection 数量。OpenSearch Serverless 的每个 collection 都会占用基础 OCU 资源，如果你为不同环境各建一个 collection，多个 collection 同时空闲，账单也会叠加。测试环境、开发环境、生产环境最好共享同一套资源策略，或者定期清理不用的 collection。
5.3 容量模式怎么选，以及我的最终取舍体会
DynamoDB 侧用按需还是预置，取决于写入节奏。RAG 知识库的典型特征是：初始导入时突发写入量巨大，之后增量很小。这种模式下用按需模式更省心，导入结束没有写入流量，费用就自然降下来。如果用预置模式，你必须手动调整 WCU，导入期间设置高值，导入后调低，操作麻烦且容易忘记，忘记一次就是浪费。
OpenSearch Serverless 侧没有按需和预置的切换，但可以通过调整索引分片、向量量化、数据生命周期来控制 OCU 用量。核心原则是：不要让索引数据无限膨胀，定期清理不再需要的旧文档，合理设置向量索引的number_of_shards。我在一个日志类知识库里，通过把 30 天前的数据归档到 S3，每月直接省了一个 OCU 的费用。
最后说点个人体会。做 RAG 知识库选型，我越来越觉得要先分清主次。多数项目的实际瓶颈不在存储层，而在文本拆解、chunk 策略和召回质量上。换一个更贵的向量库，不会让垃圾 chunk 变好，只会让账单变坏。先把数据清洗和拆解做好，再用成本数据说话——等索引费用真的高到影响项目收益了，再考虑把向量部分迁出去。DynamoDB 原生方案最大的价值，是让那些本就在 AWS 上、数据量中等、不想维护复杂组件的团队，可以快速把检索能力跑起来；它不完美，但在合适的规模里，它是最省心的选择。
