用 Amazon DynamoDB 构建无需双写的 Agent Memory 与语义检索
内容提要
本文介绍如何用Amazon DynamoDB原生向量搜索构建Agent长期记忆，无需双写。通过将业务属性和embedding存入同一item，用一次PutItem写入，SearchVectors语义召回，Query按时间读取。文章涵盖数据模型、建表、写入、检索细节，并指出分区键非安全边界、等值过滤限制、成本按字节计费等注意事项，适合操作型数据已在DynamoDB的场景。
延伸解读
双写问题的本质
文章指出，在没有原生向量索引时，业务数据与向量数据分离存储会带来一致性、管道、schema 同步、删除同步和运维等多重负担。这些工作不直接产生业务价值，却可能成为运维痛点。DynamoDB 原生向量索引将同步逻辑收进托管服务，应用只需一次写入，从根本上简化了架构。
分区键：性能优化而非安全边界
文章强调，用分区键限定搜索范围是数据局部性和性能优化，并非访问控制。任何拥有 SearchVectors 权限的主体都能搜索任意分区键值，且 IAM 条件键（如 LeadingKeys）对 SearchVectors 不生效。若需强租户隔离，应使用独立表或索引并配置独立授权。
成本与性能的权衡
向量搜索按字节计费，维度直接乘在存储和读写成本上。文章建议利用 Embed v4 的 Matryoshka 维度，在自有数据上对比 512 维与 1024 维的召回质量，以做出成本决策。同时，官方性能指标需在真实数据分布下验证，尤其关注 P99 延迟和召回率。
适用场景与限制
该特性最适合操作型数据已在 DynamoDB 的场景，可避免引入第二套存储和同步管道。但若需要复杂混合检索、海量冷向量存储或丰富元数据过滤，则 OpenSearch 或 S3 Vectors 可能更合适。此外，当前仅支持等值过滤、无分页、仅按需模式等限制需提前纳入设计。
Q&A
如何用 DynamoDB 实现 Agent 长期记忆的语义检索，避免双写？
利用 DynamoDB 的原生向量搜索功能，将业务属性和 embedding 存储在同一个 item 中，通过一次 PutItem 写入，使用 SearchVectors 进行语义召回，无需额外同步到独立的向量数据库。
DynamoDB 向量索引的数据模型如何设计？
使用一张表，分区键为 pk（如 USER#<user_id>），排序键为 sk（如 MEM#<类型>#<时间戳>），同时包含 user_id（向量索引分区键）、mem_type（内联过滤）、text、embedding 等属性。这样既能按时间查询，也能按语义检索。
如何创建 DynamoDB 向量索引？
在 CreateTable 或 UpdateTable 中定义 VectorIndexes，指定索引名称、向量属性、SearchSchema（分区键和过滤属性）、投影、维度（如 1024）和距离函数（如 COSINE）。注意 Dimensions 和 DistanceFunction 创建后不可修改。
DynamoDB 向量索引的写入和删除是如何工作的？
写入时通过 PutItem 将业务数据和 embedding 一起写入，向量索引由 DynamoDB 自动维护。删除 item 或删除 embedding 属性，索引条目也会消失。TTL 过期同样生效。
DynamoDB 向量搜索的最终一致性如何？
向量索引读取是最终一致的。稳态下写入后基本立即可搜，但索引刚创建完时，即使状态为 ACTIVE，新写入的数据可能需要 30-40 秒才能被搜索到。建议需要读己之写的场景使用基表查询。
使用 DynamoDB 向量索引有哪些注意事项？
注意分区键不是安全边界，SearchVectors 不支持细粒度访问控制；过滤条件仅支持等值；成本按字节计费；维度影响成本；需要验证嵌入模型和维度；CloudFormation 暂不支持向量索引。
DynamoDB 向量索引适合哪些场景，不适合哪些场景？
适合操作型数据已在 DynamoDB 且需要语义检索的场景，如 Agent 记忆。不适合复杂混合检索（如 BM25 融合）、海量冷向量存储、丰富元数据过滤（如范围、IN）等场景。
