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

DataFunCon#2024小红书图数据库在分布式并行查询上的探索李凝瑞（再兴）小红书——分布式数据库架构师

Contents目录背景介绍原架构问题分析分布式并行查询实现总结与展望

01背景介绍

图数据库是什么及其适用场景适用需要挖掘深链路、多维度关系的场景图数据库属于NoSQL存储，具有最高的数据关联度查询复杂度DocumentBigTableGraph查询复杂度数据关联度

图数据库vs关系型数据库用户表好友关系表UserIdNameAgePhone001Tom25135****1234002Jerry30135****4567…………IdFromIdToIdSince10010022024-01-01............用户笔记点赞点赞行为表IdUserIdNoteIdDateTime10020012024-03-01.........JOINJOINFILTER好友笔记详情表NoteIdContent001xxxxxxxx......JOINTom图建模图存储关系型数据库图数据库g.V().has(name,Tom).out(好友).out(点赞).property(Content)图查询好友好友点赞点赞点赞点赞点赞

图数据库在小红书的使用场景社交实时推荐社区风控任务调度小红书是一个年轻的生活方式分享平台，在小红书，用户可以通过短视频、图文等形式记录生活的点滴。

业务上面临的困境业务场景图模型业务诉求社交实时推荐即时地将用户可能感兴趣的好友或内容推荐给他们社区风控快速识别风险用户/笔记避免造成损失3跳及以上的查询时延无法满足业务要求

图上3跳查询与其他系统负载有什么不同要求OLTPOLAP图3跳查询并发度高低高计算复杂度低高中数据实效性高低中查询失败代价低高中目标时延吞吐时延如何在高并发、计算复杂度较高的场景下保证时延？

02原架构问题分析

RedGraph整体架构存储与计算分离，shared-nothing架构meta-server：元信息的管理query-server：处理用户查询请求store-server：存储数据

RedGraph图切分方式边切分，以顶点为中心顶点：根据ID做hash然后路由到某分片边：磁盘上会存储两份，一条跟起点存在一个分片，另一条跟终点存在一个分片

以前做过的一些优化提供定制化算法新查询模式无法支持对顶点扇出做裁剪完善算子下推允许读follower加快垃圾回收频率需要完整结果不适用可能未使用这些算子需要强一致读不适用优化方案1.0仍可能命中垃圾数据优化方案使用限制通用性差，且在3跳场景中效果还不够

耗时分析及新方案思考分布式并行查询多跳查询执行框架数据量大，计算耗时框架层面改造方案2.0执行引擎优化存储层优化查询计划优化产出记录数存储层耗时(us)查询层耗时(us)1跳算算子167297,61919,2043跳算子451133133,667754,043聚合算子-7,891从第2跳开始，查询层耗时占比越来越明显3跳中查询层耗时占比超过80%挑选一个耗时接近1s的3跳查询（无明显超级点）做profile

原多跳查询执行流程查询顶点933的三跳邻居点Id执行计划

可优化点分析算子串行执行效率低算子并行执行同步等待导致时延增加查询结果转发浪费IO取消同步点直接转发到目标节点存在的问题解决思路

改造后的执行流程

03分布式并行查询实现

如何保证不对1-2跳产生负优化生成计划后，根据跳数走不同的处理分支。1-2跳走原来的串行查询；3跳及以上走分布式并行查询；可安全回滚

如何与原有执行框架兼容添加特殊的算子，无缝接入原框架ForwardConvergeMerge算子下推进一步优化GroupByOrderBy

如何做热点处理——NeighborCachemapvid+edgeType,ListEdge条目存活时间短填充前内存检查

如何做负载均衡扩大集群规模及时清理过期数据存储均衡转发给负载较低的从节点热点结果缓存计算均衡

如何做流程控制Ack机制驱动末端stage全链路超时自检无需故障恢复机制

性能测试——3跳及以下01002003004005006001跳2跳3跳3跳+Limit(1w)3跳+MaxDegree(100)3跳+MaxDegree(1000)3跳+GroupBy原生查询(ms) 分布式查询(ms)

性能测试——4跳201816141210864204跳4跳+GroupBy4跳+Limit(10w)4跳+MaxDegree(100)4跳+MaxDegree(1000)原生查询(s) 分布式查询(s