以性能为首要考量的DynamoDB推荐系统最优设计方案咨询

嘿，针对DynamoDB做高性能多维度推荐排行榜这个需求，我刚好有不少实战经验——直接用原始时间字段做范围查询绝对是性能大坑，核心要靠预聚合+精准的主键设计来搞定，下面给你拆解最优方案：

首先得明确DynamoDB的性能核心——它是基于主键/索引的键值存储，范围扫描（比如按时间戳查某一周的数据）在数据量大的时候会消耗大量RCU（读取容量单位），而且延迟会很高。所以我们要提前把各维度的点赞数聚合好，而不是查的时候再计算，这样查询Top10就是毫秒级的单点操作。

我们用DynamoDB的**复合主键（分区键PK + 排序键SK）**来实现快速查询：

分区键（PK）：按时间维度拆分 #

把每个时间维度单独作为一个分区，格式为：
rank:<维度标识>
比如：

• 日榜：rank:2024-09-15
• 周榜：rank:2024-week37（用周数标识）
• 月榜：rank:2024-09
• 年榜：rank:2024

这样每个维度的数据都存在独立分区里，查询时直接定位到目标分区，完全避免跨分区扫描。

排序键（SK）：实现自动排序 #

为了让Top10能直接从分区头部读取，我们把排序键设计为固定长度的点赞补数 + 话题ID，比如：
%010d#<topic_id>（其中补数 = 1000000000 - likes）
举个例子：

• 某话题点赞123次 → 补数是999999877 → SK为999999877#topic_abc123
• 某话题点赞45次 → 补数是999999955 → SK为999999955#topic_def456

这样字符串排序时，补数越大（对应点赞数越高）的条目会排在分区的最前面，查询Top10直接取前10条即可，无需额外排序。

完整条目属性 #

每个条目包含：

• PK：上面的维度标识
• SK：点赞补数+话题ID
• url：目标URL
• topic_name：话题名称
• likes：实际点赞数（正数值，方便展示）
• ttl：可选，设置过期时间让DynamoDB自动清理旧数据

点赞操作必须是原子的，避免并发冲突，我们用DynamoDB的UpdateItem API配合ADD操作符来实现，同时批量更新四个维度的数据：

import boto3
from datetime import datetime

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('RecommendationRanks')

def update_likes(topic_id, url, topic_name):
    now = datetime.now()
    # 生成各维度的分区键
    dims = {
        "daily": now.strftime("%Y-%m-%d"),
        "weekly": now.strftime("%Y-week%W"),
        "monthly": now.strftime("%Y-%m"),
        "yearly": now.strftime("%Y")
    }
    
    # 批量写入四个维度的更新
    with table.batch_writer() as batch:
        for dim_key, dim_val in dims.items():
            pk = f"rank:{dim_val}"
            # 初始补数是1000000000（对应likes=0）
            sk = f"1000000000#{topic_id}"
            
            batch.update_item(
                Key={"PK": pk, "SK": sk},
                UpdateExpression="ADD likes :inc SET url = :url, topic_name = :topic_name",
                ExpressionAttributeValues={
                    ":inc": 1,
                    ":url": url,
                    ":topic_name": topic_name
                },
                # 不存在则自动创建条目
                ConditionExpression="attribute_exists(PK) OR attribute_exists(SK)"
            )

这里ADD :inc是原子操作，即使多个请求同时更新，也不会出现计数错误；批量写入则保证了四个维度的更新高效完成。

查询某个维度的Top10超级简单——直接定位到目标分区，取前10条即可：

def get_top10(dimension_value):
    pk = f"rank:{dimension_value}"
    response = table.query(
        KeyConditionExpression="PK = :pk",
        ExpressionAttributeValues={":pk": pk},
        Limit=10
    )
    
    # 转换结果，还原真实点赞数
    top_list = []
    for item in response["Items"]:
        complement = int(item["SK"].split("#")[0])
        real_likes = 1000000000 - complement
        top_list.append({
            "topic_id": item["SK"].split("#")[1],
            "topic_name": item["topic_name"],
            "url": item["url"],
            "likes": real_likes
        })
    return top_list

# 示例：查询2024年第37周的Top10
weekly_top10 = get_top10("2024-week37")

这个查询只消耗极少的RCU，延迟通常在10ms以内，完全满足高性能要求。

• TTL自动清理：给每个条目设置ttl属性（比如日榜保留30天，周榜保留3个月），DynamoDB会自动删除过期数据，节省存储成本。
• 热点分区拆分：如果某个维度（比如当日热门话题）的更新量极大，可以在PK里加上话题分类，比如rank:2024-09-15:tech，把热点分散到多个分区，避免吞吐量瓶颈。
• 缓存结果：如果Top10查询频率极高，把结果缓存到Redis（ElastiCache），设置5-10分钟的过期时间，进一步降低DynamoDB的压力。
• 事务保证一致性：如果要求四个维度的点赞数必须严格一致，可以用DynamoDB的TransactWriteItems API，确保四个更新要么全成功，要么全失败。

内容的提问来源于stack exchange，提问作者andolffer.joseph