dynamodb全局二级索引（gsi）不支持基于表达式的条件性投影。然而，可以通过构建稀疏gsi来模拟条件性索引行为。核心策略是：仅当基表中的项目满足特定条件时，才在该项目上设置gsi分区键属性。当该属性存在时，项目会被索引；当该属性缺失时，项目则不会被索引。这种方法允许开发者根据业务逻辑动态地将项目添加或移除出gsi，从而实现高效且灵活的条件性数据查询。
理解DynamoDB GSI与条件性索引的挑战
全局二级索引（GSI）是DynamoDB中实现灵活查询的关键组件，它允许用户通过不同于主键的属性进行查询。然而，DynamoDB GSI在设计上并不支持直接的“条件性投影”功能，这意味着你不能像在关系型数据库中那样，通过一个WHERE子句来决定哪些记录应该被包含在索引中。GSI的创建通常指定一个分区键（和可选的排序键），然后索引会包含所有在基表中拥有这些键属性的项目。
在某些业务场景中，我们可能希望GSI只包含满足特定条件的项目。例如，在一个订单管理系统中，可能只希望索引“待处理”状态的订单，以便快速查询需要人工干预的订单。当订单状态变为“已完成”时，它就不再需要出现在这个“待处理”索引中。直接的GSI并不能满足这种动态的条件性需求。
稀疏GSI：实现条件性索引的策略
为了克服GSI不支持条件性投影的限制，DynamoDB提供了一种强大的模式：稀疏全局二级索引（Sparse Global Secondary Index）。这个策略的核心思想是利用DynamoDB GSI的一个特性：如果一个项目不包含GSI定义的分区键（或排序键）属性，那么该项目将不会被包含在GSI中。
基于此，我们可以设计一个GSI，其分区键是一个“辅助性”属性，这个属性只在基表中的项目满足特定条件时才存在。
实现步骤：
- 定义一个GSI辅助属性： 在你的基表设计中，引入一个新的属性，我们称之为“GSI辅助属性”或“GSI标志属性”。这个属性本身可以是一个简单的字符串（例如'ACTIVE'、'INTERMEDIATE'）或者任何你认为合适的值。
- 创建GSI： 使用这个“GSI辅助属性”作为GSI的分区键。你可以选择性地添加一个排序键，以及定义投影属性（ALL、KEYS_ONLY或INCLUDE）。
-
动态管理GSI辅助属性：
- 当基表中的一个项目满足被索引的条件时，向该项目添加GSI辅助属性，并赋予一个值。一旦该属性存在，DynamoDB会自动将该项目添加到GSI中。
- 当基表中的一个项目不再满足被索引的条件时，从该项目移除GSI辅助属性。一旦该属性被移除，DynamoDB会自动将该项目从GSI中移除。
示例：条件性索引中间状态的附件
让我们以问题描述中的Attachment表为例。我们希望构建一个GSI，仅包含isIntermediateState = 1的附件记录。当isIntermediateState变为0时，这些记录应从GSI中移除。
基表结构：
- Attachment (PK: attachmentId)
- attachmentId (String)
- customerState (String: Attaching, Detaching, Attached, Detached)
- isIntermediateState (Number: 1 或 0)
目标： GSI只包含isIntermediateState = 1的记录。
解决方案：
- 定义GSI辅助属性： 我们引入一个名为GSI1PK的属性。
-
创建GSI： 创建一个名为IntermediateAttachmentsGSI的GSI，其分区键为GSI1PK。
- GSI名称: IntermediateAttachmentsGSI
- GSI分区键: GSI1PK (String)
- 投影属性: ALL (或根据需求选择KEYS_ONLY/INCLUDE)
-
管理GSI辅助属性：
- 当Attachment项目的isIntermediateState为1时（即customerState为Attaching或Detaching），我们设置GSI1PK属性，例如GSI1PK = 'INTERMEDIATE'。
- 当Attachment项目的isIntermediateState为0时（即customerState为Attached或Detached），我们移除GSI1PK属性。
示例代码（概念性DynamoDB更新操作）：
假设我们有一个attachmentId为'abc-123'的附件。
场景一：将附件添加到GSI（当isIntermediateState变为1时）
{
"TableName": "Attachment",
"Key": {
"attachmentId": { "S": "abc-123" }
},
"UpdateExpression": "SET customerState = :cs, isIntermediateState = :is, GSI1PK = :gsiPk",
"ExpressionAttributeValues": {
":cs": { "S": "Attaching" },
":is": { "N": "1" },
":gsiPk": { "S": "INTERMEDIATE" }
}
}执行此更新后，该项目将包含GSI1PK属性，从而被IntermediateAttachmentsGSI索引。
场景二：将附件从GSI中移除（当isIntermediateState变为0时）
{
"TableName": "Attachment",
"Key": {
"attachmentId": { "S": "abc-123" }
},
"UpdateExpression": "SET customerState = :cs, isIntermediateState = :is REMOVE GSI1PK",
"ExpressionAttributeValues": {
":cs": { "S": "Attached" },
":is": { "N": "0" }
}
}执行此更新后，GSI1PK属性将从项目中移除。由于该属性不再存在，DynamoDB会自动将此项目从IntermediateAttachmentsGSI中移除。
查询GSI：
要查询所有处于中间状态的附件，你可以对IntermediateAttachmentsGSI执行一个Query操作：
{
"TableName": "Attachment",
"IndexName": "IntermediateAttachmentsGSI",
"KeyConditionExpression": "GSI1PK = :gsiPk",
"ExpressionAttributeValues": {
":gsiPk": { "S": "INTERMEDIATE" }
}
}这将返回所有当前isIntermediateState = 1的附件记录。
注意事项与最佳实践
- 原子性操作： 在更新基表项目时，确保customerState、isIntermediateState以及GSI辅助属性的更新是原子性的。使用UpdateItem操作可以确保这些更改同时发生，避免数据不一致。
- GSI的最终一致性： DynamoDB GSI是最终一致的。这意味着从基表更新到GSI反映这些更改之间可能存在短暂的延迟。对于需要强一致性的场景，可能需要额外的逻辑来处理。
- 成本考量： 稀疏GSI可以有效降低成本，特别是当只有一小部分基表项目需要被索引时。因为只有包含GSI分区键的项目才会占用GSI的存储和吞吐量。
- 属性命名： 为GSI辅助属性选择一个清晰的名称（例如_gsi1_pk或status_index_key），以明确其用途。
- 多个稀疏GSI： 如果需要多个不同条件的稀疏GSI，可以为每个GSI定义一个独立的辅助属性。
总结
尽管DynamoDB GSI不提供直接的条件性投影功能，但通过巧妙地利用其稀疏索引特性，我们可以实现高度灵活的条件性数据索引。核心在于根据业务逻辑动态地添加或移除GSI分区键属性。这种模式不仅能满足复杂的查询需求，还能在存储和吞吐量方面带来成本效益，是DynamoDB高级应用中一个非常实用的设计模式。
