上篇我们讲述了一个执行计划是如何生成的,这次我们来看下这个生成的执行计划是被 Optimizer 优化的。

概述

Optimizer,优化器,顾名思义就是一个用来优化执行计划的组件。数据库的优化器通常分为两类,一类是基于规则的优化器 RBO(Rule-basd optimizer),一类是基于代价的优化 CBO(Cost-based optimizer),前者完全基于预设的优化规则进行优化,匹配的条件和优化的结果都比较固定;后者则会根据收集的数据统计信息计算不同执行计划的执行代价,尽量选择代价最小的执行计划。

目前 Nebula Graph 主要实现得是 RBO,所以本文也主要集中讲述 Nebula Graph 中的 RBO 实现。

源码定位

优化器的源码实现都在src/optimizer目录下面,其中的文件结构如下所示:

.
├── CMakeLists.txt
├── OptContext.cpp
├── OptContext.h
├── OptGroup.cpp
├── OptGroup.h
├── Optimizer.cpp
├── Optimizer.h
├── OptimizerUtils.cpp
├── OptimizerUtils.h
├── OptRule.cpp
├── OptRule.h
├── rule
│ ├── CombineFilterRule.cpp
│ ├── CombineFilterRule.h
│ ├── EdgeIndexFullScanRule.cpp
│ ├── EdgeIndexFullScanRule.h
| ....
|
└── test
├── CMakeLists.txt
├── IndexBoundValueTest.cpp
└── IndexScanRuleTest.cpp

其中test目录是测试,rule目录则是预设的规则集,其他的源文件则是优化器的具体实现。

而优化器优化查询的入口则在src/service/QueryInstance.cpp文件中,如下所示:

Status QueryInstance::validateAndOptimize() {
auto *rctx = qctx()->rctx();
VLOG(1) << "Parsing query: " << rctx->query();
auto result = GQLParser(qctx()).parse(rctx->query());
NG_RETURN_IF_ERROR(result);
sentence_ = std::move(result).value(); NG_RETURN_IF_ERROR(Validator::validate(sentence_.get(), qctx()));
NG_RETURN_IF_ERROR(findBestPlan()); return Status::OK();
}

findBestPlan函数会调用优化器,优化并返回一个全新的优化过的执行计划。

优化过程简述

Nebula Graph 目前设计的执行计划从拓扑角度来讲是一个有向无环图,通过每个节点指向它的依赖节点来组织,理论上每个节点可以指定任意节点的结果作为输入,但是使用一个还没执行的节点的结果是没有意义的,所以在生成执行计划的时候会限制只能使用已经执行过的节点作为输入。同时,执行计划也执行循环和条件分支这样的特殊节点。如图1 所示,该执行计划由查询语句GO 2 STEPS FROM 'Tim Duncan' OVER like产生。

图1

优化器目前的主要功能就是根据预设模式在执行计划中进行匹配,如果匹配成功,再调用相应的转换函数将匹配到的部分执行计划按预设的规则进行转换。比如,将 GetNeighborLimit 形式的执行计划转换成 limit 下推的GetNeighbor算子,实现算子下推优化。

具体实现

首先,优化器不会直接在执行计划上操作,而是先将执行执行计划转换成OptGroupOptGroupNodeOptGroup 代表的是一个单独的优化组(通常指一个或多个同等的算子),OptGroupNode 则是代表一个独立的算子,同时还有指向依赖以及分支的指针,也就是说OptGroupNode 保留了执行计划的拓扑结构。之所以要做这样的结构转换,主要是抽象出执行计划的拓扑结构,屏蔽掉一些不需要执行细节(比如循环和条件分支),以及在新的结构中方便保存一些规则匹配的上下文。

转换过程基本上是一个简单的先序遍历,并在遍历的过程中把算子转换成对应的OptGroup以及OptGroupNode。为了方便描述,这里把OptGroup以及OptGroupNode组成的结构称为优化计划,和执行计划做区分。

转换完成后就会开始匹配规则以及做相应的优化计划转换。这里会遍历所有预定义的规则,而每个规则都会在在优化计划上做一个 Bottom-Up 的遍历匹配,具体来说就是从最叶子层OptGroup开始,一直到根节点的OptGroup,在每个OptGroup节点上对节点内的OptGroupNode做 Top-Down 的遍历来进行规则模式的匹配。

如图2 所示,这里要匹配的模式是Limit->ProjectGetNeighbors,按照 Bottom-Up 的顺序,首先在Start节点按照 Top-Down 的顺序匹配,Start不等于Limit匹配失败,然后从GetNeighbors开始同样 Top-Down 匹配失败,直到Limit开始才匹配成功。匹配成功后,会根据规则定义的transform函数,将匹配到的部分优化计划进行转换,比如图2 会将LimitGetNeighbors合并。

图2

最后,优化器会把已经完成优化的优化计划重新转换成执行计划,这里和第一步相反,不过也是一个递归遍历转换的过程。

如何添加新规则

