本文探讨了如何在 amazon dynamodb 中实现全局二级索引（gsi）的条件性增删记录，以满足特定业务逻辑的需求。通过利用稀疏 gsi 的原理，即基于索引键属性的存在与否来控制记录是否包含在 gsi 中，开发者可以灵活地根据基表项的属性值动态管理 gsi 的内容。文章提供了具体实现方法、示例代码及注意事项，旨在帮助读者构建更高效、更具针对性的 dynamodb 索引策略。
DynamoDB 全局二级索引与条件性需求
Amazon DynamoDB 的全局二级索引（GSI）是一种强大的工具，它允许用户通过不同于基表主键的属性集进行查询，从而提高数据访问的灵活性。然而，在某些场景下，我们可能不希望基表中的所有记录都包含在 GSI 中，而是希望根据记录的特定属性值进行条件性地增删。
例如，考虑一个名为 Attachment 的基表，其中包含 customerState（客户状态，如 Attaching、Detaching、Attached、Detached）和 isIntermediateState（是否为中间状态，1 表示 Attaching 或 Detaching，0 表示 Attached 或 Detached）字段。我们的目标是构建一个 GSI，只包含 isIntermediateState = 1 的记录。当 isIntermediateState 从 1 变为 0 时，相应的记录应从 GSI 中移除。
DynamoDB GSI 本身并不支持基于表达式的条件性投影（Conditional Projection）。这意味着我们不能直接定义一个 GSI，并附加一个条件（例如 WHERE isIntermediateState = 1）来过滤记录。GSI 会自动索引基表中所有包含其定义键属性的项。因此，要实现条件性增删，我们需要利用 DynamoDB 的一个特性：稀疏 GSI（Sparse GSI）。
利用稀疏 GSI 实现条件性索引
稀疏 GSI 的核心思想是：如果一个 GSI 的分区键（或分区键和排序键）属性在基表项中不存在，那么该项就不会被包含在 GSI 中。反之，如果这些键属性存在，则该项会被索引。通过动态地在基表项中添加或移除 GSI 的键属性，我们就可以实现对 GSI 记录的条件性控制。
实现步骤：
引入 GSI 专用属性： 在基表项中引入一个或多个专门用于 GSI 的属性。这些属性的命名应清晰，表明其 GSI 键的用途。例如，我们可以添加一个名为 GSI_IntermediatePK 的属性。
-
定义 GSI： 使用这个新引入的属性作为 GSI 的分区键（或组合键的一部分）。
- GSI 名称: IntermediateStateIndex
- GSI 分区键: GSI_IntermediatePK
- GSI 排序键（可选）: 如果需要，可以基于其他属性定义排序键。
-
动态管理 GSI 键属性：
- 添加记录到 GSI： 当基表项满足条件（例如 isIntermediateState = 1）时，更新该项，添加 GSI_IntermediatePK 属性。其值可以是一个常量（例如 "INTERMEDIATE_STATE"）或者一个能反映业务逻辑的标识符。
- 从 GSI 移除记录： 当基表项不再满足条件（例如 isIntermediateState = 0）时，更新该项，移除 GSI_IntermediatePK 属性。
示例：Attachment 表的条件性 GSI
假设我们希望 GSI 只包含 isIntermediateState = 1 的 Attachment 记录。
GSI 定义： 创建一个名为 IntermediateStateIndex 的 GSI，其分区键为 GSI_IntermediatePK。
-
数据管理逻辑：
-
当 customerState 变为 Attaching 或 Detaching 时（即 isIntermediateState 变为 1）： 更新 Attachment 项，添加 GSI_IntermediatePK 属性。
{ "attachmentId": "uuid-123", "customerState": "Attaching", "isIntermediateState": 1, "GSI_IntermediatePK": "ACTIVE_INTERMEDIATE_STATE" // 添加此属性 }对应的 DynamoDB UpdateItem 操作（伪代码）：
import boto3 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('Attachment') def update_attachment_to_intermediate(attachment_id): table.update_item( Key={'attachmentId': attachment_id}, UpdateExpression="SET customerState = :cs, isIntermediateState = :is, GSI_IntermediatePK = :gsi_pk", ExpressionAttributeValues={ ':cs': 'Attaching', # 或 Detaching ':is': 1, ':gsi_pk': 'ACTIVE_INTERMEDIATE_STATE' } ) -
当 customerState 变为 Attached 或 Detached 时（即 isIntermediateState 变为 0）： 更新 Attachment 项，移除 GSI_IntermediatePK 属性。
{ "attachmentId": "uuid-123", "customerState": "Attached", "isIntermediateState": 0 // GSI_IntermediatePK 属性被移除 }对应的 DynamoDB UpdateItem 操作（伪代码）：
def update_attachment_to_final(attachment_id): table.update_item( Key={'attachmentId': attachment_id}, UpdateExpression="SET customerState = :cs, isIntermediateState = :is REMOVE GSI_IntermediatePK", ExpressionAttributeValues={ ':cs': 'Attached', # 或 Detached ':is': 0 } )
-
注意事项与最佳实践
GSI 自动更新： DynamoDB 会自动且持续地维护 GSI。当基表中的项被修改时，如果 GSI 的键属性发生变化（添加、移除或修改值），DynamoDB 会自动更新 GSI。这意味着您无需担心手动同步 GSI，只需正确管理基表中的 GSI 键属性即可。
属性命名： 为 GSI 专用的键属性选择清晰、描述性的名称，以避免混淆，例如 GSI1_PK、GSI_STATUS_SK 等。
-
查询稀疏 GSI： 查询稀疏 GSI 时，您需要指定 GSI 分区键的值。例如，要查询所有处于中间状态的附件：
response = table.query( IndexName='IntermediateStateIndex', KeyConditionExpression='GSI_IntermediatePK = :pk_value', ExpressionAttributeValues={ ':pk_value': 'ACTIVE_INTERMEDIATE_STATE' } ) 成本效益： 稀疏 GSI 可以带来成本效益，特别是当只有一小部分基表记录需要被索引时。由于 GSI 只存储实际存在的索引键属性的记录，因此可以减少 GSI 的存储空间和相应的读写容量单位消耗。
原子性操作： 在更新基表项时，请确保添加或移除 GSI 键属性的操作与更新其他相关属性（如 isIntermediateState）是原子性的。这可以通过单个 UpdateItem 操作完成，以保证数据的一致性。
总结
尽管 DynamoDB GSI 不直接支持基于表达式的条件性投影，但通过巧妙地利用稀疏 GSI 的原理，我们可以实现高度灵活的条件性索引策略。通过在基表项中动态地添加或移除 GSI 的键属性，开发者可以精确控制哪些记录被包含在 GSI 中，从而满足复杂的业务需求，同时可能优化存储和读写成本。这种方法是 DynamoDB 设计模式中一个非常实用的技巧，适用于需要根据数据状态动态调整索引内容的应用场景。
