DynamoDB搭建相关最佳实践及核心功能问题咨询

1. 使用DynamoDB过程中需要遵循哪些最佳实践与使用规范？ #

• 表设计优先采用单表设计，将多实体数据存储在同一张表中，减少跨表查询开销
• 分区键选择要保证基数足够大，避免出现热分区，不要用取值范围极小的字段（比如布尔值、仅少数可选值的枚举字段）作为分区键
• 生产环境尽量避免全表Scan操作，大表Scan会消耗大量读容量单位（RCU），延迟也不可控
• 按需配置读写容量模式：流量波动大的场景优先用按需模式，流量稳定的场景用预置模式搭配自动扩缩容
• 频繁访问的属性不要放在嵌套结构深层，减少查询解析开销
• 不需要长期保留的历史数据配置TTL自动过期，无需手动批量删除，节省操作成本
• 批量操作时控制单批次条目数量不超过100条，总大小不超过16MB，避免触发请求阈值限制

2. Query和Scan操作有什么区别？如果我要查找属性“Checked”等于False的条目，属于Scan还是Query操作？ #

两者核心差异是数据检索逻辑：

• Query必须指定分区键的精确值，可额外搭配排序键的条件过滤，只会扫描分区键对应单个分区内的指定范围数据，性能稳定，成本和实际扫描的数据量成正比
• Scan会遍历整张表所有分区的全部数据，再按过滤条件返回匹配条目，性能随表数据量增大线性下降，相同查询量下成本远高于Query

如果Checked既不是主表的分区键，也不是二级索引的分区键，直接查找Checked=False默认属于Scan操作，数据量大时开销极高，不建议直接使用。

3. 使用UUID作为分区键是否合理？会对Query、Scan的成本产生影响吗？ #

UUID作为分区键是非常合理的选择：UUID随机性强、基数足够大，能保证数据均匀分布在所有存储分区，完全避免热分区问题，属于DynamoDB分区键的首选方案之一。

对成本的影响：

• 对Query完全无负面影响：Query本身就是按分区键精确值查询，UUID作为分区键不会改变Query的扫描数据量，成本和其他类型的分区键完全一致
• 对Scan无直接影响：Scan成本仅和扫描的总数据量挂钩，和分区键类型无关。但UUID的均匀分布特性可以避免热分区导致的额外限流开销，间接降低异常场景的冗余成本。

4. 如何借助二级索引实现上述属性查找的需求？ #

你需要针对Checked属性创建全局二级索引（GSI），常用有两种方案：

1. 低基数场景（Checked仅True/False两个取值）：将GSI的分区键设为Checked，排序键可搭配你需要的其他过滤字段（比如创建时间），创建完成后直接对该GSI执行Query操作，指定分区键值为False，即可直接拿到所有匹配条目，成本远低于全表Scan。

注意：如果Checked=False的条目占总表数据的20%以上，建议额外加一个分类字段作为GSI分区键，避免GSI出现热分区。

2. 多条件过滤场景：如果查询还要搭配其他业务维度的过滤，可以把对应的业务字段作为GSI分区键，Checked作为排序键，查询时指定业务维度的分区键值+Checked=False的排序键条件，查询性能更高。

5. 采用定时触发Lambda查询DynamoDB执行对应操作的架构是否合理？和使用DynamoDB Stream的方案相比哪个更优？ #

两种方案适用场景完全不同，没有绝对的优劣，可按需选择：

• 定时触发Lambda架构适合离线批量处理场景，比如每天凌晨统计前一天所有Checked=False的条目做批量处理，对实时性要求不高的场景下成本更低，架构更简单。但如果数据更新频率高、需要接近实时的响应，定时方案会有固定延迟，且每次查询扫描大量数据时成本较高。
• DynamoDB Stream方案适合近实时触发场景，只要表数据发生变更就会触发Lambda执行，延迟通常在毫秒级，无需主动查询DynamoDB，仅处理变更的单条/少量数据，RCU开销极低。但如果业务不需要实时处理、仅需定期批量操作，Stream方案会产生大量Lambda调用，反而成本更高。

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