在前面的文章中,我们了解整个优化器组件的实现部分,不过对于添加优化规则来说并不需要了解太多优化器的实现细节,只需要了解如何定义新规则即可。这里,我们以Limit下推为例讲解一个典型的优化规则的实现。Limit下推规则的源码详见src/optimizer/rule/LimitPushDownRule.cpp文件:


std::unique_ptr<OptRule> LimitPushDownRule::kInstance =
std::unique_ptr<LimitPushDownRule>(new LimitPushDownRule()); LimitPushDownRule::LimitPushDownRule() {
RuleSet::QueryRules().addRule(this);
} const Pattern &LimitPushDownRule::pattern() const {
static Pattern pattern =
Pattern::create(graph::PlanNode::Kind::kLimit,
{Pattern::create(graph::PlanNode::Kind::kProject,
{Pattern::create(graph::PlanNode::Kind::kGetNeighbors)})});
return pattern;
}
StatusOr<OptRule::TransformResult> LimitPushDownRule::transform(
OptContext *octx,
const MatchedResult &matched) const {
auto limitGroupNode = matched.node;
auto projGroupNode = matched.dependencies.front().node;
auto gnGroupNode = matched.dependencies.front().dependencies.front().node; const auto limit = static_cast<const Limit *>(limitGroupNode->node());
const auto proj = static_cast<const Project *>(projGroupNode->node());
const auto gn = static_cast<const GetNeighbors *>(gnGroupNode->node()); int64_t limitRows = limit->offset() + limit->count();
if (gn->limit() >= 0 && limitRows >= gn->limit()) {
return TransformResult::noTransform();
} auto newLimit = static_cast<Limit *>(limit->clone());
auto newLimitGroupNode = OptGroupNode::create(octx, newLimit, limitGroupNode->group()); auto newProj = static_cast<Project *>(proj->clone());
auto newProjGroup = OptGroup::create(octx);
auto newProjGroupNode = newProjGroup->makeGroupNode(newProj); auto newGn = static_cast<GetNeighbors *>(gn->clone());
newGn->setLimit(limitRows);
auto newGnGroup = OptGroup::create(octx);
auto newGnGroupNode = newGnGroup->makeGroupNode(newGn); newLimitGroupNode->dependsOn(newProjGroup);
newProjGroupNode->dependsOn(newGnGroup);
for (auto dep : gnGroupNode->dependencies()) {
newGnGroupNode->dependsOn(dep);
} TransformResult result;
result.eraseAll = true;
result.newGroupNodes.emplace_back(newLimitGroupNode);
return result;
} std::string LimitPushDownRule::toString() const {
return "LimitPushDownRule";
}

定义一个规则首先先继承OptRule类。然后,实现pattern接口,这里要求返回需要匹配的模式,模式是算子和算子的依赖组成,比如Limit->Project->GetNeighbors。然后需要实现transform接口,transform接口会传入一个匹配的优化计划,我们根据预定义的模式来解析匹配到的优化计划,并对优化计划做相应的优化转换,比如把Limit算子合并到GetNeighbors算子,最后返回优化过的优化计划计划即可。

只需要正确实现这两个接口,我们的新的优化规则就可以正常工作了。

以上,为 Nebula Graph Optimizer 的介绍。

交流图数据库技术?加入 Nebula 交流群请先填写下你的 Nebula 名片,Nebula 小助手会拉你进群~~

【活动】Nebula Hackathon 2021 进行中,一起来探索未知,领取 ¥ 150,000 奖金 →→ https://nebula-graph.com.cn/hackathon/

