DynamoDBGSI唯一性与PutItem限制详解

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《DynamoDB GSI唯一性与PutItem限制解析》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

在Amazon DynamoDB中，PutItemRequest结合ConditionExpression是执行条件写入操作的强大工具。开发者常希望利用这一机制来确保特定属性的全局唯一性，尤其当这些属性作为全局二级索引（GSI）的一部分时。然而，对于GSI属性的全局唯一性检查，ConditionExpression的行为可能与直觉不符，导致意外的写入成功。

理解ConditionExpression与GSI唯一性

问题中提到的代码片段如下：

var req = PutItemRequest.builder()
            .tableName(TABLE_NAME)
            .item(getAllValues(settings))
            .conditionExpression("attribute_not_exists(#" + MAC_ADDRESS + ") AND attribute_not_exists(#" + REGISTRATION_CODE + ")")
            .expressionAttributeNames(Map.of("#" + MAC_ADDRESS, MAC_ADDRESS, "#" + REGISTRATION_CODE, REGISTRATION_CODE))
            .build();

这里的核心误解在于attribute_not_exists(attribute_name)条件表达式的作用范围。当在PutItemRequest中使用此条件时，它主要用于以下两种场景：

1. 防止覆盖现有项： 如果attribute_name是表的主键（分区键或复合主键），则条件表示“只有当主键对应的项不存在时才执行写入”。这是最常见的防止重复创建项的方法。
2. 检查当前写入项的属性是否存在： 如果attribute_name是待写入项中的一个普通属性，则条件表示“只有当待写入的这个项中不包含名为attribute_name的属性时才执行写入”。

关键点在于： attribute_not_exists条件表达式不会扫描整个表或GSI来检查MAC_ADDRESS或REGISTRATION_CODE的值是否已存在于其他**项中。它只针对当前正在处理的PutItemRequest所涉及的项进行评估。

在上述示例中，如果getAllValues(settings)返回的item中包含了MAC_ADDRESS和REGISTRATION_CODE这两个属性，那么attribute_not_exists(#MAC_ADDRESS)和attribute_not_exists(#REGISTRATION_CODE)将评估为false，因为这些属性在待写入的项中是存在的。因此，无论这些MAC地址或注册码是否已存在于其他项中，条件表达式都将失败，导致PutItem操作无条件成功（除非主键冲突）。

全局二级索引（GSI）的主要目的是提供灵活的查询能力，允许您使用与主键不同的属性集来访问数据。它们本身不强制执行全局唯一性约束。即使您在GSI中定义了某个属性作为分区键，DynamoDB也允许GSI中的分区键值在不同的GSI项中重复出现，只要它们属于不同的主表项即可。

模拟GSI唯一性约束的复杂性

虽然DynamoDB本身不直接支持GSI的全局唯一性约束，但可以通过更复杂的机制来模拟。AWS官方博客曾介绍过一种使用DynamoDB事务（Transactions）来模拟唯一性约束的方法。

基本思路：

1. 创建“影子”表或唯一性检查表： 为需要唯一性的属性（例如MAC_ADDRESS）创建一个单独的表，或者在主表中为每个需要唯一性的属性创建一个特殊的“唯一性检查项”。
2. 事务性写入： 使用TransactWriteItems操作，在一个事务中同时执行两个写入：
   • 将实际数据写入主表。
   • 将一个包含唯一属性值（例如MAC_ADDRESS作为主键）的项写入“影子”表或唯一性检查项。此写入操作会附带attribute_not_exists条件，确保该唯一属性值在“影子”表中是首次出现。
3. 原子性保证： 如果“影子”表的写入因唯一性冲突而失败（即attribute_not_exists条件不满足），整个事务将回滚，主表的写入也不会发生。

注意事项：

• 开销增加： 事务操作会引入额外的请求单位（RCU/WCU）开销，因为需要执行多次写入操作。
• 复杂性增加： 这种方法需要额外的表设计和更复杂的应用逻辑来管理事务。
• 性能考量： 对于高吞吐量的场景，频繁的事务操作可能会对性能产生影响。

最佳实践：重新思考表结构设计

鉴于模拟GSI唯一性约束的复杂性和开销，更推荐的方法是重新评估和优化您的DynamoDB表结构设计。

如果MAC_ADDRESS或REGISTRATION_CODE在您的应用中是必须全局唯一的标识符，那么最自然和高效的方式是：

1. 将其作为主表的主键：

   • 分区键： 如果MAC_ADDRESS本身足以唯一标识一个项，可以考虑将其作为主表的分区键（Partition Key）。DynamoDB强制分区键的唯一性，确保不会有两个项具有相同的分区键。
   • 复合主键： 如果需要结合其他属性来唯一标识，可以将其作为复合主键（Partition Key + Sort Key）的一部分。例如，MAC_ADDRESS作为分区键，DEVICE_ID作为排序键。

   示例：将MAC_ADDRESS设为主表分区键 假设您的表主键是MAC_ADDRESS。那么，当您尝试插入一个新项时，可以使用以下PutItemRequest来防止重复：

   var req = PutItemRequest.builder()
               .tableName(TABLE_NAME)
               .item(getAllValues(settings))
               .conditionExpression("attribute_not_exists(MAC_ADDRESS)") // 假设MAC_ADDRESS是主键
               .build();

   这里的attribute_not_exists(MAC_ADDRESS)会检查是否存在相同MAC_ADDRESS的项。如果存在，操作将失败，从而实现唯一性。

2. 应用层预检查： 对于非主键的属性，如果唯一性要求不那么严格，或者性能要求极高，可以在写入前在应用层进行一次Query或GetItem操作来检查该值是否已存在。如果存在则拒绝写入。但这会引入竞态条件，不适用于强一致性要求。

总结

在DynamoDB中，PutItemRequest的ConditionExpression主要用于基于主键或当前写入项的属性进行条件判断，它无法直接在全局二级索引（GSI）上强制执行全局唯一性。当您需要确保某个属性的全局唯一性时，应优先考虑将其作为主表主键的一部分。如果这不可行，且强唯一性是强制要求，那么采用基于事务的复杂方案可以模拟实现，但需要权衡其带来的开销和复杂性。理解ConditionExpression的实际作用范围，并结合DynamoDB的特性进行合理的表结构设计，是构建高效、健壮应用程序的关键。

本篇关于《DynamoDBGSI唯一性与PutItem限制详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！