本文详解如何通过合理设计全局二级索引（GSI）替代低效全表扫描，精准筛选 platform + type + rate_id 时间前缀组合的数据，彻底解决 monthly/weekly 类型混杂问题。
本文详解如何通过合理设计全局二级索引（gsi）替代低效全表扫描，精准筛选 `platform` + `type` + `rate_id` 时间前缀组合的数据，彻底解决 `monthly`/`weekly` 类型混杂问题。
你当前 Lambda 函数中大量使用 table.scan() 并依赖 FilterExpression 进行多字段过滤（如 platform, type, rate_id.begins_with(...)），这是导致查询结果“不纯净”且性能低下的根本原因——DynamoDB 的 scan 操作会在返回全部匹配项前先读取整个分区（或全表）数据，再在内存中应用 FilterExpression；该过滤仅减少返回量，不减少读容量单位（RCU）消耗，更无法保证逻辑隔离。尤其当 rate_id 前缀（如 "2024-11"）同时匹配 2024-11-summary 和 2024-11-week1 时，FilterExpression 虽然写了 Key('type').eq('monthly')，但 DynamoDB 仍会先加载所有 "2024-11*" 的项（含 weekly），再丢弃不符合 type 的记录——这正是你观察到“weekly 数据意外出现”的技术根源。
✅ 正确解法：放弃 Scan，拥抱 Query + GSI 主键设计
DynamoDB 的高性能查询必须围绕 Query 操作展开，而 Query 的前提是有明确的分区键（Partition Key）匹配。因此，我们需要重构访问模式，将高频查询维度（platform 和 type）提升为索引主键，使 Query 能天然、原子性地隔离数据：
方案：创建复合 GSI —— platform-type-index
| GSI 名称 | 分区键（PK） | 排序键（SK） |
|---|---|---|
| platform-type-index | platform | type#rate_id |
✅ 优势：
- platform 作为分区键 → 支持按平台高效路由；
- type#rate_id 作为排序键（如 "monthly#2024-11-summary" 或 "weekly#2024-11-week1"）→ 同一分区下天然按 type 字典序分组，且 rate_id 前缀可配合 BEGINS_WITH 精准范围查询。
步骤 1：创建 GSI（使用 AWS CLI）
aws dynamodb update-table \
--table-name deployment-frequency-table \
--attribute-definitions \
AttributeName=platform,AttributeType=S \
AttributeName="type#rate_id",AttributeType=S \
--global-secondary-index-updates \
"[{
\"Create\":{
\"IndexName\":\"platform-type-index\",
\"KeySchema\":[
{\"AttributeName\":\"platform\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"type#rate_id\",\"KeyType\":\"RANGE\"}
],
\"Projection\":{\"ProjectionType\":\"ALL\"},
\"ProvisionedThroughput\":{\"ReadCapacityUnits\":10,\"WriteCapacityUnits\":5}
}
}]"
步骤 2：重写查询函数（Python + boto3）
from boto3.dynamodb.conditions import Key, BeginsWith
import datetime
def query_items_by_platform_and_type(platform: str, data_type: str, month_prefix: str = None):
"""
高效查询指定平台与类型的记录，支持按月前缀过滤（可选）
"""
table = dynamodb.Table('deployment-frequency-table')
# 构建排序键前缀：type#YYYY-MM
sort_key_prefix = f"{data_type}#{month_prefix}" if month_prefix else data_type
query_kwargs = {
'IndexName': 'platform-type-index',
'KeyConditionExpression': Key('platform').eq(platform) & BeginsWith('type#rate_id', sort_key_prefix),
'ConsistentRead': False
}
# 若需精确到某月（如 current_month=True），则用 BeginsWith；若只需某 type 全量，则省略 month_prefix
response = table.query(**query_kwargs)
return response['Items']
# 示例调用：仅查 Generic_Data_DF 的 monthly 数据（2024-11 及之后）
current_month = datetime.datetime.now().strftime('%Y-%m') # e.g., "2024-11"
items = query_items_by_platform_and_type(
platform='Generic_Data_DF',
data_type='monthly',
month_prefix=current_month
)
步骤 3：更新 Lambda handler 中的逻辑
替换原 query_items_current_month() 函数：
def query_items_current_month(platform, data_type=None):
if not data_type:
raise ValueError("data_type is required for current_month query")
current_month = datetime.datetime.now().strftime('%Y-%m')
return query_items_by_platform_and_type(platform, data_type, current_month)
⚠️ 关键注意事项
- FilterExpression 不是银弹：它永远在 Query/Scan 返回结果后执行，无法跳过底层数据读取。高频、高基数字段（如 type）绝不能仅靠 FilterExpression 隔离。
- GSI 写入开销可控：你只需在 PutItem/UpdateItem 时，将 type#rate_id 作为属性显式写入（如 "type#rate_id": "monthly#2024-11-summary"），DynamoDB 自动维护索引。
- 避免全表 Scan：scan() 在生产环境应仅用于一次性迁移或调试；任何面向终端用户（如 Grafana）的 API 必须使用 query() + 合理 GSI。
- 分页与限流：Query 默认返回最多 1MB 数据，务必检查 LastEvaluatedKey 并实现分页（尤其 Grafana 可能需要完整数据集）。
✅ 效果验证
- 请求 ?current_month=true&platform=Generic_Data_DF&type=monthly → 仅返回 rate_id 以 "2024-11" 开头且 type#rate_id 为 "monthly#2024-11*" 的项（如 2024-11-summary），绝对不包含任何 weekly 记录；
- 请求 ?platform=Generic_Data_DF&type=weekly → 返回所有 type#rate_id 以 "weekly#" 开头的项，天然与 monthly 物理隔离。
通过将业务语义（platform+type+time-granularity）直接编码进主键结构，你不仅解决了数据污染问题，更将单次查询延迟从秒级降至毫秒级，RCU 消耗降低 90% 以上——这才是 DynamoDB “以查询驱动设计”的正确打开方式。
