使用DynamoDB filter expression还是代码层过滤效果更好？

先明确选型的核心前提：DynamoDB 的 Filter Expression 不是下推到存储层的过滤，是读取完数据后在 Dynamo 服务侧执行的过滤，你仍然需要为扫描/查询到的全部数据支付 RCU 费用，也不会突破单次查询最多返回 1MB 数据的限制，很多团队选型时容易忽略这个特性踩坑。

两种方案的适用场景 #

• 优先选 Dynamo 侧 Filter Expression 的情况：
  • 不需要在应用层写额外的过滤逻辑，代码更简洁，查询逻辑统一收口在 DB 操作层
  • 过滤后的数据量比原始查询结果小很多，能有效降低网络传输开销，减少数据返回延迟
  • 过滤逻辑简单，不需要结合其他非 Dynamo 存储的业务数据做判断，Filter Expression 的能力完全可以覆盖需求
• 优先选应用层过滤的情况：
  • 同一份原始查询结果需要复用做多种过滤处理，比如同一份模板列表既要给前端返回激活状态的，又要给管理后台返回全量状态的，只查一次 Dynamo 就能满足两个需求，节省重复查询的 RCU 开销
  • 过滤逻辑复杂，Dynamo Filter Expression 的语法能力无法覆盖，比如需要结合自定义业务规则、关联其他存储的配置做判断
  • 后续有更换存储引擎的规划，应用层实现过滤不依赖 Dynamo 专属语法，迁移成本更低

针对你当前场景的选型建议 #

你的场景是查询 deal-template 列表仅返回激活状态条目，可根据数据分布做选择：

1. 如果绝大多数模板都是激活状态，停用的占比很低，两种方案差异极小，选团队写起来更顺手的即可，更推荐用 Dynamo 侧 Filter Expression，少写额外的循环过滤逻辑
2. 如果停用的模板占比很高（超过 30%），优先建议你新增以激活状态作为分区键/排序键的 GSI，直接查 GSI 就能只拉取激活的模板，从根本上降低 RCU 消耗，性价比远高于在两种过滤方案中二选一。如果暂时无法调整表结构，就看业务后续规划：如果后续只会保留「仅返回激活模板」这一种查询逻辑就选 Dynamo 侧过滤，如果后续可能扩展多状态查询需求就选应用层过滤，扩展性更强。

Dynamo 侧实现代码示例 #

filterCondition := expression.Name(activeColumn).Equal(expression.Value(true))

应用层实现代码示例 #

List<DealTemplate> templates = getTemplate();
for (DealTemplate template : templates) {
    if (template.isActive) {
        // 业务处理逻辑
    }
}

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