构建分布式系统和单机软件完全不同。在分布式系统中，系统有一千种奇妙的出错方法，本章将会探讨其中的一部分。

分布式系统中的麻烦事（上）：系统故障，以及不可靠的网络

在用户使用 NebulaGraph 的过程中，经常会遇到各种问题，通常我们都会建议先通过 `show hosts` 查看集群状态。可以说，整个 NebulaGraph 的集群状态都是靠心跳机制来构建的。本文将从心跳说起，帮助你了解 NebulaGraph 集群各个节点之间通信的机制。

# 什么是心跳？有什么作用？

![metad storaged graphd 通信](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-metad-storaged-graphd-v-r-family.png)

NebulaGraph 集群一般包含三种节点，graphd 作为查询节点，storaged 作为存储节点，metad 作为元信息节点。本文说的心跳，主要是指 graphd 和 storaged 定期向 metad 上报信息的这个心跳，借助心跳，整个集群完成了以下功能。（相关参数是 `heartbeat_interval_secs`）

> 在 NebulaGraph 中经常提及的 raft 心跳则是用于拥有同一个 partition 的多个 storaged 之间的心跳，和本文提的心跳并不相同。

## 1. 服务发现

当我们启动一个 NebulaGraph 集群时，需要在对应的配置文件中填写 `meta_server_addrs`。graphd 和 storaged 在启动之后，就会通过这个 `meta_server_addrs` 地址，向对应的 metad 发送心跳。通常来说，graphd 和 storaged 在连接上 metad 前是无法对外进行服务的。当 metad 收到心跳后，会保存相关信息（见下文第 2 点），此时就能够通过 show hosts 看到对应的 storaged 节点，在 2.x 版本中，也能够通过 `show hosts graph` 看到 graphd 节点。

## 2. 上报节点信息

在 metad 收到心跳时，会将心跳中的 ip、port、节点类型、心跳时间等等信息保存，以供后续使用（见下文）。

除此以外 storaged 在自身 leader 数量变化的时候也会上报 leader 信息，在 `show hosts` 中看到的 Leader count 和 Leader distribution 就是通过心跳汇报的。

## 3. 更新元信息

当客户通过 console 或者各种客户端，对集群的元信息进行更改之后（例如 `create/drop space`、`create/alter/drop tag/edge`、`update configs` 等等），通常在几秒之内，整个集群就都会更新元数据。

每次 graphd 和 storaged 在心跳的响应中会包含一个 `last_update_time`，这个时间是由 metad 返回给各个节点的，用于告知 metad 自身最后一次更新元信息的时间。当 graphd 或者 storaged 发现 metad 的元信息有更新，就会向 metad 获取相应信息（例如 space 信息、schema 信息、配置更改等等）。

> 我们以创建一个 tag 为例，如果在 graphd/storaged 获取到新创建的这个 tag 信息之前，我们无法插入这个 tag 数据（会报类似 **No schema found** 这样的错误）。而当通过心跳获取到对应信息并保存至本地缓存后，就能够正常写入数据了。

# 心跳上报的信息有什么用？

- `show hosts`、`show parts` 这类命令都是通过 metad 中保存的各个节点心跳信息，组合显示出来的。
- `balance data`、`balance leader` 等运维命令，需要通过获取当前集群内哪些 storaged 节点是在线状态，实际也是通过 metad 判断最近一次心跳时间是否在阈值之内。
- `create space`，当用户创建一个 space 时，metad 也需要获取 storaged 的状态，将这个 space 的各个 partition 分配到在线的 storaged 中。

> 以用户容易遇到的问题为例：假如我们启动一个 storaged 后，关掉并修改端口号，然后再启动 storaged。如果这个过程足够快，那么通过 `show hosts` 能看到两个在线的 storaged。此时，如果新建一个 space，例如 `CREATE space test(partition_num=10, replica_factor=1)`，这个 test space 就会分布在前后启动的两个 storage 上。但如果等到在 show hosts 中看到其中一个离线后，再执行 `CREATE space test(partition_num=10, replica_factor=1)`，即便离线的 storaged 再启动，也只有一个 storaged 拥有这个 space（创建 test space 时 online 的那个 storaged）。

