本文深入探讨了在Amazon DynamoDB中使用PutItemRequest时，如何有效处理全局二级索引（GSI）的唯一性问题。阐明了conditionExpression在GSI上的局限性，并强调DynamoDB仅在主键上强制唯一性。文章提供了避免复杂事务的推荐方案：通过优化表结构，将需唯一性保证的属性提升为主键，从而简化唯一性约束的实现，并探讨了其他高级策略，旨在帮助开发者构建高效且数据一致的DynamoDB应用。
理解DynamoDB的唯一性与GSI行为
在DynamoDB中，唯一性约束是其核心设计的一部分，但这一特性主要体现在表的主键上。每张DynamoDB表都必须定义一个主键，可以是单一的分区键（Partition Key），也可以是分区键和排序键（Sort Key）的组合。DynamoDB保证，在同一个分区键下，排序键的值是唯一的，从而确保每个项（Item）在表内是唯一的。
然而，全局二级索引（GSI）的行为则有所不同。GSI是为了提供灵活的查询能力而设计的，它允许您基于非主键属性进行高效查询。但关键在于，GSI并不强制其索引键的唯一性。这意味着，即使您将某个属性定义为GSI的分区键或排序键，DynamoDB仍然允许该GSI键存在多个具有相同值的项。
开发者在使用PutItemRequest并结合conditionExpression尝试强制GSI属性唯一性时，常常会遇到预期之外的行为。例如，以下代码片段试图通过检查MAC_ADDRESS和REGISTRATION_CODE这两个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();
这段代码未能实现GSI唯一性，原因在于attribute_not_exists()条件表达式的工作原理。当您执行PutItemRequest时，conditionExpression是在针对要写入的特定项（或基于该项的主键检索到的现有项）进行评估。attribute_not_exists(#MAC_ADDRESS)检查的是：在当前PutItemRequest尝试写入的这个新项中，或者在与这个新项具有相同主键的现有项中，是否存在MAC_ADDRESS这个属性。由于MAC_ADDRESS和REGISTRATION_CODE是您正在尝试插入的项的一部分，这些属性必然存在于item(getAllValues(settings))中，因此attribute_not_exists条件将始终评估为false（即属性存在），导致条件检查失败，或者如果条件表达式是用于阻止覆盖，则会因为属性存在而允许写入。它并不会检查整个GSI中是否存在具有相同MAC_ADDRESS或REGISTRATION_CODE值的其他项。因此，这种方法无法实现跨表的GSI属性唯一性。
GSI唯一性强制的挑战与开销
由于DynamoDB不提供GSI的原生唯一性约束，若要模拟此功能，通常需要更复杂的设计。常见的模拟方法包括：
读-写-检查模式： 在写入之前，先查询GSI以检查是否存在重复项。如果不存在，则进行写入。然而，这种模式存在典型的竞态条件（Race Condition），即在查询和写入之间，其他客户端可能已经插入了相同的唯一值。使用事务（Transactions）： DynamoDB的事务写入（TransactWriteItems）可以用于原子性地执行多个操作。例如，您可以尝试在主表写入数据，并同时在另一个辅助表（该辅助表以需要唯一性的属性作为主键）中写入一个占位符项，并利用ConditionCheck来确保该占位符项不存在。如果任何一个操作失败（包括条件检查），整个事务都会回滚。虽然事务可以解决竞态条件，但它会引入额外的复杂性、性能开销和成本。AWS官方博客中也曾探讨过如何通过事务来模拟唯一性约束，但这通常被视为一种高级且有代价的解决方案。
鉴于上述挑战和开销，对于大多数需要唯一性保证的场景，更推荐从表结构设计层面进行优化。
推荐方案：通过表结构设计实现唯一性
最有效且成本最低的实现唯一性约束的方法是充分利用DynamoDB主键的固有唯一性。
策略一：将唯一属性提升为主键
如果某个属性（例如MAC_ADDRESS或REGISTRATION_CODE）在您的业务逻辑中必须是全局唯一的，那么最直接且推荐的做法是将其设计为主表的主键（分区键或复合主键的一部分）。
示例：将MAC_ADDRESS作为主分区键
假设您的业务需求是MAC_ADDRESS必须在整个表中唯一，并且它能够作为项的唯一标识符。您可以将MAC_ADDRESS设置为表的主分区键。
// 假设表名为 "Devices", 主键为 "MAC_ADDRESS" (分区键)// 如果MAC_ADDRESS必须是唯一的，将其作为主键String macAddressToInsert = "000000000000"; // 示例MAC地址// 准备要插入的项Map item = new HashMap();item.put("MAC_ADDRESS", AttributeValue.builder().s(macAddressToInsert).build());item.put("RegistrationCode", AttributeValue.builder().s("CODE123").build());item.put("DeviceName", AttributeValue.builder().s("MySmartDevice").build());// 构建PutItemRequestPutItemRequest request = PutItemRequest.builder() .tableName("Devices") // 假设表名为 "Devices" .item(item) // 使用conditionExpression确保主键为MAC_ADDRESS的项不存在 // 只有当MAC_ADDRESS作为主键的项不存在时，才允许写入 .conditionExpression("attribute_not_exists(MAC_ADDRESS)") .build();// 执行PutItemRequesttry { dynamoDbClient.putItem(request); System.out.println("成功插入设备信息。MAC地址: " + macAddressToInsert);} catch (ConditionalCheckFailedException e) { // 如果MAC_ADDRESS已存在，则会抛出此异常 System.err.println("错误：MAC地址 " + macAddressToInsert + " 已存在。");} catch (Exception e) { System.err.println("插入设备信息时发生错误: " + e.getMessage());}
解释：
当MAC_ADDRESS作为主表的分区键时，attribute_not_exists(MAC_ADDRESS)会检查表中是否已经存在一个主键为该MAC_ADDRESS的项。如果存在，ConditionalCheckFailedException将被抛出，从而阻止重复插入，有效实现了MAC_ADDRESS的唯一性。如果REGISTRATION_CODE也需要独立唯一，但不能与MAC_ADDRESS组成复合主键（因为它们可能属于不同的唯一维度），那么情况会更复杂，可能需要考虑下面的辅助表策略。
策略二：使用辅助唯一性表（仅在必要时）
在某些复杂场景下，如果多个非主键属性都需要保证唯一性，并且它们无法合理地组合成主表的主键，或者主键已经由其他业务需求决定，那么可以考虑使用一个或多个辅助唯一性表。
这种策略的核心思想是：为每个需要唯一性的属性创建一个单独的DynamoDB表。这个辅助表只包含一个主键，即需要保证唯一性的那个属性的值。当您向主表写入数据时，同时尝试向这些辅助表写入一个占位符项。
例如，如果您需要MAC_ADDRESS和REGISTRATION_CODE都独立唯一，但它们都不是主表的主键，您可以：
创建一个MacAddressUniquenessTable，以MAC_ADDRESS作为其主键。创建一个RegistrationCodeUniquenessTable，以REGISTRATION_CODE作为其主键。
在写入主表数据时，使用TransactWriteItems操作，原子性地执行以下步骤：
向主表写入实际数据。向MacAddressUniquenessTable写入一个包含MAC_ADDRESS的项，并使用conditionExpression(“attribute_not_exists(MAC_ADDRESS)”)。向RegistrationCodeUniquenessTable写入一个包含REGISTRATION_CODE的项，并使用conditionExpression(“attribute_not_exists(REGISTRATION_CODE)”)。
如果任何一个辅助表的写入操作因为条件检查失败（即对应的MAC_ADDRESS或REGISTRATION_CODE已存在）而失败，整个事务将回滚，从而保证了所有属性的原子性唯一性。
注意事项：
这种方法增加了表的数量和操作的复杂性。事务操作通常比单项操作有更高的延迟和成本。仅当通过主键设计无法满足所有唯一性需求时，才应考虑此方案。
总结与最佳实践
DynamoDB原生唯一性仅限于主键： 始终记住，DynamoDB只在其主键（分区键和排序键）上强制唯一性。GSI主要用于查询优化，不提供唯一性保证： 不要依赖GSI来强制数据唯一性。GSI允许其键属性存在重复值。优先通过主键设计实现唯一性： 在设计DynamoDB表时，优先考虑将业务上必须唯一的属性作为主表的主键。这是实现唯一性最简单、最高效且成本最低的方式。谨慎使用复杂策略： 对于无法通过主键实现的复杂唯一性需求（例如，多个非主键属性都需要独立唯一），可以考虑使用事务和辅助唯一性表。但请充分评估其带来的复杂性、性能开销和成本。在大多数情况下，良好的主键设计可以避免这些复杂性。
通过理解DynamoDB的唯一性机制并合理设计表结构，您可以有效地管理数据一致性，同时充分利用DynamoDB的高性能和可伸缩性。
以上就是DynamoDB 全局二级索引（GSI）唯一性设计与实现的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/134692.html
微信扫一扫 
支付宝扫一扫 
