DynamoDB中利用稀疏GSI实现条件性数据索引的策略

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，其分区键是一个“辅助性”属性，这个属性只在基表中的项目满足特定条件时才存在。

实现步骤：

1. 定义一个GSI辅助属性： 在你的基表设计中，引入一个新的属性，我们称之为“GSI辅助属性”或“GSI标志属性”。这个属性本身可以是一个简单的字符串（例如'ACTIVE'、'INTERMEDIATE'）或者任何你认为合适的值。
2. 创建GSI： 使用这个“GSI辅助属性”作为GSI的分区键。你可以选择性地添加一个排序键，以及定义投影属性（ALL、KEYS_ONLY或INCLUDE）。
3. 动态管理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的记录。

解决方案：

1. 定义GSI辅助属性： 我们引入一个名为GSI1PK的属性。
2. 创建GSI： 创建一个名为IntermediateAttachmentsGSI的GSI，其分区键为GSI1PK。
   • GSI名称: IntermediateAttachmentsGSI
   • GSI分区键: GSI1PK (String)
   • 投影属性: ALL (或根据需求选择KEYS_ONLY/INCLUDE)
3. 管理GSI辅助属性：
   • 当Attachment项目的isIntermediateState为1时（即customerState为Attaching或Detaching），我们设置GSI1PK属性，例如GSI1PK = 'INTERMEDIATE'。
   • 当Attachment项目的isIntermediateState为0时（即customerState为Attached或Detached），我们移除GSI1PK属性。

示例代码（概念性DynamoDB更新操作）：

纳米搜索

纳米搜索：360推出的新一代AI搜索引擎

30

查看详情

假设我们有一个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的附件记录。

注意事项与最佳实践

1. 原子性操作： 在更新基表项目时，确保customerState、isIntermediateState以及GSI辅助属性的更新是原子性的。使用UpdateItem操作可以确保这些更改同时发生，避免数据不一致。
2. GSI的最终一致性： DynamoDB GSI是最终一致的。这意味着从基表更新到GSI反映这些更改之间可能存在短暂的延迟。对于需要强一致性的场景，可能需要额外的逻辑来处理。
3. 成本考量： 稀疏GSI可以有效降低成本，特别是当只有一小部分基表项目需要被索引时。因为只有包含GSI分区键的项目才会占用GSI的存储和吞吐量。
4. 属性命名： 为GSI辅助属性选择一个清晰的名称（例如_gsi1_pk或status_index_key），以明确其用途。
5. 多个稀疏GSI： 如果需要多个不同条件的稀疏GSI，可以为每个GSI定义一个独立的辅助属性。

总结

尽管DynamoDB GSI不提供直接的条件性投影功能，但通过巧妙地利用其稀疏索引特性，我们可以实现高度灵活的条件性数据索引。核心在于根据业务逻辑动态地添加或移除GSI分区键属性。这种模式不仅能满足复杂的查询需求，还能在存储和吞吐量方面带来成本效益，是DynamoDB高级应用中一个非常实用的设计模式。

以上就是DynamoDB中利用稀疏GSI实现条件性数据索引的策略的详细内容，更多请关注php中文网其它相关文章！