如何按最佳实践创建含String List与布尔值的DynamoDB表？

嘿，针对你的业务场景——每个国家对应一个布尔值，还要根据布尔值执行不同逻辑，我得说为每个国家单独创建一行记录绝对是最符合DynamoDB最佳实践的方案。咱们先拆解下为什么其他初步想法不太靠谱，再讲具体的设计细节：

先排除不合理的方案 #

• 把布尔值作为主键：DynamoDB的主键必须全局唯一，但布尔值只有true和false两个值，根本存不了多个国家，直接pass。
• 把布尔值当主键、List当另一属性：同样存在主键重复的问题，而且List存所有国家的话，后续修改单个国家的布尔值需要全量读写整个List，不仅效率低，还容易引发并发冲突，单条记录大小也可能超限（DynamoDB单条记录最大400KB）。

推荐的表结构设计 #

核心表结构 #

• 分区键（Partition Key）：用country（String类型），每个国家名称作为唯一键，比如"China"、"USA"。这样查询单个国家的布尔值是O(1)的高效操作，直接通过主键检索即可。
• 第二个属性：比如命名为isTarget（Boolean类型），存储对应国家的布尔标记。

举个例子，表中的两条记录会是这样：

{
  "country": "China",
  "isTarget": true
},
{
  "country": "USA",
  "isTarget": false
}

针对“按布尔值批量查询”的优化 #

如果你的业务需要频繁查询所有isTarget = true或isTarget = false的国家，直接用Scan加过滤条件会很慢（全表扫描），这时候建议创建全局二级索引（GSI）：

• GSI的分区键设为isTarget（Boolean类型）
• 投影属性选择country（或者全表投影，根据你的需求）

这样查询所有符合条件的国家时，直接查询GSI就能快速拿到结果，避免全表扫描的性能损耗。

额外的最佳实践 #

• 属性名尽量简短：比如用ctry代替country，flag代替isTarget，能减少存储和读写操作的成本（DynamoDB按数据量计费）。
• 并发修改防护：如果有多个客户端可能同时修改同一个国家的布尔值，可以添加一个version（Number类型）属性，用乐观锁机制（更新时带上当前版本号，版本不匹配则拒绝更新）避免数据冲突。
• 避免过度设计：不需要额外的排序键，除非你有按其他维度排序查询的需求，当前场景下分区键足够。

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