Elasticsearch技术问询：社交网络如何按好友点赞量排序搜索帖子？

方案1：Redis缓存好友点赞集合 + Elasticsearch评分加权 #

这是针对大用户量、好友数多场景的最优轻量化方案，核心是将关系计算和文本搜索分离：

• 数据存储设计：

  • Elasticsearch帖子索引仅存储基础字段：post_id（keyword）、content（text）、like_count（integer）等，不存储点赞用户ID数组，避免文档过大。
  • Redis维护两个核心缓存：
    • user:{uid}:friends：存储用户的直接好友ID列表，好友关系变更时同步更新。
    • friend_likes:{uid}：存储用户所有好友点赞过的帖子ID集合。当用户点赞/取消点赞帖子时，异步更新该用户所有好友的friend_likes集合；好友关系变更时，重新计算该用户的friend_likes集合（可通过异步任务批量处理）。

• 搜索查询实现：
  先从Redis获取当前用户的friend_likes集合，再通过ES的function_score给这些帖子加权，提升排序优先级：

  {
    "query": {
      "match": {
        "content": "你的搜索关键词"
      }
    },
    "function_score": {
      "functions": [
        {
          "filter": {
            "terms": {
              "post_id": ["p_123", "p_456", "..."] // 从Redis获取的好友点赞帖子ID列表
            }
          },
          "weight": 10 // 自定义加权值，根据业务需求调整
        }
      ],
      "boost_mode": "sum" // 将加权值加到原始文本搜索评分上
    }
  }
  

• 优势：

  • 避免每次请求传递数千个好友ID，仅传递好友点赞的帖子ID（数量远小于好友数），降低查询开销。
  • 数据一致性维护成本低：点赞/好友关系变更仅需更新Redis缓存，无需修改ES的帖子文档。
  • 无重复数据存储，帖子编辑仅需更新ES单条文档。

方案2：Elasticsearch Parent-Child 文档模型 #

适合希望所有逻辑在ES内实现、好友数中等的场景：

• 索引映射设计：
  建立post（父文档）和like（子文档）的关联关系，子文档存储点赞用户ID：

  {
    "mappings": {
      "properties": {
        "content": { "type": "text" },
        "like_user_id": { "type": "keyword" },
        "join_field": {
          "type": "join",
          "relations": {
            "post": "like"
          }
        }
      }
    }
  }
  

• 搜索查询实现：
  通过has_child查询匹配好友点赞的帖子，并通过bool查询的should子句提升权重：

  {
    "query": {
      "bool": {
        "must": [
          { "match": { "content": "你的搜索关键词" } }
        ],
        "should": [
          {
            "has_child": {
              "type": "like",
              "query": {
                "terms": { "like_user_id": ["friend_1", "friend_2", "..."] } // 当前用户的好友ID列表
              },
              "boost": 5 // 提升好友点赞帖子的权重
            }
          }
        ]
      }
    }
  }
  

• 注意事项：

  • 好友数超过1000时，terms查询的性能会下降，建议结合缓存好友ID、分片优化或提前过滤高频好友点赞的帖子。
  • 子文档的写入会带来一定的性能开销，适合点赞频率中等的场景。

方案3：图数据库（Neo4j）+ Elasticsearch 协同方案 #

适合社交关系复杂、未来可能扩展关系型推荐的场景，将关系计算交给图数据库，文本搜索交给ES：

• 数据分工：

  • Neo4j存储节点：User(id)、Post(id)；关系：User-[:FRIEND_OF]->User（好友关系）、User-[:LIKED]->Post（点赞关系）。
  • Elasticsearch仅存储帖子的文本内容和基础属性，专注文本搜索。

• 搜索流程：

  1. 用Cypher查询快速获取当前用户好友点赞的帖子ID：

     MATCH (u:User {id: $current_user_id})-[:FRIEND_OF]->(f:User)-[:LIKED]->(p:Post)
     RETURN DISTINCT p.id
     

  2. 将查询得到的帖子ID传入ES，用function_score加权后执行文本搜索（同方案1的ES查询逻辑）。

• 优势：

  • 图数据库处理关系查询的效率远高于ES，尤其是复杂层级的关系（如后续扩展好友的好友点赞）。
  • 职责分离，ES专注文本搜索，避免因关系查询拖慢搜索性能。
  • 数据一致性维护简单：好友关系、点赞行为的变更仅需更新Neo4j，帖子文本更新仅需修改ES。

方案选择建议 #

• 若好友数多、但好友共同点赞的帖子数少：优先选方案1，兼顾性能和维护成本。
• 若希望所有逻辑在ES内完成、好友数中等：选方案2，需注意性能调优。
• 若社交关系复杂、有未来扩展需求：选方案3，扩展性更强。

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