基于DynamoDB实现社交APP关注者帖子查询及分页需求问询

如果暂时不想调整表结构，可以按以下步骤实现，但要注意当关注者数量较多时，性能会明显下降：

1. 获取关注者ID列表
   假设你的粉丝表结构为：

• 分区键（PK）：USER#{userId}（存储当前用户ID）
• 排序键（SK）：FOLLOWER#{followerId}（存储关注者ID）
  通过Query操作快速获取当前用户的所有关注者ID：

import { DynamoDBClient, QueryCommand } from "@aws-sdk/client-dynamodb";
import { unmarshall } from "@aws-sdk/util-dynamodb";

const client = new DynamoDBClient({ region: "你的区域" });

async function getFollowers(userId) {
  const command = new QueryCommand({
    TableName: "粉丝表名称",
    KeyConditionExpression: "PK = :pk",
    ExpressionAttributeValues: {
      ":pk": { S: `USER#${userId}` }
    },
    ProjectionExpression: "SK"
  });
  const response = await client.send(command);
  // 提取纯关注者ID
  return response.Items.map(item => unmarshall(item).SK.replace("FOLLOWER#", ""));
}

2. 批量获取帖子并合并排序
   帖子表假设结构：

• 分区键（PK）：AUTHOR#{followerId}
• 排序键（SK）：POST_DATE#{isoDate}（例如POST_DATE#2024-05-20T12:30:00Z，确保可按时间排序）
  由于DynamoDB不支持跨分区的多键查询，需对每个关注者单独发起Query，并行执行后合并结果再按日期排序：

async function getFollowersPosts(followerIds, pageCount, exclusiveStartKeys = {}) {
  // 并行查询每个关注者的帖子
  const postPromises = followerIds.map(async (followerId) => {
    const command = new QueryCommand({
      TableName: "帖子表名称",
      KeyConditionExpression: "PK = :pk",
      ExpressionAttributeValues: {
        ":pk": { S: `AUTHOR#${followerId}` }
      },
      ScanIndexForward: false, // 按日期降序排列
      Limit: pageCount,
      ExclusiveStartKey: exclusiveStartKeys[followerId]
    });
    const response = await client.send(command);
    return {
      followerId,
      posts: response.Items.map(unmarshall),
      lastEvaluatedKey: response.LastEvaluatedKey
    };
  });

  const results = await Promise.all(postPromises);
  
  // 合并所有帖子并按发布日期排序
  const allPosts = results.flatMap(res => res.posts);
  allPosts.sort((a, b) => new Date(b.SK.replace("POST_DATE#", "")) - new Date(a.SK.replace("POST_DATE#", "")));
  
  // 截取分页数据
  const paginatedPosts = allPosts.slice(0, pageCount);
  
  // 收集每个关注者的查询位置，用于下一页请求
  const newExclusiveStartKeys = results.reduce((acc, res) => {
    if (res.lastEvaluatedKey) {
      acc[res.followerId] = res.lastEvaluatedKey;
    }
    return acc;
  }, {});

  return {
    posts: paginatedPosts,
    lastEvaluatedKey: newExclusiveStartKeys
  };
}

这种方案的局限性：

• 关注者越多，并行请求数越多，容易触发DynamoDB并发限制
• 合并排序的开销随帖子数量增长而急剧变大
• 分页逻辑复杂，需要维护每个关注者的查询位置

DynamoDB是面向查询设计的数据库，社交APP的时间线场景最适合用反范式的时间线表，直接将关注者的帖子预计算到当前用户的时间线中，读取时只需一次查询：

时间线表结构 #

写入逻辑 #

• 用户发布帖子时，查询该用户的所有粉丝，将帖子复制到每个粉丝的时间线表中（可通过DynamoDB Streams + Lambda异步处理，避免阻塞发布请求）
• 用户关注/取消关注他人时，同步该作者的历史帖子到/从用户的时间线表中（或仅同步新帖子，历史帖子按需加载）

高效查询与分页实现 #

只需一次Query就能获取排序好的分页结果：

async function getUserTimeline(userId, pageCount, exclusiveStartKey = undefined) {
  const command = new QueryCommand({
    TableName: "时间线表名称",
    KeyConditionExpression: "PK = :pk",
    ExpressionAttributeValues: {
      ":pk": { S: `TIMELINE#${userId}` }
    },
    ScanIndexForward: false, // 按发布时间降序
    Limit: pageCount,
    ExclusiveStartKey: exclusiveStartKey
  });

  const response = await client.send(command);
  return {
    posts: response.Items.map(unmarshall),
    lastEvaluatedKey: response.LastEvaluatedKey // 下一页查询时作为ExclusiveStartKey传入
  };
}

这种方案的优势：

• 读取性能极高，一次Query完成排序和分页，完全符合DynamoDB最佳实践
• 分页逻辑简单，直接复用DynamoDB原生的LastEvaluatedKey和ExclusiveStartKey
• 适配社交APP读多写少的场景，写入时的额外开销可通过异步处理抵消

如果你的APP用户关注者数量较少，现有表结构的方案可临时使用；但从长期扩展性和性能考虑，强烈建议采用时间线表的反范式设计，这是DynamoDB处理社交时间线场景的标准方案。

内容的提问来源于stack exchange，提问作者Ushan Fernando