时延降低 50%，小红书图数据库如何实现多跳查询性能大幅提升

多跳查询为企业提供了深入的数据洞察和分析能力，它在小红书众多在线业务中扮演重要的角色。然而，这类查询往往很难满足稳定的 P99 时延要求。小红书基础架构存储团队针对这一挑战，基于大规模并行处理（MPP）的理念，开发了一种图数据库上的分布式并行查询框架，成功将多跳查询的时延降低了 50% 以上，尤其是使 3 跳查询在在线场景从不能用到落地，极大地增强了在线业务的数据处理能力。

本文核心贡献在于：团队提出了一种从框架层面优化多跳查询时延的方案，在业务上使在线场景中使用多跳查询成为可能，在技术上实现了图数据库查询的框架级优化。全文将从以下几个方面依次展开：

• 介绍小红书使用图数据库的背景，并分析多跳查询在实际业务中因时延高而受限的现状（需求是什么）

• 深入探讨 REDgraph 架构，揭示原有查询模式的不足和可优化点（存在的问题）

• 详细阐述优化原查询模式的方案，并提供部分实现细节（改进方案）

• 通过一系列性能测试，验证优化措施的有效性（改进后效果）

本方案为具有复杂查询需求的在线存储产品提供了优化思路，欢迎业界同行深入探讨。

同时，作者再兴曾在「DataFunCon 2024·上海站」分享过本议题，感兴趣的同学欢迎点击“阅读原文”，回看完整录播视频。

1.1 图数据库在小红书的使用场景

小红书是一个以社区属性为主的产品，覆盖多个领域，鼓励用户通过图文、短视频、直播等形式记录和分享生活点滴。在社交领域中，我们存在多种实体，如用户、笔记、商品等，它们之间构成了复杂的关系网络。为高效处理这些实体间的一跳查询，小红书自研了图存储系统 REDtao，满足极致性能的需求。

（参见：小红书如何应对万亿级社交网络关系挑战？图存储系统 REDtao 来了！）

面对更为复杂的多跳查询场景，我们自研了图数据库系统 REDgraph，将多跳查询的需求应用于小红书多个业务领域，包括但不限于：

• 社区推荐：利用用户间的关系链和分享链，为用户推荐可能感兴趣的好友、笔记和视频。这类推荐机制通常涉及多于一跳的复杂关系。

• 风控场景：通过分析用户和设备的行为模式，识别可能的欺诈行为（如恶意薅羊毛），从而保护平台免受滥用和作弊行为的影响。

• 电商场景：构建商品与商品、商品与品牌之间的关联模型，优化商品分类和推荐，从而提升用户的购物体验。

在传统的 SQL 产品（如 MySQL）中，想实现这些多跳查询，通常需要在一个查询语句中写多个 JOIN，这样的性能无疑是较差的。若想利用键值存储 KV 产品实现，则需要分多次发送 get 请求，并自行处理中间结果，实现过程也较为麻烦。

相比之下，图数据库的设计理念为处理这类查询提供了天然优势。在图数据库中，数据表被抽象为顶点，表之间的关系被抽象为边，并且边作为一等公民被存储和处理。这样一来，执行 n 度关系查询只需查询 n 次边表，大大简化查询过程，并提高了效率。

1.2 业务上面临的困境

小红书在社交、风控及离线任务调度等场景中均采用了图数据库，然而在实际应用过程中遇到了一些挑战。

场景一：社交推荐

在社交推荐中，我们希望能够及时地将用户可能感兴趣的好友或内容推荐给他们。例如，如果用户 A 关注了用户 B，而用户 B 点赞了笔记 C，那么用户 D（也点赞了笔记 C）就可能成为用户 A 的潜在好友，使小红书的好友社区建立更丰富的连接。

业务当然可以使用离线任务分析，基于分析结果进行推荐，但社交图谱是无时无刻不在变化，基于离线分析做出的推荐往往是滞后的。如果推荐得更及时，能更好地抓住一些潜在的用户关系，建立更丰富完善的社交图谱，赋能其他业务（如：社区兴趣小组，电商商品推荐）。

业务希望能即时向用户推送可能感兴趣的 “好友” 或 “内容”，如果能即时完成此推荐，则能有效优化用户使用体验，提升留存率。然而，由于先前 REDgraph 在某些方面的能力尚未完善，导致三跳时延比较高，所以业务一直只采用了一跳和两跳查询。

场景二：社区生态与风险控制

小红书致力于促进社区生态的健康发展，对优质内容创作者提供奖励。然而，这也吸引了一些作弊用户想薅羊毛。例如，作弊用户可能会通过组织点赞来提升低质量笔记的排名，将低质笔记伪造成优质笔记以赚取奖励。

风控业务需要对这种行为予以识别并防范，借助图数据库的多跳查询，我们构建出一个包含用户和笔记为顶点、点赞为边的复杂关系图（“用户->笔记-> ... ->用户->笔记“）。随后，对每篇笔记查询其多度关系（笔记 -> 用户 -> 笔记 -> 用户）上作弊用户的比例，若比例高于一定阈值，把笔记打上作弊标签，系统便不对作弊用户和作弊笔记发放奖励。

打标行为往往是实时消费消息队列去查询图数据库，如果查询动作本身比较慢，则会造成整体消费积压。例如，如果一个查询任务本应在 12:00 执行，但由于性能问题直到 12:10 才开始触发，那么在这十分钟的延迟期间，一篇劣质笔记已成为优质笔记，作者薅羊毛成功。等到发现这是作弊用户时，显然「为时晚矣」，因为损失已经造成了。

具体来说，社交推荐场景要求三跳的 P99 低于 50 毫秒，风控场景则要求三跳的 P99 低于 200 毫秒，这是目前 REDgraph 所面临的一大难题。那为何一至二跳可行，三跳及以上就难以实现呢？对此，我们基于图数据库与其他类型系统在工作负载的差异，做了一些难点与可行性分析。

1.3 难点与可行性分析

首先在并发方面，OLTP 的并发度很高，而 OLAP 则相对较低。图的三跳查询，服务的仍然是在线场景，其并发度也相对较高，这块更贴近 OLTP 场景。

其次在计算复杂度方面，OLTP 场景中的查询语句较为简单，包含一到两个 join 操作就算是较为复杂的情况了，因此，OLTP 的计算复杂度相对较低。OLAP 则是专门为计算设计的，因此其计算复杂度自然较高。图的三跳查询则介于 OLTP 和 OLAP 之间，它虽不像 OLAP 那样需要执行大量的计算，但其访问的数据量相对于 OLTP 来说还是更可观的，因此属于中等复杂度。

第三，数据时效性方面，OLTP 对时效性的要求较高，必须基于最新的数据提供准确且实时的响应。而在 OLAP 场景中则没有这么高的时效要求，早期的 OLAP 数据库通常提供的是 T+1 的时效。图的三跳查询，由于我们服务的是在线场景，所以对时效性有一定的要求，但并不是非常高。使用一小时或 10 分钟前的状态进行推荐，也不会产生过于严重的后果。因此，我们将其定义为中等时效性。

最后，查询失败代价方面。OLTP