在Django电商中构建User-Based Collaborative Filtering的性能优化咨询

你的方案可行性分析 #

这个方案完全可行，是解决当前性能问题的合理方向，具体分析如下：

当前实现的性能瓶颈 #

• 全量用户遍历：find_similar_users 会遍历当前用户外的所有用户，用户规模扩大后，这一步会成为核心性能瓶颈
• 重复数据库查询：计算杰卡德相似度时，每对用户都要两次查询购买记录，IO开销极大
• 实时计算阻塞：每次调用推荐接口都要重新计算相似度和推荐结果，无法应对高并发场景

你的方案的核心优势 #

• 异步解耦：用Celery把相似度计算、推荐结果生成放到后台执行，不会阻塞用户的实时请求
• NoSQL适配性：NoSQL（如MongoDB、Redis）更适合存储非结构化的用户相似度数据、推荐结果，读写性能远高于关系型数据库，尤其适配高频读取推荐结果的场景
• 预计算缓存：提前生成并存储推荐结果，用户请求时直接读取，响应速度能得到数量级的提升

具体落地建议 #

数据同步与存储设计 #

• 购买数据实时同步：在用户完成购买后，通过Django信号触发Celery任务，将用户-商品的购买关系同步到NoSQL中，比如用Redis集合存储每个用户的购买商品ID列表，方便快速计算交集/并集
• 相似度与推荐结果存储：
  • 用哈希表存储用户的Top K相似用户及相似度值，例如Redis的HSET user:{user_id} similar_users '[{"user_id":123, "similarity":0.8}, ...]'
  • 用有序集合存储用户的推荐商品，还能按相似度排序，方便返回优先级更高的推荐内容

优化后的计算流程 #

1. 用户完成购买，Django信号触发Celery异步任务
2. Celery任务从NoSQL读取当前用户及关联用户的购买集合，重新计算相似度并更新Top K相似用户数据
3. 根据更新后的相似用户，汇总他们的购买商品（排除当前用户已购买的），生成推荐列表并存储到NoSQL
4. 前端请求推荐时，直接从NoSQL读取预计算好的结果返回

额外优化点 #

• 增量计算：无需每次全量重新计算所有用户的相似度，只计算当前用户与有购买交集的用户的相似度变化，大幅减少计算量
• 过期更新策略：定期清理或更新过期的推荐结果，保证推荐时效性，比如每周用Celery执行一次全量更新任务
• 算法升级：如果用户量极大，可以考虑用矩阵分解、Faiss向量检索等更高效的方式，替代杰卡德相似度的全量遍历

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