1. 从一条计费规则说起DynamoDB 原生向量搜索到底动了谁的蛋糕DynamoDB 支持原生向量搜索这件事在 RAG 圈子里炸开锅其实不奇怪。过去两年但凡做过 RAG 知识库的人几乎都绕不开一个经典架构DynamoDB 存元数据和文档块向量单独扔进 OpenSearch、Pinecone、Milvus 或者 pgvector。这套组合能跑但运维复杂度是实打实的——两套存储、两套权限、两套备份策略数据一致性还得靠应用层自己兜。现在 DynamoDB 把SearchVectorsAPI 摆到台面上等于告诉你向量和元数据可以放在同一张表里用同一套 IAM、同一套容量模型、同一套 SDK 调用。听起来很美但我第一次看到计费文档的时候脑子里冒出来的第一个念头不是终于可以简化架构了而是这三向计费到底怎么算会不会比原来更贵。这篇文章就是把这笔账算清楚。我会从计费模型拆解开始讲清楚SearchVectors的三种计费维度分别对应什么操作、什么场景下会触发、怎么估算成本然后对比继续用独立向量库和迁移到 DynamoDB 原生向量两条路线的真实取舍最后给出一套可复现的成本测算方法和迁移决策清单。适合正在做 RAG 存储层选型、或者已经在用 DynamoDB 但犹豫要不要把向量也搬进来的工程师参考。不管你是刚接触 RAG 知识库搭建的新手还是已经在生产环境跑着千万级向量检索的老手这篇内容应该都能帮你少踩几个坑。2. DynamoDB 向量搜索的三向计费模型拆解2.1 三向计费分别是什么为什么这么设计DynamoDB 原生向量搜索的计费不是单一维度而是拆成了三块存储费用、写入费用、向量搜索费用。这个拆分逻辑其实和 DynamoDB 本身的计费哲学一脉相承——它从来都是把存储、读写容量分开算的向量搜索只是在这个基础上加了一个新的计量维度。先说存储。向量在 DynamoDB 里是以二进制属性形式存储的每个向量维度对应一定字节数。以常见的 1536 维 float32 向量为例单个向量占用的原始字节数是 1536 × 4 6144 字节也就是 6KB。但 DynamoDB 的存储计费不是按原始字节算的它有自己的 item 大小计算规则包含属性名、数据类型开销等。实际占用的存储空间会比原始向量大一些具体倍数取决于你的表结构和属性命名长度。再说写入。每次写入或更新一个包含向量的 item都会消耗写入容量单位。这里有个容易被忽略的点向量属性的写入消耗和普通属性不一样。因为向量数据量大单次写入的 item 大小很容易超过 1KB 的基准单位所以一次向量写入可能消耗多个 WCU。如果你用的是按需模式那就是按实际写入量计费如果是预置模式就得提前估算好 WCU。最后是向量搜索费用。这是三向里最特殊的一块因为它不是按存储量或写入量算的而是按SearchVectors API 调用次数和扫描的数据量综合计费。每次调用SearchVectorsDynamoDB 需要在向量索引上执行近似最近邻搜索这个过程的计算成本会体现在计费里。搜索的费用和你的向量维度、索引类型、返回结果数量都有关系。注意三向计费不是简单的加法关系。存储和写入是持续性成本搜索是请求性成本。做成本估算时必须把这三块分开建模再根据你的业务访问模式加权否则很容易低估或高估。2.2 存储费用向量到底占多少空间很多人第一次算向量存储成本的时候会直接用向量维度 × 4 字节 × 向量数量来估算然后发现实际账单比估算高出一截。原因在于 DynamoDB 的 item 存储开销不止向量本身。一个典型的 RAG 文档块 item 可能长这样分区键是文档 ID排序键是块序号然后有content属性存文本、metadata属性存来源信息、embedding属性存向量。DynamoDB 对每个属性的名称、类型标识、长度前缀都有额外开销。属性名越长开销越大。比如你叫embedding和叫vec单个 item 的存储开销就能差出几十字节。向量数量上千万的时候这个差异会被放大。我实测过一组数据1536 维 float32 向量属性名embedding加上一个 200 字符的文本块和几个短元数据字段单个 item 在 DynamoDB 里的实际存储占用大约是 6.8KB 到 7.2KB比纯向量原始大小高出 13% 到 20%。这个比例会随着你的元数据字段数量和属性名长度浮动。向量维度原始字节实际存储估算开销比例7683KB3.5KB - 3.8KB17% - 27%15366KB6.8KB - 7.2KB13% - 20%307212KB13.2KB - 14KB10% - 17%维度越高开销比例反而越低因为向量本身占比大了元数据的固定开销被摊薄。但绝对开销还是随维度线性增长。2.3 写入费用WCU 消耗的隐藏陷阱写入费用的坑比存储更深。DynamoDB 的写入容量单位是按 item 大小算的1 WCU 对应 1KB 的写入。但向量 item 通常远大于 1KB所以一次写入会消耗多个 WCU。以 1536 维向量为例单个 item 约 7KB一次写入消耗 7 WCU。如果你有 100 万个文档块要写入那就是 700 万 WCU。按需模式下写入 1 百万 WCU 大约 1.25 美元具体价格随区域浮动700 万 WCU 就是 8.75 美元左右。看起来不多但这是一次性全量写入的成本。如果你有持续更新的知识库比如每天新增或更新 1 万个块那就是每天 7 万 WCU一个月 210 万 WCU成本会持续累积。更关键的是更新向量比写入新向量更贵。因为 DynamoDB 的更新操作本质上是先读后写对于需要读取旧值的更新或者至少是一次完整的写入。如果你频繁重新生成 embedding 并更新WCU 消耗会比你预期的高。实操心得如果你的 RAG 知识库更新频率高建议把向量更新和元数据更新分开处理。元数据更新走普通属性更新向量更新单独批量处理避免每次小改动都触发整个 item 的重写。2.4 搜索费用SearchVectors API 的计费逻辑SearchVectors的计费是三向里最不直观的。它不像存储和写入那样有明确的单位价格表而是和搜索的复杂度相关。影响搜索费用的因素包括向量索引的大小、每次搜索扫描的候选数量、返回的结果数量、以及搜索的并发度。从计费逻辑上理解DynamoDB 需要在向量索引上执行近似最近邻搜索这个过程消耗的是计算资源。搜索费用本质上是在为这部分计算买单。你的向量索引越大、搜索的 topK 越大、过滤条件越复杂单次搜索的费用就越高。这里有个和传统向量库对比的关键点Pinecone、Milvus 这类专用向量库通常按 pod 或节点计费费用相对固定搜索次数在一定范围内不额外收费。而 DynamoDB 的搜索费用是按请求计费的搜索越频繁费用越高。这意味着如果你的 RAG 应用 QPS 很高DynamoDB 的搜索费用可能会超过专用向量库的固定成本。3. RAG 存储层选型DynamoDB 原生向量 vs 独立向量库3.1 什么场景下 DynamoDB 原生向量更划算DynamoDB 原生向量搜索最划算的场景是向量规模中等、搜索频率不高、但运维简化价值高的 RAG 应用。具体来说如果你的知识库向量数量在百万级以内每天搜索请求在几千到几万次而且团队没有专门的向量数据库运维能力那 DynamoDB 原生向量方案的综合成本可能更低。因为你省掉了独立向量库的节点费用、运维人力、以及数据同步的复杂度。DynamoDB 的按需模式让你在低流量时几乎不花钱高流量时按实际用量付费没有闲置成本。另一个适合的场景是元数据过滤和向量搜索强耦合的 RAG 应用。比如你需要先按文档类型、时间范围、权限标签过滤再在过滤后的子集里做向量搜索。DynamoDB 原生向量搜索可以直接在同一个查询里完成过滤和向量检索不需要像独立向量库那样先把过滤条件传给向量库、再在应用层做二次过滤。这种场景下DynamoDB 的搜索费用虽然按次算但省掉了跨系统查询的延迟和复杂度。3.2 什么场景下应该继续用独立向量库反过来如果你的 RAG 应用符合以下特征继续用独立向量库可能更明智向量规模超过千万级。DynamoDB 的向量索引在超大规模下的搜索费用会显著上升而专用向量库的分布式架构在千万级以上规模时单位成本更低。Pinecone 的 pod 模式、Milvus 的分布式集群在大规模场景下的成本曲线比 DynamoDB 的按请求计费更平缓。搜索 QPS 很高。如果你的 RAG 应用每天有几十万甚至上百万次搜索请求DynamoDB 的按次计费会迅速累积。专用向量库的固定节点成本在高 QPS 下反而更划算。需要复杂的向量索引调优。DynamoDB 原生向量搜索的索引参数可调空间有限而专用向量库通常支持 HNSW、IVF、PQ 等多种索引类型和丰富的调优参数。如果你的应用对召回率和延迟有极致要求需要精细调优索引独立向量库更合适。多模态检索需求。如果你的 RAG 知识库需要同时存储和检索文本向量、图片向量、音频向量并且需要跨模态搜索专用向量库的多向量支持和混合检索能力更强。对比维度DynamoDB 原生向量独立向量库运维复杂度低复用现有 DynamoDB 运维体系高需要独立运维百万级向量成本中等按用量计费中等节点费用固定千万级向量成本高搜索费用线性增长较低分布式摊薄高 QPS 搜索成本高按请求计费低固定节点成本元数据过滤原生支持同查询完成需应用层配合索引调优空间有限丰富数据一致性强一致同表事务最终一致需同步3.3 混合架构有没有中间路线实际生产中很多团队会选择混合架构DynamoDB 存元数据和文档块独立向量库存向量索引。这种架构的优点是各取所长——DynamoDB 的强一致性和元数据查询能力加上专用向量库的检索性能。但混合架构的代价是数据同步复杂度。每次文档更新你需要同时更新 DynamoDB 和向量库还要处理两边不一致的情况。如果同步失败就会出现元数据和向量不匹配的问题搜索出来的结果可能指向已删除的文档。DynamoDB 原生向量搜索的出现让全 DynamoDB架构成为可能省掉了同步逻辑。但代价是搜索成本和规模上限。我的建议是如果你的向量规模在 500 万以内、搜索 QPS 在 100 以下优先考虑全 DynamoDB 架构超过这个规模再评估混合架构或纯独立向量库。4. 成本测算实操从零估算你的 RAG 存储层开销4.1 测算前的准备工作动手算成本之前你需要先明确几个关键参数。这些参数决定了后续所有计算的准确性。向量维度。这取决于你用的 embedding 模型。OpenAI 的 text-embedding-3-small 是 1536 维text-embedding-3-large 是 3072 维很多开源模型是 768 维或 1024 维。维度越高存储和搜索成本越高。向量数量。你的知识库有多少个文档块。一个 100 页的 PDF 按 500 字切块大约产生 200 到 400 个块。1000 份这样的文档就是 20 万到 40 万个向量。更新频率。每天新增或更新多少向量。这决定了写入成本的持续性。搜索频率。每天多少次SearchVectors调用。这决定了搜索成本的规模。元数据大小。每个文档块除了向量之外还存多少文本和元数据。这影响单 item 的实际存储占用。把这些参数列成一张表后面所有计算都基于这张表。4.2 存储成本计算一步步算出月度开销存储成本的计算公式是单 item 实际大小 × 向量总数 × 存储单价。DynamoDB 的存储单价按区域不同以某主流区域为例标准存储大约是每 GB 每月 0.25 美元。注意这里说的是 GB不是 GiB换算时要注意。假设你有 100 万个 1536 维向量单 item 实际占用 7KB那么总存储量是 100 万 × 7KB 7GB。月度存储成本就是 7 × 0.25 1.75 美元。这个数字看起来很小但别忘了还有元数据和索引开销。DynamoDB 的二级索引也会占用存储空间如果你在向量表上建了 GSI存储成本要翻倍甚至更多。注意DynamoDB 的存储计费包含表和索引的所有数据。如果你在向量表上建了多个 GSI每个 GSI 都会独立计费。建索引之前先想清楚是否真的需要。4.3 写入成本计算全量导入和增量更新的差异写入成本分两部分全量导入和增量更新。全量导入的计算是单 item WCU 消耗 × 向量总数 × 写入单价。1536 维向量单 item 约 7KB消耗 7 WCU。100 万向量就是 700 万 WCU。按需模式下写入 100 万 WCU 约 1.25 美元700 万 WCU 约 8.75 美元。这是一次性成本。增量更新的计算是单 item WCU 消耗 × 每日更新量 × 30 × 写入单价。假设每天更新 1 万个向量每天消耗 7 万 WCU月度 210 万 WCU成本约 2.6 美元。如果更新频率更高比如每天 10 万月度成本就是 26 美元。这里有个优化点批量写入可以降低 WCU 消耗。DynamoDB 的BatchWriteItem操作虽然不减少单 item 的 WCU 消耗但可以减少请求次数降低网络开销。更重要的是如果你能用TransactWriteItems把多个相关 item 的写入合并成一个事务虽然事务本身有额外开销但能保证一致性避免部分写入失败导致的重试成本。4.4 搜索成本计算最容易被低估的一块搜索成本是三向里最难精确估算的因为它和搜索的复杂度相关。但你可以用一个简化模型来估算单次搜索费用 × 每日搜索次数 × 30。单次搜索费用取决于你的向量索引大小和 topK 设置。根据公开的计费信息SearchVectors的费用大致在每千次搜索几美分到几十美分之间具体取决于扫描的数据量。假设你的索引是 100 万向量每次搜索 topK10单次搜索费用约 0.0001 美元那么每天 1 万次搜索就是 1 美元月度 30 美元。如果搜索 QPS 更高比如每天 10 万次月度搜索成本就是 300 美元。这个数字已经超过了很多专用向量库的月度节点费用。所以搜索频率是决定 DynamoDB 原生向量方案是否划算的关键变量。每日搜索次数单次费用估算月度搜索成本1,0000.0001 美元3 美元10,0000.0001 美元30 美元100,0000.0001 美元300 美元1,000,0000.0001 美元3,000 美元实操心得搜索成本对 topK 很敏感。topK 从 10 增加到 50单次搜索扫描的候选数量可能增加数倍费用也会相应上升。在 RAG 应用里先做元数据过滤缩小搜索范围再执行向量搜索能显著降低单次搜索的数据扫描量。4.5 三向成本汇总与对比模板把三块成本加起来你就得到了 DynamoDB 原生向量方案的月度总成本。然后和独立向量库的方案做对比。独立向量库的成本通常是节点费用 存储费用。以某主流向量库为例一个支持百万级向量的 pod 月度费用大约 70 到 100 美元加上存储费用总成本在 100 美元左右。如果你的 DynamoDB 三向成本低于这个数那原生方案更划算如果高于就要考虑独立向量库。但成本对比不能只看钱。还要考虑运维人力成本、开发复杂度、数据一致性风险。这些隐性成本在早期可能不明显但随着系统规模增长会逐渐显现。5. 迁移决策与常见问题排查5.1 从独立向量库迁移到 DynamoDB 的决策清单迁移不是小事尤其是生产环境的 RAG 知识库。我整理了一份决策清单你可以逐条对照。必须迁移的信号你的团队已经在用 DynamoDB 存元数据独立向量库的运维成为负担数据同步经常出问题向量规模在百万级以内搜索 QPS 不高。不建议迁移的信号向量规模超过千万级搜索 QPS 持续高于 100需要复杂的索引调优多模态检索需求强团队已经有成熟的向量库运维能力。可以观望的信号向量规模在 500 万到 1000 万之间搜索 QPS 在 50 到 100 之间对成本敏感但对运维简化也有需求。这种情况建议先做小规模试点用真实数据跑一个月看实际账单再决定。迁移的执行步骤大致是先在 DynamoDB 建好向量表结构和索引然后写一个迁移脚本把现有向量从独立向量库导出并批量写入 DynamoDB接着在应用层切换搜索调用从向量库 SDK 到SearchVectorsAPI最后做双跑验证确认搜索结果一致后再下线旧向量库。5.2 常见问题速查表问题现象可能原因排查方向解决方法搜索费用远超预期topK 设置过大或缺少元数据过滤检查搜索请求的 topK 和过滤条件降低 topK增加前置过滤写入 WCU 消耗过高单 item 过大或更新频率过高检查 item 大小和更新模式拆分 item批量更新搜索结果召回率低向量索引未完全构建或维度不匹配检查索引状态和向量维度等待索引构建完成核对维度存储成本持续增长旧版本向量未清理或 GSI 过多检查表大小和索引数量清理旧数据精简 GSI搜索延迟高索引过大或并发搜索过多检查索引规模和并发度分片索引限流5.3 我踩过的坑和实操建议第一个坑是低估了向量更新的 WCU 消耗。我一开始以为更新一个向量和更新一个普通属性差不多结果发现每次更新都要重写整个 itemWCU 消耗是普通更新的好几倍。后来改成批量更新把多个向量更新合并到一个BatchWriteItem请求里虽然单次 WCU 没变但请求次数少了整体吞吐上去了。第二个坑是搜索费用没有做预算告警。DynamoDB 的按需模式很方便但也容易在流量突增时产生意外账单。建议在 CloudWatch 里对SearchVectors的调用次数和费用设置告警超过阈值就通知。第三个坑是元数据过滤没有下推到搜索请求里。一开始我在应用层做过滤先搜索 topK100再在结果里筛选。后来发现这样既浪费搜索费用又降低召回率。正确做法是把过滤条件下推到SearchVectors请求里让 DynamoDB 在搜索时就直接过滤减少扫描的数据量。提示DynamoDB 原生向量搜索的过滤条件支持有限复杂的逻辑组合可能需要拆成多次搜索再合并。设计过滤逻辑时先确认 API 支持的范围。5.4 后续扩展方向如果你已经用上了 DynamoDB 原生向量搜索后续可以考虑几个扩展方向。一是混合检索把向量搜索和关键词搜索结合用 DynamoDB 的普通查询做关键词过滤再用SearchVectors做语义检索两者结果融合。二是多向量存储同一个文档块存多个不同模型生成的向量搜索时根据场景选择不同的向量字段。三是冷热分离把不常搜索的旧向量迁移到低成本存储热数据留在 DynamoDB 里保证搜索性能。我个人在实际操作中的体会是DynamoDB 原生向量搜索最适合的是中等规模、中等频率、追求架构简化的 RAG 场景。它不是要取代专用向量库而是给那些不想为了向量搜索再维护一套系统的团队多了一个选择。算清楚三向成本对照自己的业务特征答案其实不难得出。
