DynamoDB访问模式变更后的辅助存储方案选型咨询

1. 适配新访问模式的方案选择 #

结合你的系统现状（DynamoDB作为唯一数据源、依赖Streams/TTL处理后逻辑、新UI的多维度查询需求），更推荐基于DynamoDB Streams同步的OpenSearch方案，其次是Aurora Serverless Postgres方案，完全不建议在DynamoDB中加大量索引的方案，具体分析：

Aurora Serverless Postgres（辅助SQL存储） #

• 优势：SQL天生适配offset/limit/order by这类固定分页和多属性排序筛选，开发上手快，复杂结构化查询逻辑容易实现。
• 关键注意点：别用应用双写模式，双写大概率会出现数据不一致（比如DynamoDB写成功但Postgres写失败），直接用DynamoDB Streams触发Lambda同步数据，能保证最终一致性。另外你的树形JSON属性可以用Postgres的JSONB类型存储，但查询灵活性不如DynamoDB原生，要是新UI不需要查这个字段，甚至可以不同步它。

OpenSearch（搜索型辅助存储） #

• 完美匹配需求：天然支持多属性排序、多维度筛选、全文检索，自定义页大小的固定分页也能轻松实现。同样用DynamoDB Streams同步数据，和主库保持最终一致。尤其是全文检索这个需求，Postgres虽然能做，但性能和灵活性远不如OpenSearch，刚好覆盖你新UI的核心能力。
• 成本优化：只同步新UI需要的属性就行，不用全量复制，省存储也省同步资源。

DynamoDB加大量索引+并行查询 #

• 不建议采用：DynamoDB的二级索引有数量限制，而且每个GSI只能对应一组分区键+排序键，多属性筛选需要多个GSI配合，然后在应用层合并结果、去重、排序，逻辑复杂度拉满，数据量大的时候性能会崩。另外维护大量索引会增加DynamoDB的写入延迟和存储成本，完全不符合你“不迁移但高效适配新需求”的目标，直接pass。

2. 复制部分属性数据的可行性 #

完全可行，这是这类场景下的常规操作：

• 只同步新UI用到的字段（比如用于排序、筛选、检索的属性），没必要复制整个实体，减少同步开销和辅助存储的占用。
• 一致性保障：必须用DynamoDB Streams做同步，别搞应用双写，Streams能捕获DynamoDB的所有变更（包括TTL过期删除），确保辅助存储的数据和主库最终一致。
• 树形JSON属性：如果新UI不需要基于它做查询，就不用同步；如果需要嵌套字段筛选，OpenSearch对JSON的支持比Postgres更顺手。

3. 业内同行的通用解法 #

业内碰到“主库适配不了新查询但不想迁移”的情况，普遍用多存储组合策略：

• 保留原数据库（DynamoDB）作为唯一数据源，所有写入和核心业务访问都走它，保证数据的单一可信来源。
• 根据新查询需求选对应的辅助存储：
  • 复杂结构化查询、固定分页 → 上SQL数据库（比如Aurora Serverless、RDS）。
  • 全文检索、多维度筛选排序 → 用搜索引擎（比如OpenSearch、Elasticsearch）。
• 用数据库的变更流（比如DynamoDB Streams）同步数据，彻底避免应用双写的一致性问题。
• 辅助存储只做只读查询，不接收写入，所有变更都从主库同步过来。

内容的提问来源于stack exchange，提问作者Franklin