李凝瑞-再兴-小红书图数据库在分布式并行查询上的探索-可公开版.pdf

《李凝瑞-再兴-小红书图数据库在分布式并行查询上的探索-可公开版.pdf》由会员分享，可在线阅读，更多相关《李凝瑞-再兴-小红书图数据库在分布式并行查询上的探索-可公开版.pdf（28页珍藏版）》请在三个皮匠报告上搜索。

1、DataFunConDataFunCon#20242024小红书图数据库在小红书图数据库在分布式并行查询上的探索分布式并行查询上的探索李凝瑞（再兴）小红书分布式数据库架构师ContentsContents目录目录背景介绍原架构问题分析分布式并行查询实现总结与展望01 01 背景介绍背景介绍图数据库是什么及其适用场景图数据库是什么及其适用场景适用需要挖掘深链路、多维度关系的场景图数据库属于 NoSQL 存储，具有最高的数据关联度查询复杂度BigBig TableTableDocumentDocumentGraphGraph查询复杂度数据关联度图数据库图数据库 vs vs 关系型数据库关系型数据库

2、用户表好友关系表UserIdUserIdNameNameAgeAgePhonePhone001Tom25135*1234002Jerry30135*4567IdIdFromIdFromIdToIdToIdSinceSince10010022024-01-01.用户笔记点赞点赞行为表IdIdUserIdUserIdNoteIdNoteIdDateTimeDateTime10020012024-03-01.JOINJOINFILTER好友笔记详情表NoteIdNoteIdContentContent001xxxxxxxx.JOINTom图建模图存储关系型数据库关系型数据库图数据库图数据库g.V()

3、.has(name,Tom).out(好友).out(点赞).property(Content)图查询好友好友点赞点赞点赞点赞点赞图数据库在小红书的使用场景图数据库在小红书的使用场景社交实时推荐社区风控任务调度小红书是一个年轻的生活方式分享平台，在小红书，用户可以通过短视频、图文等形式记录生活的点滴。业务上面临的困境业务上面临的困境业务场景业务场景图模型图模型业务诉求业务诉求社交实时推荐即时地将用户可能感兴趣的好友或内容推荐给他们社区风控快速识别风险用户/笔记避免造成损失3跳及以上的查询时延无法满足业务要求图上图上3 3跳查询与其他系统负载有什么不同跳查询与其他系统负载有什么不同要求要求OLT

4、POLTPOLAPOLAP图图3 3跳查询跳查询并发度高低高计算复杂度低高中数据实效性高低中查询失败代价低高中目标时延吞吐时延如何在高并发、计算复杂度较高的场景下保证时延？02 02 原架构问题分析原架构问题分析RedGraphRedGraph整体架构整体架构 存储与计算分离，shared-nothing 架构 meta-server：元信息的管理 query-server：处理用户查询请求 store-server：存储数据RedGraphRedGraph图切分方式图切分方式 边切分，以顶点为中心 顶点：根据 ID 做 hash 然后路由到某分片 边：磁盘上会存储两份，一条跟起点存在一个分片

5、，另一条跟终点存在一个分片以前做过的一些优化以前做过的一些优化提供定制化算法新查询模式无法支持对顶点扇出做裁剪完善算子下推允许读 follower加快垃圾回收频率需要完整结果不适用可能未使用这些算子需要强一致读不适用优化方案 1.0仍可能命中垃圾数据优化方案使用限制通用性差，且在3跳场景中效果还不够耗时分析及新方案思考耗时分析及新方案思考分布式并行查询多跳查询执行框架数据量大，计算耗时框架层面改造方案 2.0执行引擎优化存储层优化查询计划优化产出记录数产出记录数存储层耗时存储层耗时(us)(us)查询层耗时查询层耗时(us)(us)1跳算子66744382跳算子167297,61919,204

6、3跳算子451133133,667754,043聚合算子-7,891从第2跳开始，查询层耗时占比越来越明显3跳中查询层耗时占比超过 80%挑选一个耗时接近 1s 的3跳查询（无明显超级点）做 profile原多跳查询执行流程原多跳查询执行流程查询顶点 933 的三跳邻居点 Id执行计划可优化点分析可优化点分析算子串行执行效率低算子并行执行同步等待导致时延增加查询结果转发浪费IO取消同步点直接转发到目标节点存在的问题解决思路改造后的执行流程改造后的执行流程03 03 分布式并行查询实现分布式并行查询实现如何保证不对如