DynamoDB唯一性约束机制解析
DynamoDB的PutItemRequest配合ConditionExpression可以用于防止覆盖现有项或确保某些条件成立。例如，使用attribute_not_exists(PK)可以有效防止插入一个与现有主键（Partition Key, PK 或 Partition Key + Sort Key, SK）相同的项，从而实现主键的唯一性。
然而，当尝试将这种逻辑应用于GSI属性时，例如使用attribute_not_exists(#MAC_ADDRESS)，其行为并非如预期般检查整个GSI的全局唯一性。这是因为ConditionExpression是在单个项目级别上进行评估的。它检查的是当前正在处理的这个项目中是否存在指定的属性，而不是扫描整个GSI来查找是否有其他项目拥有相同的属性值。
考虑以下用户尝试的代码片段：
var req = PutItemRequest.builder()
.tableName(TABLE_NAME)
.item(getAllValues(settings))
// 此条件表达式仅检查当前待插入项的属性是否存在，无法用于GSI的跨项唯一性检查
.conditionExpression("attribute_not_exists(#" + MAC_ADDRESS + ") AND attribute_not_exists(#" + REGISTRATION_CODE + ")")
.expressionAttributeNames(Map.of("#" + MAC_ADDRESS, MAC_ADDRESS, "#" + REGISTRATION_CODE, REGISTRATION_CODE))
.build();这段代码的目的是在插入新项时，确保该项的MAC_ADDRESS和REGISTRATION_CODE属性在表中是唯一的。但实际上，attribute_not_exists(#MAC_ADDRESS)只会检查当前要插入的这个项是否已经包含MAC_ADDRESS属性。如果待插入的项本身没有MAC_ADDRESS属性（这是通常情况，因为是新插入），那么这个条件就会满足，允许插入，即使表中其他项已经有了相同的MAC_ADDRESS值。因此，这种方法无法强制GSI属性的跨项唯一性。GSI主要用于提供不同的查询访问模式，而非作为强制数据完整性约束的机制。
GSI唯一性约束的实现策略
由于DynamoDB本身不直接支持GSI属性的全局唯一性约束，我们需要采用不同的策略来实现这一需求。
策略一：基于主键的Schema设计（推荐方案）
在DynamoDB中，实现唯一性的最直接、最高效和推荐的方式是利用主键（分区键和/或排序键）的唯一性特性。如果某个属性（如MAC_ADDRESS或REGISTRATION_CODE）必须是唯一的，那么应考虑将其作为主表的主键或主键的一部分。
示例：
-
如果MAC_ADDRESS是全局唯一的标识符：可以直接将MAC_ADDRESS设置为表的分区键（Partition Key, PK）。这样，每次尝试用相同的MAC_ADDRESS插入新项时，如果该主键已存在，PutItemRequest默认会覆盖现有项。若要防止覆盖，可结合ConditionExpression("attribute_not_exists(PK)")。
// 假设MAC_ADDRESS是主表的分区键 var item = new HashMap
如果唯一性是基于多个属性的组合：例如，REGISTRATION_CODE与另一个DeviceId的组合是唯一的，可以将REGISTRATION_CODE设为分区键，DeviceId设为排序键（Sort Key, SK）。
这种方法利用了DynamoDB主键固有的唯一性，是实现唯一性约束最自然且性能最佳的方式。
策略二：使用事务（TransactWriteItems）模拟唯一性（复杂但可行）
在某些复杂场景下，如果无法将需要唯一性的属性直接作为主键，或者需要在多个属性组合上强制唯一性，可以使用DynamoDB事务（TransactWriteItems）来模拟唯一性。
基本原理：
- 创建一个辅助表（或在主表中设计一个特殊的“唯一性占位符”项），用于存储需要强制唯一性的属性值。
- 当尝试插入主数据项时，同时在同一个事务中尝试向辅助表（或主表中的占位符）写入一个“唯一性标记”项。
- 在写入唯一性标记项时，使用ConditionCheck来确保该标记项不存在。
- 如果该标记项已存在（即该属性值已被占用），整个事务将失败，从而阻止主数据项的插入。
示例流程（概念性）： 假设我们有一个Devices表，其中MAC_ADDRESS是GSI属性，但我们仍想强制其唯一。
- 主表 (Devices): PK: DeviceId, SK: (None)
- 辅助唯一性表 (UniqueMacAddresses): PK: MAC_ADDRESS
-
事务操作 (TransactWriteItems):
- PutItem: 尝试将新设备项插入到Devices表。
- ConditionCheck: 检查UniqueMacAddresses表中是否存在与新设备MAC_ADDRESS相同的项。如果attribute_not_exists(MAC_ADDRESS)条件不满足，则事务失败。
- PutItem: 如果条件检查通过，将MAC_ADDRESS值插入到UniqueMacAddresses表中作为唯一性标记。
缺点：
- 增加复杂性：需要管理额外的表或项，并编写更复杂的事务逻辑。
- 增加成本：事务操作通常比单一操作更昂贵，因为它涉及多个底层操作和额外的协调开销。
- 潜在的并发冲突：在高并发场景下，事务可能会遇到冲突并回滚，需要适当的重试机制。
AWS官方博客文章《Simulating Amazon DynamoDB Unique Constraints Using Transactions》详细介绍了这种方法，可以作为进一步参考。
最佳实践与注意事项
- 优先考虑主键设计：在设计DynamoDB表结构时，始终优先考虑如何通过主键来强制唯一性。这是最符合DynamoDB设计哲学且性能最优的方式。
- 理解GSI的作用：GSI主要用于提供灵活的查询模式，以支持不同于主键的访问需求。它们不适合直接用于强制业务规则的唯一性。
- 重新评估业务需求：在项目初期就明确哪些属性需要唯一性，并据此调整数据模型。如果一个属性在业务上必须是唯一的，那么它通常应该成为主键的一部分。
- 成本与复杂性考量：虽然事务可以模拟GSI的唯一性，但它会引入额外的成本和系统复杂性。除非有非常明确的需求且无法通过主键设计解决，否则应避免过度依赖事务来实现唯一性。
- 应用层逻辑（谨慎使用）：对于非严格的唯一性需求，或者在低并发场景下，可以在应用层先进行一次读取（GetItem或Query）来检查唯一性，然后再进行写入。但这种方法存在竞态条件，不能保证强一致性，在高并发下可能导致重复数据。
总结
在DynamoDB中，直接通过PutItemRequest的ConditionExpression对GSI属性强制跨项唯一性是不可行的。最佳实践是重新审视表的主键设计，将需要唯一性的属性纳入主键，从而利用DynamoDB主键固有的唯一性特性。对于少数无法通过主键实现唯一性的复杂场景，可以考虑使用TransactWriteItems来模拟唯一性，但需要权衡其带来的复杂性、成本和性能影响。理解DynamoDB的设计哲学，并根据实际业务需求选择最合适的唯一性实现策略至关重要。