Nebula Graph 源码解读系列 | Vol.04 基于 RBO 的 Optimizer 实现的更多相关文章

  1. 新手阅读 Nebula Graph 源码的姿势

    摘要:在本文中,我们将通过数据流快速学习 Nebula Graph,以用户在客户端输入一条 nGQL 语句 SHOW SPACES 为例,使用 GDB 追踪语句输入时 Nebula Graph 是怎么 ...

  2. Alamofire源码解读系列(二)之错误处理(AFError)

    本篇主要讲解Alamofire中错误的处理机制 前言 在开发中,往往最容易被忽略的内容就是对错误的处理.有经验的开发者,能够对自己写的每行代码负责,而且非常清楚自己写的代码在什么时候会出现异常,这样就 ...

  3. Alamofire源码解读系列(四)之参数编码(ParameterEncoding)

    本篇讲解参数编码的内容 前言 我们在开发中发的每一个请求都是通过URLRequest来进行封装的,可以通过一个URL生成URLRequest.那么如果我有一个参数字典,这个参数字典又是如何从客户端传递 ...

  4. Alamofire源码解读系列(三)之通知处理(Notification)

    本篇讲解swift中通知的用法 前言 通知作为传递事件和数据的载体,在使用中是不受限制的.由于忘记移除某个通知的监听,会造成很多潜在的问题,这些问题在测试中是很难被发现的.但这不是我们这篇文章探讨的主 ...

  5. Alamofire源码解读系列(五)之结果封装(Result)

    本篇讲解Result的封装 前言 有时候,我们会根据现实中的事物来对程序中的某个业务关系进行抽象,这句话很难理解.在Alamofire中,使用Response来描述请求后的结果.我们都知道Alamof ...

  6. Alamofire源码解读系列(六)之Task代理(TaskDelegate)

    本篇介绍Task代理(TaskDelegate.swift) 前言 我相信可能有80%的同学使用AFNetworking或者Alamofire处理网络事件,并且这两个框架都提供了丰富的功能,我也相信很 ...

  7. Alamofire源码解读系列(七)之网络监控(NetworkReachabilityManager)

    Alamofire源码解读系列(七)之网络监控(NetworkReachabilityManager) 本篇主要讲解iOS开发中的网络监控 前言 在开发中,有时候我们需要获取这些信息: 手机是否联网 ...

  8. Alamofire源码解读系列(八)之安全策略(ServerTrustPolicy)

    本篇主要讲解Alamofire中安全验证代码 前言 作为开发人员,理解HTTPS的原理和应用算是一项基本技能.HTTPS目前来说是非常安全的,但仍然有大量的公司还在使用HTTP.其实HTTPS也并不是 ...

  9. Alamofire源码解读系列(九)之响应封装(Response)

    本篇主要带来Alamofire中Response的解读 前言 在每篇文章的前言部分,我都会把我认为的本篇最重要的内容提前讲一下.我更想同大家分享这些顶级框架在设计和编码层次究竟有哪些过人的地方?当然, ...

  10. Alamofire源码解读系列(十)之序列化(ResponseSerialization)

    本篇主要讲解Alamofire中如何把服务器返回的数据序列化 前言 和前边的文章不同, 在这一篇中,我想从程序的设计层次上解读ResponseSerialization这个文件.更直观的去探讨该功能是 ...

随机推荐

  1. 【验证码逆向专栏】数美验证码全家桶逆向分析以及 AST 获取动态参数

    声明 本文章中所有内容仅供学习交流使用,不用于其他任何目的,不提供完整代码,抓包内容.敏感网址.数据接口等均已做脱敏处理,严禁用于商业用途和非法用途,否则由此产生的一切后果均与作者无关! 本文章未经许 ...

  2. Python下的三维建模和可视化

    本文介绍基于AnyCAD Rapid Py三维图形平台开发Python的三维应用 1 准备工作 1.1 安装 vc_resit 2022 在Windows下,AnyCAD Rapid SDK依赖Vis ...

  3. MD5算法:高效安全的数据完整性保障

    摘要:在数字世界中,确保数据完整性和安全性至关重要.消息摘要算法就是一种用于实现这一目标的常用技术.其中,Message Digest Algorithm 5(MD5)算法因其高效性和安全性而受到广泛 ...

  4. 手把手教你-把Kali Linux系统安装到U盘 【超详细】(随身携带/即插即用)

    [0-背景说明]: 1)为什么想要把Kali Linux系统安装到U盘? 之前学习渗透测试的时候,有安装过虚拟机,在虚拟机上安装Kali Linux系统,但是因为是在现有系统上安装虚拟机又安装kali ...

  5. 创建大量栅格文件并分别写入像元数据:C++ GDAL代码实现

      本文介绍基于C++语言GDAL库,批量创建大量栅格遥感影像文件,并将数据批量写入其中的方法.   首先,我们来明确一下本文所需实现的需求.已知我们对大量遥感影像进行了批量读取与数据处理操作--具体 ...

  6. 《ASP.NET Core 与 RESTful API 开发实战》-- (第8章)-- 读书笔记(上)

    第 8 章 认证和安全 8.1 认证 认证(Authentication)是指验证用户身份的过程,授权(Authorization)是验证一个已经通过认证的用户是否有权限做某些事的过程 常见的 HTT ...

  7. .NET Core开发实战(第28课:工作单元模式(UnitOfWork):管理好你的事务)--学习笔记

    28 | 工作单元模式(UnitOfWork):管理好你的事务 工作单元模式有如下几个特性: 1.使用同一上下文 2.跟踪实体的状态 3.保障事务一致性 我们对实体的操作,最终的状态都是应该如实保存到 ...

  8. 下载Apache软件基金的软件和项目(Hadoop相关组件)

    一.下载Hadoop相关组件,可以到Apache软件基金的资源目录: Apache 分发目录地址:https://dlcdn.apache.org/ 二.下载软件 方法一:在页面中找到需要下载的软件目 ...

  9. JS leetcode 反转字符串中的单词 III 题解分析

    壹 ❀ 引 又到了快乐的leetcode算法时间,今天的题目特别特别简单,来自leetcode557. 反转字符串中的单词 III,题目描述如下: 给定一个字符串,你需要反转字符串中每个单词的字符顺序 ...

  10. CF1833F Ira and Flamenco

    题目链接 题解 知识点:组合数学,枚举,双指针. 注意到,长度为 \(m\) 且数字各不相同的子序列,那么最大值与最小值的差至少为 \(m-1\) .因此,对于任意子序列,它是合法的,当且仅当,将其从 ...