![上线](https://www-cdn.nebula-graph.com.cn/nebula-blog/heart-beat-online.png)

![掉线](https://www-cdn.nebula-graph.com.cn/nebula-blog/heart-beat-offline.png)

# 心跳的演变历史

在 18-19 年的时候，当时的心跳机制没有这么完善。一方面，无论元信息是否更改，都会从 metad 获取最新的元信息。而通常来说，元信息改动不会很频繁，定期获取元信息有一定的资源浪费。另一方面，想要将一个 storaged 节点加入和移除都是通过类似 `add/delete hosts` 这样的命令，采取的是类似白名单的机制。对于其他没有认证过的节点，都无法对外服务，这样做固然也有一些优势，带来的最大问题就是不够友好。

因此，在 19 年底开始，我们对心跳做了一系列的改动，特别鸣谢社区用户 @zhanggguoqing。经过一段时间的验证踩坑后，基本就形成了现在的形式。

# 额外的补充

有关心跳还有一个涉及到的问题就是 _cluster.id_ 这个文件。它实际是为了防止 storaged 与错误的 metad 通信，大致原理如下：

- 首先，metad 在启动的时候会根据 `meta_server_addrs` 这个参数，生成一个 hash 值并保存在本地 kv 中。
- storaged 在启动的时候会尝试从 _cluster.id_ 这个文件中获取对应 metad 的 hash 值，并附送在心跳中发送（如果文件不存在，则第一次使用 0 代替。收到心跳响应时，将 metad 的 hash 值保存在 _cluster.id_ 这个文件中，后续一直使用该值）。
- 在心跳处理中，metad 会比较本地 hash 值和来自 storaged 心跳请求中的 hash 值，如果不匹配则拒绝。此时，storaged 是无法对外服务的，也就是 _Reject wrong cluster host_ 这个日志的由来。

以上就是心跳机制大致的介绍，感兴趣的你可以参考下源码实现，GitHub 传送门：[https://github.com/vesoft-inc/nebula-graph](https://github.com/vesoft-inc/nebula-graph)。

# 推荐阅读

- [分布式图数据库 NebulaGraph 的 Index 实践](https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/)
- [分布式图数据库 NebulaGraph 中的集群快照实践](https://nebula-graph.com.cn/posts/introduction-to-snapshot-in-nebula-graph/)


本文将从心跳说起，帮助你了解 NebulaGraph 集群各个节点之间通信的机制。

一文带你了解图数据库 NebulaGraph 集群通信机制

本文旨在帮助 NebulaGraph 新手快速了解查询语句调优，读懂查询计划。

nGQL 简明教程 vol.02 执行计划详解与调优 转至元数据结尾

NebulaGraph Exchange 的性能如何？哪些参数调整下可以有更好的性能？本文带你了解 NebulaGraph Exchange 的最佳使用姿势。

从实测出发，掌握 NebulaGraph Exchange 性能最大化的秘密

LOOKUP 是图数据库 NebulaGraph 的一个查询语句。它依赖索引，可以查询点或者边的信息。本文将着重从源码的角度解析一下 LOOKUP 语句的一生是如何度过的。

读 NebulaGraph源码 ｜ 查询语句 LOOKUP 的一生

# 前言

在先前的 Query Engine 源码解析中，我们介绍了 2.0 中 [Query Engine](https://mp.weixin.qq.com/s/vayb9PvvBkmXkK06n8ni9w) 和 1.0 的主要变化和大体的结构：

![架构变化](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-query-engine.png)

大家可以大概了解到用户通过客户端发送一条查询语句，Query Engine 是如何解析语句、把语句构建为抽象语法树，在抽象语法树进行校验、生成执行计划的过程。本文会通过 2.0 中新增的子图算法模块继续讲解 Query Engine 背后所做的内容，并着重介绍执行计划生成的过程，以便加强你对源码更好地理解。

# 子图的定义

子图是指节点集合和边集合分别是某一图的节点集的子集和边集的子集的图。直观地理解，就是从用户指定的起点开始出发沿着指定的边一步步拓展，直到达到用户所设定的步数为止，然后返回在拓展过程中遇到的所有点集和边集。

# 子图的语法​

```shell
GET SUBGRAPH [<step_count> STEPS] FROM {<vid>, <vid>...} [IN <edge_type>, <edge_type>...]
[OUT <edge_type>, <edge_type>...] [BOTH <edge_type>, <edge_type>...]
```

- step_count：指定从起始点开始的跳数，返回从 0 到 `step_count` 跳的子图。必须是非负整数。默认值为 1
- vid：指定起始点 ID
- edge_type：指定边类型。可以用 `IN`、`OUT` 和 `BOTH` 来指定起始点上该边类型的方向。默认为 `BOTH`

# 子图的实现

当 Query Engine 接收到 `GET SUBGRAPH` 命令后，Parser 模块（由 flex 和 bison 实现）会根据已经写好的规则（`parser.yy` 中 `get_subgraph_sentence` 规则）把所需要的内容从查询语句中提取出来，生成一个抽象语法树，如下所示：

![解析 NebulaGraph 子图设计及实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-abstract-tree.png)

然后进入 Validate 阶段，此时对生成的抽象语法树进行校验，目的是为了验证用户的输入是否合法（参考  [Query Engine](https://mp.weixin.qq.com/s/vayb9PvvBkmXkK06n8ni9w) 的文章），当校验通过后，会把语法树中的内容提取出来，生成一个执行计划。
​
那么这个执行计划是如何生成的呢？对同一功能不同的数据库厂商可能会生成不同的执行计划，但是原理都是相同的。那就是要看自身的算子有哪些和查询层和存储层是如何进行交互的。因为我们的每一条查询语句到最后都是要从存储层取数据的。在 NebulaGraph 中 Query Engine 和存储层是通过 RPC 方式（fbthrift）进行交互的（接口定义在 common 仓中的 interface 目录下）。这里有两个非常关键的接口 getNeighbors 和 getProps 需要了解一下。

getNeighbors 其中 fbthrift 的定义格式如下：

```shell
struct GetNeighborsRequest {    
    1: common.GraphSpaceID                      space_id,
    2: list<binary>                             column_names,
    3: map<common.PartitionID, list<common.Row>>
        (cpp.template = "std::unordered_map")   parts,
    4: TraverseSpec                             traverse_spec
}
```

该结构中每个变量的详细定义可以参考 [https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift](https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift)，里面有详细的注释。
​

其主要功能就是 Query Engine 根据定义好的结构传入起始点和要拓展的边类型信息，然后存储层会找到起始点，然后把该点的属性和以该点的出边的边属性找出来组装成一个表格返回给 Query Engine，其中返回的表格的格式参考  [https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift](https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift) 中 GetNeighborsResponse 的定义，然后在 Query Engine 中我们就可以通过这个表格提取到我们想要的内容。
​
例如在 basketba l l 数据集中，当起始点为 Tim Duncan、Manu Ginobili 沿着 `like` 边双向拓展。想要获得 `$^.[player.name](http://player.name/)`、`like._dst`、`$$.[player.name](http://player.name/)` 和 `like.likeness` 这四个属性。其返回的数据大致如下所示：

![数据图](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-table1.png)

表格1

因为是双向拓展第四列的 `+ like` 代表出边，第五列的 `- like` 代表入边。

在 NebulaGraph 的存储层中边是和起始点在一起存放的，所以通过 getNeighbor 接口就可以获得起点和出边的所有属性信息，但是如果想要在拓展过程中拿到目的点的属性信息则需要使用 getProps 接口，当然如果我只想通过 fetch 语句拿到某个点或者边的属性也需要调用这个接口。你可以自行了解 [https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift](https://github.com/vesoft-inc/nebula-common/blob/master/src/common/interface/storage.thrift) 下 getPropRequest 的定义，加深理解。

## 执行计划

有了上面的接口定义我们就可以开始执行计划了，首先需要的算子有 start、getNeighbor、subgraph、loop、datacollect。

- start 算子：相当于执行计划中叶子节点，不做任何事情。目的是告诉调度器，之后没有可以依赖的算子，或者可以理解为递归算法中的终止条件。
- loop 算子：相当于 C 语言中的 while 语法，该算子有三个成员 depend、condition 和 loopBody，depend 在多语句和 `PIPE` 中会使用当前暂且不表，condition 相当于终止条件。loopBody 相当于 while 中的循环体。
- subgraph 算子：负责把 getNeighbor 算子结果中的 `_dst`（目的点）属性提出来然后过滤掉已经访问过的目的点（避免重复从存储层拿数据），然后把它们当作 getNeighbor 算子下一次拓展时的输入。
- datacollect 算子：负责在最后把拓展过程中获得的点和边属性收集起来组装为 vertex 和 edge 类型。

其中各个算子的详细信息，可参考源码 [https://github.com/vesoft-inc/nebula-graph/tree/master/src/executor](https://github.com/vesoft-inc/nebula-graph/tree/master/src/executor) 。
下面通过图1 举例，我们是如何构建子图的

![构建子图](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-create-subgraph.png)
图1

**拓展一步的情况**

当从 A 点开始沿着 `like` 边只获取一步的所有点和边的信息，则很容易。只需要 getNeighbor 和 dataCollect 这两个算子就可以了。执行计划如下图所示 ：

![拓展一步的情况](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-1-step.png)

**拓展多步的情况**

一步场景其实是多步的场景的特殊情况。所以可以将一步的场景合入到多步场景中。当从 A 点开始，沿着 like 边拓展三步的话，根据现有的算子，可以在 getNeighbor 拓展后把目的点提取出来，然后将这些目的点当作起点重新调用 getNeighbor 接口，这个循环两次就可以了（loop 算子的终止条件设置为当前步数），因此执行计划如下图所示 ：

![拓展多步的情况](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-n-step.png)

**输入和输出**

一般情况下，每个算子的输入就是所依赖算子的输出，这时候根据执行计划的依赖关系就可以直观地确定每个算子的输入和输出。但是在某些情况下，比如：子图，在多步场景中每一次 getNeighbor 算子的输入都应该是上一次拓展边的目的点，也就是 subgraph 算子的输出，因此 subgraph 算子的输出应该就是 getNeighbor 算子的输入。这时就和上图的执行计划依赖不一致，这时就需要自行设置每个算子的输入和输出。在 Query Engine 2.0 中我们已经介绍了每个算子的输入和输出是存放在哈希表中的，其中 value 是 vector 类型。如下表 ResultMap 所示：

![ResultMap](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-result-map-1.png)

- 起始点存放在 ResultMap["StartVid"] 中
- getNeighbor 算子的输入是 ResultMap["StartVid"], 输出存放在 ResultMap["GN_1"]
- subgraph 算子的输入是 ResultMap["GN_1"], 输出存放在 ResultMap["StartVid"]
- loop 算子不产生数据，当作逻辑循环使用，因此不需要设置输入输出
- dataCollect 算子的输入是 ResultMap["GN_1"], 输出存放在 ResultMap["DATACOLLECT_2"]

这时 getNeighbor 算子会把每一次的结果放在 ResultMap["GN_1"] 中的 vector 中的末尾，然后 subgraph 算子从 ResultMap["GN_1"] 中的 vector 中的末尾取值，经过计算再把下一次要拓展的起始点存放在 ResultMap["StartVid"] 中。

当拓展第一步后，ResultMap 的结果如下：
​
![ResultMap](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-result-map-2.png)

为了方便显示，GetNeighbor 的结果只写了 `_dst` 的属性，实际上会带上边上所有的属性和起始点的所有属性，类似于表格 1。

subgraph 算子接收"GN_1"的输入，提取 `_dst` 属性，然后将结果放入"StartVid"中。当拓展第二步后，ResultMap 的结果如下：

![ResultMap](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-result-map-3.png)

当拓展第三步后，ResultMap 的结果如下：

![ResultMap](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-result-map-4.png)

最后 dataCollect 算子从 ResultMap["GN_1"] 中取出拓展过程中遇到的所有点集和边集，组装成最终的结果返回给用户。

# 实例

下面执行一个子图的实例看看在 NebulaGraph 中执行计划的具体结构，打开 nebula-console, 切换 space 到 basketball， 输入 `EXPLAIN format="dot" GET SUBGRAPH 2 STEPS FROM 'Tim Duncan' IN like, serve`，这时候 nebula-console 会生成 dot 格式的数据，然后打开 [Graphviz Online](https://dreampuf.github.io/GraphvizOnline/) 这个网站，将生成的 dot 数据粘贴上去，就可以看到如下结构：

![dot 结果](https://www-cdn.nebula-graph.com.cn/nebula-blog/subgraph-dot-result.png)

其中 Start_0 算子是 loop 算子中 depend 的依赖，由于没有多语句或 PIPE 语句，因此不做任何处理。
​
以上为本次子图的讲解，如果你在使用子图或者其他 Nebula 过程中遇到问题，欢迎来论坛和我们交流：[https://discuss.nebula-graph.com.cn/](https://discuss.nebula-graph.com.cn/)


本文通过 2.0 中新增的子图算法模块继续讲解 Query Engine 背后的故事，以便加强你对源码更好地理解

解析 NebulaGraph 子图设计及实践


![基于 NebulaGraph 构建百亿关系知识图谱实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph.jpg)

# 一、项目背景

微澜是一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用，其中包含着百亿级的关系和数十亿级的实体，为了使这套业务能够完美运行起来，经过调研，我们使用 NebulaGraph 作为承载我们知识图谱业务的主要数据库，随着 NebulaGraph 的产品迭代，我们最终选择使用 v2.5.1 版本的 NebulaGraph 作为最终版本。

# 二、为什么选择 NebulaGraph？

在开源图数据库领域，无疑存在着很多选择，但为了支撑如此大规模数据的知识图谱服务，NebulaGraph 对比其他的图数据库具有以下几个优点，这也是我们选择 NebulaGraph 的原因：

1. **对于内存的占用较小**

在我们的业务场景下，我们的 QPS 比较低且没有很高的波动，同时相比起其他的图数据库，NebulaGraph 具有更小的闲时内存占用，所以我们可以通过使用内存配置更低的机器去运行 NebulaGraph 服务，这无疑为我们节省了成本。

2. **使用 multi-raft 一致性协议**

multi-raft 相比于传统的 raft，不仅增加了系统的可用性，而且性能比传统的 raft 要高。共识算法的性能主要在于其是否允许空洞和粒度切分，在应用层无论 KV 数据库还是 SQL ，能成功利用好这两个特性，性能肯定不会差。由于 raft 的串行提交极其依赖状态机的性能，这样就导致即使在 KV 上，一个 key 的 op 慢，显著会拖慢其他 key。所以，一个一致性协议的性能高低的关键，一定是在于状态机如何让可以并行地尽量并行，纵使 multi-raft 的粒度切分比较粗（相比于 Paxos），但对于不允许空洞的 raft 协议来说，还是有巨大的提升。

3. **存储端使用 RocksDB 作为存储引擎**

RocksDB 作为一款存储引擎/嵌入式数据库，在各种数据库中作为存储端得到了广泛地使用。更关键的是 NebulaGraph 可以通过调整 RocksDB 的原生参数来改善数据库性能。

4. **写入速度快**

我们的业务需要频繁地大量写入，NebulaGraph 即使在具有大量长文本内容的 vertex 的情况下（集群内3 台机器、3 份数据，16 线程插入）插入速度也能达到 2 万/s 的插入速度，而无属性边的插入速度在相同条件下可以达到 35 万/s。

# 三、使用 NebulaGraph 时我们遇到了哪些问题？

在我们的知识图谱业务中，很多场景需要向用户展示经过分页的一度关系，同时我们的数据中存在一些超级节点，但根据我们的业务场景，**超级节点一定会是用户访问可能性最高的节点，所以这不能被简单归类到长尾问题上**；又因为我们的用户量并不大，所以缓存必然不会经常被撞到，我们需要一套解决方案来使用户的查询延迟更小。

举例：业务场景为查询这个技术的下游技术，同时要根据我们设置的排序键进行排序，此排序键是局部排序键。比如，某个机构在某一领域排名特别高，但是在全局或者其他领域比较一般，这种场景下我们必须把排序属性设置在边上，并且对于全局排序项进行拟合与标准化，使得每个维度的数据的方差都为 1，均值都为 0，以便进行局部的排序，同时还要支持分页操作方便用户查询。

语句如下：

```SQL
MATCH (v1:technology)-[e:technologyLeaf]->(v2:technology) WHERE id(v2) == "foobar" \ 
RETURN id(v1), v1.name, e.sort_value AS sort ORDER BY sort | LIMIT 0,20;
```
此节点有 13 万邻接边，这种情况下即使对 sort_value 属性加了索引，查询耗时还是将近两秒。这个速度显然无法接受。

我们最后选择使用蚂蚁金服开源的 OceanBase 数据库来辅助我们实现业务，数据模型如下：

technologydownstream

|technology_id|downstream_id|sort_value|
| --------| -----| --------|
|foobar|id1|1.0|
|foobar|id2|0.5|
|foobar|id3|0.0|

technology

|id|name|sort_value|
| --------| -----| --------|
|id1|aaa|0.3|
|id2|bbb|0.2|
|id3|ccc|0.1|

查询语句如下：

```SQL
SELECT technology.name FROM technology INNER JOIN (SELECT technologydownstream.downstream_id FROM technologydownstream 
WHERE technologydownstream.technology_id = 'foobar' ORDER BY technologydownstream.sort_value DESC LIMIT 0,20) AS t 
WHERE t.downstream_id=technology.id; 
```
此语句耗时 80 毫秒。这里是整个架构设计

![基于 NebulaGraph 构建百亿关系知识图谱实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph-01.jpeg)

# 四、使用 NebulaGraph 时我们如何调优？

前面讲过 NebulaGraph 的一个很大的优势就是可以使用原生 RocksDB 参数进行调优，减少学习成本，关于调优项的具体含义以及部分调优策略我们分享如下：

| RocksDB 参数|含义|
| --------| -----|
|max_total_wal_size|一旦 wal 的文件超过了 max_total_wal_size 会强制创建新的 wal 文件，默认值为 0时，max_total_wal_size = write_buffer_size * max_write_buffer_number * 4 |
| delete_obsolete_files_period_micros |删除过期文件的周期，过期的文件包含 sst 文件和 wal 文件， 默认是 6 小时|
|max_background_jobs|最大的后台线程数目 = max_background_flushes + max_background_compactions|
| stats_dump_period_sec |如果非空，则每隔 stats_dump_period_sec 秒会打印 rocksdb.stats 信息到 LOG 文件	|
| compaction_readahead_size |压缩过程中预读取硬盘的数据量。如果在非 SSD 磁盘上运行 RocksDB，为了性能考虑则应将其设置为至少 2 MB。如果是非零，同时会强制new_table_reader_for_compaction_inputs=true|
| writable_file_max_buffer_size |WritableFileWriter 使用的最大缓冲区大小 RocksDB 的写缓存，对于 Direct IO 模式的话，调优该参数很重要。|
| bytes_per_sync |每次sync的数据量，累计到 bytes_per_sync 会主动 Flush 到磁盘，这个选项是应用到 sst 文件，wal 文件使用 wal_bytes_per_sync|
| wal_bytes_per_sync |wal 文件每次写满 wal_bytes_per_sync 文件大小时，会通过调用 sync_file_range 来刷新文件，默认值为 0 表示不生效|
| delayed_write_rate |如果发生 Write Stall， 写入的速度将被限制在 delayed_write_rate 以下|
| avoid_flush_during_shutdown |默认情况下，DB 关闭时会刷新所有的 memtable，如果设置了该选项那么将不会强制刷新，可能造成数据丢失|
| max_open_files |RocksDB 可以打开文件的句柄数量(主要是 sst文件)，这样下次访问的时候就可以直接使用，而不需要重新在打开。当缓存的文件句柄超过 max_open_files 之后，一些句柄就会被 close 掉，要注意句柄 close 的时候相应 sst 的 index cache 和 filter cache 也会一起释放掉，因为 index block 和 filter block 缓存在堆上，数量上限由 max_open_files 选项控制。依据 sst 文件的 index_block 的组织方式判断，一般来说 index_block 比 data_block 大 1 到 2 个数量级，所以每次读取数据必须要先加载 index_block，此时 index 数据放在堆上，并不会主动淘汰数据；如果大量的随机读的话，会导致严重的读放大，另外可能导致 RocksDB 不明原因的占据大量的物理内存，所以此值的调整非常重要，需要根据自己的 workload 在性能和内存占用上做取舍。如果此值为 -1，RocksDB 将一直缓存所有打开的句柄，但这个会造成比较大量的内存开销|
| stats_persist_period_sec |如果非空，则每隔 stats_persist_period_sec 自动将统计信息保存到隐藏列族___ rocksdb_stats_history___。|
| stats_history_buffer_size |如果不为零，则定期获取统计信息快照并存储在内存中，统计信息快照的内存大小上限为 stats_history_buffer_size|
| strict_bytes_per_sync|RocksDB 把数据写入到硬盘时为了性能考虑，默认没有同步 Flush，因此异常情况下存在丢失数据的可能，为了对丢失数据数量的可控，需要一些参数来设定刷新的动作。如果此参数为 true，那么 RocksDB 将严格的按照 wal_bytes_per_sync 和 bytes_per_sync 的设置刷盘，即每次都刷新完整的一个文件，如果此参数为 false 则每次只刷新部分数据：也就是说如果对可能的数据丢失不怎么 care，就可以设置 false，不过还是推荐为 true|
| enable_rocksdb_prefix_filtering |是否开启 prefix_bloom_filter，开了之后会根据写入 key 的前 rocksdb_filtering_prefix_length 位在 memtable 构造 bloom filter|
| enable_rocksdb_whole_key_filtering |在 memtable 创建 bloomfilter，其中映射的 key 是 memtable 的完整 key 名，所以这个配置和 enable_rocksdb_prefix_filtering 冲突，如果 enable_rocksdb_prefix_filtering 为 true，则这个配置不生效|
|rocksdb_filtering_prefix_length|见 enable_rocksdb_prefix_filtering|
| num_compaction_threads|后台并发 compaction 线程的最大数量，实际是线程池的最大线程数，compaction 的线程池默认为低优先级|
|rate_limit|用于记录在代码里通过 NewGenericRateLimiter 创建速率控制器的参数，这样重启的时候可以通过这些参数构建 rate_limiter。rate_limiter 是 RocksDB 用来控制 Compaction 和 Flush 写入速率的工具，因为过快的写会影响数据的读取，我们可以这样设置：`rate_limit = {"id":"GenericRateLimiter"; "mode":"kWritesOnly"; "clock":"PosixClock"; "rate_bytes_per_sec":"200"; "fairness":"10"; "refill_period_us":"1000000"; "auto_tuned":"false";}`|
| write_buffer_size|memtable 的最大 size，如果超过了这个值，RocksDB 就会将其变成 immutable memtable，并创建另一个新的 memtable|
| max_write_buffer_number|最大 memtable 的个数，包含 mem 和 imm。如果满了，RocksDB 就会停止后续的写入，通常这都是写入太快但是 Flush 不及时造成的|
| level0_file_num_compaction_trigger|Leveled Compaction 专用触发参数，当 L0 的文件数量达到 level0_file_num_compaction_trigger 的值时，则触发 L0 和 L1 的合并。此值越大，写放大越小，读放大越大。当此值很大时，则接近 Universal Compaction 状态|
|level0_slowdown_writes_trigger|当 level0 的文件数大于该值，会降低写入速度。调整此参数与level0_stop_writes_trigger 参数是为了解决过多的 L0 文件导致的 Write Stall 问题|
|level0_stop_writes_trigger|当 level0 的文件数大于该值，会拒绝写入。调整此参数与level0_slowdown_writes_trigger 参数是为了解决过多的 L0 文件导致的 Write Stall 问题|
| target_file_size_base|L1 文件的 SST 大小。增加此值会减少整个 DB 的 size，如需调整可以使target_file_size_base = max_bytes_for_level_base / 10，也就是 level 1 会有 10 个 SST 文件即可|
| target_file_size_multiplier |使得 L1 上层(L2...L6)的文件的 SST 的 size 都会比当前层大 target_file_size_multiplier 倍|
| max_bytes_for_level_base|L1 层的最大容量（所有 SST 文件大小之和），超过该容量就会触发 Compaction|
| max_bytes_for_level_multiplier|每一层相比上一层的文件总大小的递增参数|
| disable_auto_compactions|是否禁用自动 Compaction|

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

本文讲述了 NebulaGraph 是如何护航微澜的实时资讯业务之余，用了大篇幅来讲述底层数据库的调优方法。

基于 NebulaGraph 构建百亿关系知识图谱实践

经测试 KV 分离对于小 value 的查询延迟降低可高达 80.7%；对于大 value 的查询，可达到 52.5%。Nebula 的 KV 分离是如何做到这种性能提升的呢？这篇文章给你答案~

NebulaGraph 的 KV 存储分离原理和性能测评

除了 v3.0.0 的性能报告之外，还有和 Baseline 的性能对比。

NebulaGraph v3.0.0 性能报告


![Geospatial Data 在 NebulaGraph 中的实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/geospatial-data-practice.webp)

本文主要介绍了地理空间数据（Geospatial Data）以及它在 NebulaGraph 中的具体实践。 

# Geospatial Data 在 NebulaGraph 中的实践

## 什么是 Geospatial Data

地理空间数据（Geospatial Data）是包含简单地理空间要素信息的数据，比如点（point）、线（linestring）、多边形（polygon），或是其他更复杂的形状。

NebulaGraph 在 2.6 版本中引入了对 Geospatial Data 完整的支持，包括地理空间数据的存储、计算，以及索引。NebulaGraph 目前支持 Geography 类型的地理空间数据，Geography 类型是建模在地球空间坐标系上由经纬度坐标对表示的地理位置信息。

### Geospatial Data -- 地理空间数据使用

#### 创建 Schema

这里仅以 Tag 为例，当然 Edgetype 上同样可以将 Geography 类型作为属性列。

Nebula 目前支持点、线、多边形三种空间数据类型。下面介绍一下如何如何创建 Geography 类型属性以及如何插入地理空间数据到 Nebula 中。

```
CREATE TAG any_shape(geo geography);
CREATE TAG only_point(geo geography(point));
CREATE TAG only_linestring(geo geography(linestring));
CREATE TAG only_polygon(geo geography(polygon));
```

当 `geography` 属性后面没有指定具体的地理形状信息时，代表该列可以存储任意地理形状的数据；当指定形状类型时，则代表只能存储该形状的地理数据，比如 `geography(point)`，就代表该列只能存储 point 形状的地理位置信息。

#### 插入数据

向 Tag `any_shape` 的 `geo` 列插入数据：

```
INSERT VERTEX any_shape(geo) VALUES "101":(ST_GeogFromText("POINT(120.12 30.16)"));
INSERT VERTEX any_shape(geo) VALUES "102":(ST_GeogFromText("LINESTRING(3 8, 4.7 73.23)"));
INSERT VERTEX any_shape(geo) VALUES "103":(ST_GeogFromText("POLYGON((75.3 45.4, 112.5 53.6, 122.7 25.5, 93.9 28.6, 75.3 45.4))"));
```

向 Tag `only_point` 的 `geo` 列插入数据：

```
INSERT VERTEX only_point(geo) VALUES "201":(ST_Point(120.12，30.16)"));;
```

向 Tag `only_linestring` 的 `geo` 插入数据：

```
INSERT VERTEX only_linestring(geo) VALUES "302":(ST_GeogFromText("LINESTRING(3 8, 4.7 73.23)"));
```

向 Tag `only_polygon`的 `geo` 列插入数据：

```
INSERT VERTEX only_polygon(geo) VALUES "403":(ST_GeogFromText("POLYGON((75.3 45.4, 112.5 53.6, 122.7 25.5, 93.9 28.6, 75.3 45.4))"));
```

当插入地理数据形状不符合该列地理形状要求时，会报错无法插入:

```
(root@nebula) [geo]> INSERT VERTEX only_polygon(geo) VALUES "404":(ST_GeogFromText("POINT((75.3 45.4))"));
[ERROR (-1005)]: Wrong value type: ST_GeogFromText("POINT((75.3 45.4))")
```
我们可以看到地理空间数据插入方法比较奇特，和 int、string、bool 等基本类型的插入很不一样。

我们以 `ST_GeogFromText("POINT(120.12 30.16)")` 为例，ST_GeogFromText 是一个地理位置信息解析函数，它接受一个 string 类型的 WKT（Well-Known Text）标准格式表示的地理位置数据：

`POINT(120.12 30.16)` 代表一个东经 120°12′，北纬 30°16′ 的地理位置点。ST_GeogFromText 函数会从 wkt 参数中解析并构造一个 geography 数据对象，然后 `INSERT` 语句会将其以 WKB（Well-Known Binary）标准存储在 Nebula 中。

### Geospatial functions -- 地理空间函数

Nebula 支持的地理空间函数可以分为以下几大类:

- 构造函数
  * ST_Point(longitude, latitude)，根据一对经纬度构造一个 geography point 对象
- 解析函数
  * ST_GeogFromText(wkt_string)，从 wkt 文本中解析 geography 对象
  * ST_GeogFromWKB(wkb_string)，从 wkb 文本中解析 geography 对象 # 尚未正式支持，因为 Nebula还未支持二进制字符串
- 格式设置函数
  * ST_AsText(geogrpahy)，将 geogrpahy 对象以 wkt 文本格式输出
  * ST_AsBinary(geography)，将 geography 对象以 wkb 文本格式输出 # 尚未正式支持，因为 Nebula 还未支持二进制字符串
- 转换函数
  * ST_Centroid(geography)，计算 geography 对象的重心，重心是一个 geography point 对象
- 谓词函数
  * ST_Intersects(geography_1, geography_2)，判断两个 geography 对象是否相交
  * ST_Covers(geography_1, geography_2)，判断第一个 geography 对象是否完全覆盖第二个
  * ST_CoveredBy(geography_1, geography_2)，ST_Covers 的反义词
  * ST_DWithin(geography_1, geography_2, distance_in_meters)，判断两个 geography 对象的最短距离是否小于给定距离
- 度量函数
  * ST_Distance(geography_1, geography_2)，计算两个 geography 对象之间的距离

这些函数接口遵循 OpenGIS Simple Feature Access 以及 ISO SQL/MM 标准，具体用法参见[Nebula 文档](https://docs.nebula-graph.com.cn/2.6.1/3.ngql-guide/6.functions-and-expressions/14.geo/)

### Geospatial index -- 地理空间索引

#### 什么是地理空间索引?

地理空间索引用于基于空间谓词函数的的地理形状的快速过滤，如：ST_Intersects、ST_Covers 等。

Nebula 使用[Google S2库](https://s2geometry.io/)做空间索引。 

S2 库将地球表面投影到一个外切的正方体上，然后对正方体的每一个正方形表面递归地进行 n 次四等，最后使用一条空间填充曲线--[希尔伯特曲线](https://en.wikipedia.org/wiki/Hilbert_curve)去连接这些小正方格子的中心。

当 n 无穷大时，这条希尔伯特曲线就几乎填满了正方形。

S2 库使用的是 30 阶的希尔伯特曲线。

[![oPuZvt.png](https://z3.ax1x.com/2021/11/24/oPuZvt.png)](https://imgtu.com/i/oPuZvt)

如下图, 是用希尔伯特曲线填充地地球表面的示意图：

[![oPuPED.png](https://z3.ax1x.com/2021/11/24/oPuPED.png)](https://imgtu.com/i/oPuPED)

可以看到，地球表面最终被这些希尔伯特曲线划分成了一个个单元格。对于地球表面的任意地理形状，比如一个城市、一条河流、一个人的位置我们都可以用若干个这样的格子去完全覆盖住这个地理形状。

每个格子都有一个唯一的 int64 的 CellID 来标识。因此，地理对象的空间索引就是构建完全覆盖该地理形状的 S2 格子的集合。

当构建地理空间对象的索引时，会构造一个完全覆盖被索引对象的不同 S2 单元格的集合。基于空间谓词函数的索引查询通过查找覆盖所查询对象的 S2 单元格的集合与覆盖被索引对象的 S2 单元格之间的交集，来快速过滤掉大量不相关的地理对象。

#### 创建 geography 索引

```
CREATE TAG any_shape_geo_index on any_shape(geo)
```
对于形状为 point 的地理数据，可以用一个 level 为 30 的 S2 单元格来表示它，因此一个 point 对应一个索引条目；对于形状为 linestring 和 polygon 的地理数据，我们使用多个不同 level 的 S2 单元格来覆盖，因此会对应多个索引条目；

空间索引会用来加速所有 geo 谓词的查找速度，比如对于如下语句

```
LOOKUP ON any_shape WHERE ST_Intersects(any_shape.geo, ST_GeogFromText("LINESTRING(3 8, 4.7 73.23)"));
```
当 any_shape 的 geo 列上没有空间索引时，该语句会先将 any_shape 的所有数据读到内存，然后用来计算是否和点(3.0, 8.0)相交，这个计算的开销一般是比较昂贵的。当 any_shape 的数据量较大时，计算开销将难以接受。

而当 any_shape 的 geo 列有空间索引时，该语句会首先用空间索引过滤掉绝大部分和该线绝对不相交的数据，最终读到内存的还是会有部分可能相交的，因此还需要进行一次计算。这样空间索引就以很小的代价快速过滤掉了大部分不可能相交的数据，最终进行精确过滤的只有少部分，极大的降低了计算开销。

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![关注公众号](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)


本文主要介绍了地理空间数据（Geospatial Data）以及它在 NebulaGraph 中的具体实践。一起来看看 NebulaGraph 是如何储存地理空间信息，将山川河流纳入 Nebula 之中的吧~

Geospatial Data 在 NebulaGraph 中的实践


![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning.webp)

# 前言

当我们使用 Nebula 图数据库执行查询语句，效率不如预期时候可能会有多种因素影响，可以分为两类，第一种是硬件资源受限，第二种是执行计划的问题（涉及到索引的选择、执行语句的优化等等），而本文着重讲述这两种情况下的性能问题排查。

# 硬件检查

本文测试环境最低硬件要求

- CPU 核数：4
- 硬盘：100GB SSD

硬件检查大体分为内存检查、磁盘 IO 检查、网络带宽检查和 CPU 检查。

## 内存检查

在执行查询语句时，在目标机上使用 `top` 命令查看 nebula-graph 进程和 nebula-stroage 进程的内存使用情况。

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-01.webp)

- 物理内存（RES）是实际占用的内存空间。
- 交换区（SWAP）是物理内存不足时，操作系统会把内存中不常用的页换出到磁盘空间，当被换出的页再次被访问时，再换入物理内存。
- 虚拟内存（VIRT）是物理内存 + 交换区，程序操作内存时操作的是虚拟内存中的地址，由操作系统再负责映射到物理内存或者交换区。

`free` 命令可以查看内存的整体状态：

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-02.webp)

- 缓存（buff/cache）是 Linux 会尽量提高内存使用率：把磁盘上的内容缓存到内存中，用来加速。当内存不足时，Linux 会释放缓存部分，给真正需要的进程使用。

内存不足有两个主要的指标可以判断

- 持续的内存换入换出
- 较多的主缺页中断
   - 主缺页中断是指在内存中找不到目标页，需要到磁盘中找，所以较多的主缺页中断意味着较多的磁盘访问，可以通过 `sar` 命令查看。

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-03.webp)

如上图所示，`pgpgin/pgpgout` 就是内存的换入换出；`majflt` 是主缺页中断。

## 磁盘 IO 检查

分析磁盘 IO 的工具很多，我们选择其中一个 `iostat` 命令, 可以同时监测 CPU 和磁盘 IO 的使用情况。

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-04.webp)

-  iowait 是 CPU 等待 IO 完成时间的百分比 ，若较高表明磁盘存在 IO 瓶颈
-  idle 是 CPU 空闲时间百分比，若较高则 CPU 比较空闲
- aqu-sz 是平均请求队列长度，越短越好
- util  是衡量 IO 的繁忙程度，值越大则 IO 请求较多，IO 压力较大，可以结合 idle 参数，若 idle < 70% 说明 IO 比较繁忙
- w_await 和 r_await 是衡量 IO 的读写响应速度，可以理解为 IO 响应时间
- svctm: 是平均每次 IO 服务时间，如果 svctm 和 await 很接近，表示几乎没有 IO 等待，磁盘性能很好，若 await 远高于 svctm，则 IO 队列等待太长，系统上运行的应用程序将变慢

通过上述指标可以判断瓶颈是否在 IO 排队上。

## 网络带宽检查

对数据密集型服务，网络带宽可能成为瓶颈。首先查看 服务器的网卡带宽配置，使用 ethtool  <网卡名>。  (一般第一块网卡命名为 eth0，第二块为 eth1)

- Speed: 1000Mb/s.  为千兆网卡
- Speed: 10000Mb/s 为万兆网卡

然后使用 dstat 工具，dstat 可以实时监控 CPU、磁盘、网络、IO、内存的使用情况，dstat 中统计网络的单位是 byte，将网络统计的结果乘 8 和网卡带宽对比，如果比较接近，说明网络在满负荷运行，可能会产生瓶颈。

## CPU 检查

使用 `top` 命令 查看 CPU 的运行指标。

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-05.webp)

- load average：任务队列的平均长度，三个数值分别是 1 分钟、5 分钟、15 分钟前的平均值，值越大说明当前系统负荷越大，3 个值除以逻辑 CPU 个数，若结果均大于 1，表明 CPU 过载
- us、sy：是用户空间和内核空间占用 CPU 百分比，若 us 大于 65%，sy 大于 35%，表明 CPU 有瓶颈

# 执行计划

除了上述检查，还可以在执行查询语句后，通过 profile 查询，profile 的使用参考文档：[https://docs.nebula-graph.com.cn/2.6.1/3.ngql-guide/17.query-tuning-statements/1.explain-and-profile/#_2](https://docs.nebula-graph.com.cn/2.6.1/3.ngql-guide/17.query-tuning-statements/1.explain-and-profile/#_2)

`profile` 可以查看 执行语句在 Nebula 中的详细执行计划，包括每个算子的执行时间。
其中和 storage 交互的算子主要有 `getNeightbor`、`getVertices`、`getEdge` 和 `indexScan`。下图为 getVertices 算子的详细情况：

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-07.webp)

- 其中 红框中 `totalTime` 是 `getVertices` 算子从发送请求到接收到结果总的耗时。
- 绿框中的 `total` 是 每一个 graph client 发送请求到接收结果的时间 (这个时间等于 storage 处理  + 数据序列化 + 网络传输)。
- 绿框中的 `exec` 是 每一个 storage 处理数据的时间。

在多分区场景下 ：

- 正常情况如果线程并发地执行，绿框中的每一个 `total` 时间和红框中的 totalTime 相差不大，像上图的情况表明线程在排队等待 CPU 执行，没有完全并发的跑，说明可能 CPU 有瓶颈。

同理，GetNeightbor 和 GetEdge 可以同样参考上述方式进行分析。
## 执行计划优化
近日在论坛中看到有用户发帖，为什么几乎相同的两条语句，一条 `LIMIT` 可以下推到 storage 中，另一条却无法下推到 storage 中，在此稍作解释。

目前 Nebula 中使用的是基于 RBO 的优化 [https://nebula-graph.com.cn/posts/nebula-graph-source-code-reading-04/](https://nebula-graph.com.cn/posts/nebula-graph-source-code-reading-04/)，优化阶段是基于已经写好的优化规则进行优化的，优化器并不能看到整体的执行计划，而是从根节点开始递归的遍历到叶子结点，然后再从叶子结点一个个和已经写好的规则进行匹配。如果当前遍历到的结点及其依赖结点和某一个规则匹配，则执行转换；否则继续，直到递归结束。

目前已有的规则参考源码：[https://github.com/vesoft-inc/nebula/tree/master/src/graph/optimizer/rule](https://github.com/vesoft-inc/nebula/tree/master/src/graph/optimizer/rule)

这里举一个例子方便理解，首先把 nebula-graph.conf 中 enable_optimizer 设置为 false，这时候执行计划是不经过优化器的。下面对比：

- GO FROM "tim" OVER like YIELD $^.[person.name](http://person.name/), like._dst | LIMIT 3 
- GO FROM "tim" OVER like YIELD $$.[person.name](http://person.name/), like._dst | LIMIT 3

这两条语句最原始的执行计划 `GO FROM "tim" OVER like YIELD $^.person.name, like._dst | LIMIT 3` 的执行计划如下：

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-07.webp)

在优化器中从根节点 `DataCollect` 出发遍历到 `Start` 节点，然后一个个匹配， 当遍历到 `LIMIT` 节点时，匹配到 `project→ limit` 规则， 执行转换将 `LIMIT` 放到 project 前面变为 `limit→project`，然后继续 `LIMIT` 节点匹配到 `getNeighbors→limit` 规则，将 `LIMIT` 下推到 `getNeighbor` 中，完成 `LIMIT` 下推。

`GO FROM "tim" OVER like YIELD $$.person.name, like._dst | LIMIT 3` 的执行计划如下：

![性能调优](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-performance-tuning-08.webp)

在优化器中从根节点 `DataCollect` 出发遍历到 `Start` 节点，然后一个个匹配， 当遍历到 `LIMIT` 节点时，匹配到 `project→ limit` 规则，执行转换将 `LIMIT` 放到 project 前面 变为 `limit→project`，但是不存在 `leftJoin→limit` 规则，因此无法将 `LIMIT` 继续下推。

因此虽然两条语句的 YIELD 子句只相差了一点，一个是取起始点属性，一个是取目的点属性，但是原始的执行计划却相差很大，造成优化后一个 LIMIT 下推，另一个却没有，造成性能问题。

## 索引的选择

索引是否命中对查询性能的影响也非常大，Nebula 的索引介绍请参考文章：[https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/](https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/)。

Nebula 中的索引分为唯一索引（索引列的值必须唯一）和联合索引（多个字段上建立的索引，能够加速复合查询条件的检索）。其中联合索引遵循最左前缀原则，即在检索数据时从联合索引的最左边开始匹配，目前nebula不支持跨tag或者edge 创建复合索引。

不能使用索引的条件有：
1、负向条件查询 例如 `WHERE` 条件中有 `!=`、`not in`
2、模糊查询 例如：`like '%XX'`

在 validate 阶段 会将 `MATCH` 语句中的 `WHERE` 条件和点和边属性过滤提取出来，然后在 optimizer 阶段会对提取出的条件进行分析：

1. 若过滤条件时候会在选择一个和当前 Schema 相同的索引中属性列最少的索引进行全表扫描，否则进入到 2；
1. 对当前条件进行分析, 目前仅支持单一的逻辑表达式，例如 where c1 > 1 and c2 < 2 and c3 == 1  或者 where c1 == 1 or c2 == 1 or c3 == 1，不支持复合的逻辑表达式，例如 where c1 > 1 and c2 > 1 or c3 > 1 或者 where c1 > 1 and c2 < 2 or c2 > 1 等等，当满足单一逻辑表达式后，进入到 3；
1. 索引选取的优先级时 等值查找 > 范围查找 ，其中索引中的列命中条件中的列数越多，优先级越高；

建议：
1、建联合索引的时候，区分度最高的字段在最左边
2、存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置

# Nebula 配置和使用指南

讲完硬件和执行计划，再来讲述下常见的 Nebula 使用性能瓶颈点，它们主要集中在配置以及使用操作方面。

## Nebula 配置

**storage.conf 配置**

- rocksdb_block_cache：数据在内存缓存大小，默认是 4MB，可以设置到当前内存的一半，这样在第二次查询的时候，可以优先在 RocksDB 的 cache 中查找数据；
- query_concurrently：true 时 storage 会并发地捞数据，false 时 storage 是单线程捞数据；
- rocksdb_column_family_options：在刚开始导入大量数据时可以将 `disable_auto_compaction` 选项设置为 true，提升写入的性能；

**graphd.conf 配置**

- system_memory_high_watermark_ratio：设置内存使用量超过多少时停止计算，以 1 作为单位一般设置为 0.8～1.0 之间。

## 执行语句前的操作

**Compaction**

当导入完数据之后需要执行。

- 打开 nebula-console 连接到图空间，然后执行 `SUBMIT JOB COMPACT;`
- 通过 `SHOW JOBS` 查看 compact 是否执行完毕。

compaction可以消除重复的数据，去掉无用的数据，将 sst 文件合并，进而减少 sst 占用的磁盘空间，提高读的性能。

**Balance leader**

- 打开 nebula-console 连接到图空间，然后执行 `BALANCE LEADER`
- 通过 `SHOW HOSTS` 查看 leader 是否均匀分布。

Balance 可以让 storage 服务实现负载均衡，避免出现热点现象。

以上为本次分享。

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![关注公众号](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)


一份经过多家企业验证过的性能排查和调优小秘籍

Nebula 性能问题排查和性能调优

美团内部在骑手社交网络、金融反欺诈、设备风险识别等诸多场景下也有使用图计算的迫切需求。经过广泛的调研后，美团技术团队列举一些有代表性的图计算框架，并对当中的 GraphX、Giraph、Plato 3 个框架进行测试……

标签