

小红书图数据库在分布式并行查询上的探索

DataFunSummit

2025-11-05

导读小红书作为一个社区属性为主的产品，涵盖了各个领域的生活社区，并存储海量的社交网络关系。为了解决社交场景下的应用痛点以及分布式并行查询实现中的问题，我们自研了面向超大规模社交网络的图数据库系统 REDgraph，大大提高了系统的查询效率和性能。

本次分享的内容主要包括五个部分：

1. 背景介绍

2. 原架构问题分析

3. 分布式并行查询实现

4. 总结与展望

5. 问答环节

出品社区｜DataFun

背景介绍

1. 图数据库介绍

关于图数据库的概念，这里不作详细阐述。而是以图表的形式，对其与另外几种 NoSQL 产品进行比较。图数据库本身归属于 NoSQL 存储，而诸如KV 类型、宽表类型、文档类型、时序类型等其他 NoSQL 产品，各自具备独特的特性。从上图左侧的坐标轴中可以看到，从 KV 到宽表、文档，再到图，数据关联度和查询复杂度是越来越高的。前三者，即 KV、宽表和文档，主要关注的是单个记录内部的丰富性，但并未涉及记录间的关系。而图数据库则专注于处理这些关系。图数据库主要适用于需要挖掘深链路或多维度关系的业务场景。

接下来通过一个具体示例，再来对比一下图数据库与关系型数据库。这是社交网络中常见的一种表结构，包括四个数据表：用户表、好友关系表、点赞行为表以及笔记详情表。比如要查询 Tom 这个用户的好友所点赞的笔记的详细信息，那么可能需要编写一段冗长的 SQL 语句。在该 SQL 语句中，涉及到三个 join 操作，首先将用户表和好友关系表进行连接，从而获取 Tom 的所有好友信息。然后，将得到的中间结果与点赞行为表进行连接，以确定 Tom 的好友都点赞了哪些笔记。最后，还需要对先前生成的临时表和笔记详情表进行连接，以便最终获取这些笔记的全部内容。

关系型数据库中的 join 操作通常复杂度较高，其执行过程中需消耗大量的 CPU 资源、内存空间以及 IO，虽然我们可以通过精心的设计，例如针对所要关联的列创建索引，以降低扫描操作的比例，通过索引匹配来实现一定程度的性能提升。然而，这样的举措所产生的成本相对较高，因为所有新的场景都需要创建索引，要考虑如何撰写 SQL 中的 join 条件，选择哪个表作为驱动表等等，这些都需要耗费大量的精力和时间。

而如果采用图数据库，则会简单很多。首先进行图建模，创建两类顶点，分别为用户和笔记，同时创建两类边，一类是好友关系，即用户到用户的边；另一类是用户到笔记的点赞关系。当我们将这些数据存储到图数据库中时，它们在逻辑上呈现出一种网状结构，其关联关系已经非常明确。查询时，如上图中使用 Gremlin 语句，仅需四行代码即可获取到所需的信息。其中第一行 g.V().has('name', 'Tom')，用于定位 Tom 节点，两个 out 子句，第一个 out 子句用于查找 Tom 的好友，第二个 out 子句用于查找 Tom 的点赞笔记。当第二个 out 子句执行完毕后，就可以遍历所有外部的绿色顶点，即笔记节点。最后，读取它们的 content 属性。可以发现，与关系型数据库相比，图数据库的查询语句更加简洁、清晰易懂。

此外，图数据库还有一个更为显著的优势，就是在存储时，它已经将顶点及其关系作为一等公民进行设计和存储，因此在进行邻接边访问和关系提取时，效率极高。即使数据规模不断扩大，也不会导致查询时间显著增加。

文章节选自《AI for Data：智能数据处理与分析实战》电子书

识别下方二维码进群即可领取电子书