DynamoDB 全局二级索引（GSI）唯一性设计与实现

理解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的原生唯一性约束，若要模拟此功能，通常需要更复杂的设计。常见的模拟方法包括：

1. 读-写-检查模式： 在写入之前，先查询GSI以检查是否存在重复项。如果不存在，则进行写入。然而，这种模式存在典型的竞态条件（Race Condition），即在查询和写入之间，其他客户端可能已经插入了相同的唯一值。
2. 使用事务（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<String, AttributeValue> 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());

// 构建PutItemRequest
PutItemRequest request = PutItemRequest.builder()
    .tableName("Devices") // 假设表名为 "Devices"
    .item(item)
    // 使用conditionExpression确保主键为MAC_ADDRESS的项不存在
    // 只有当MAC_ADDRESS作为主键的项不存在时，才允许写入
    .conditionExpression("attribute_not_exists(MAC_ADDRESS)")
    .build();

// 执行PutItemRequest
try {
    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都独立唯一，但它们都不是主表的主键，您可以：

1. 创建一个MacAddressUniquenessTable，以MAC_ADDRESS作为其主键。
2. 创建一个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已存在）而失败，整个事务将回滚，从而保证了所有属性的原子性唯一性。

注意事项：

• 这种方法增加了表的数量和操作的复杂性。
• 事务操作通常比单项操作有更高的延迟和成本。
• 仅当通过主键设计无法满足所有唯一性需求时，才应考虑此方案。

总结与最佳实践

1. DynamoDB原生唯一性仅限于主键： 始终记住，DynamoDB只在其主键（分区键和排序键）上强制唯一性。
2. GSI主要用于查询优化，不提供唯一性保证： 不要依赖GSI来强制数据唯一性。GSI允许其键属性存在重复值。
3. 优先通过主键设计实现唯一性： 在设计DynamoDB表时，优先考虑将业务上必须唯一的属性作为主表的主键。这是实现唯一性最简单、最高效且成本最低的方式。
4. 谨慎使用复杂策略： 对于无法通过主键实现的复杂唯一性需求（例如，多个非主键属性都需要独立唯一），可以考虑使用事务和辅助唯一性表。但请充分评估其带来的复杂性、性能开销和成本。在大多数情况下，良好的主键设计可以避免这些复杂性。

通过理解DynamoDB的唯一性机制并合理设计表结构，您可以有效地管理数据一致性，同时充分利用DynamoDB的高性能和可伸缩性。

以上就是DynamoDB 全局二级索引（GSI）唯一性设计与实现的详细内容，更多请关注php中文网其它相关文章！