近年来，GraphRAG 已成为企业 AI 落地的重要技术方向。相比传统 RAG，GraphRAG 通过知识图谱组织实体与关系，为大模型提供更加完整的上下文和推理能力，在复杂问答、多跳推理、企业知识管理等场景展现出显著优势。

近日， LightRAG 合并了社区 PR #3536，正式新增 NebulaGraph 作为官方支持的图数据库存储后端。这意味着开发者可以直接使用 NebulaGraph 构建 LightRAG 的知识图谱存储与查询能力，为 GraphRAG 应用提供更高性能、更大规模的图数据支撑。

> 目前 NebulaGraph 开源版的最新版本为 v3.8.0，v5.x 为企业版，其核心特性之一是原生支持 GQL（Graph Query Language）国际标准。因此，本次集成主要面向部署了企业版 v5.0 的用户，帮助他们充分发挥 LightRAG 与企业版新特性结合的能力。

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/lightgraph/light-pr.png)

# 为什么是 NebulaGraph？

LightRAG 的核心思想，是利用知识图谱增强传统向量检索，通过实体、关系以及图结构组织知识，实现局部（Low-Level）与全局（High-Level）双层检索，从而提升复杂问题的回答质量。

随着企业知识规模不断增长，GraphRAG 对底层图数据库提出了更高要求：

* 海量节点与关系的存储能力
* 高并发、多跳关联查询性能
* 在线增量更新能力
* 面向生产环境的分布式架构

NebulaGraph 正是为这些企业级场景而设计。作为分布式图数据库，NebulaGraph 能够支持超大规模关系数据管理，并在复杂图遍历、多跳查询和实时图计算场景中保持稳定性能，因此成为越来越多企业构建知识图谱和 GraphRAG 系统的重要基础设施。

# 为 LightRAG 提供企业级图能力

LightRAG 是一套强调“轻、快、可组合”的 GraphRAG 系统，通过引入知识图谱来增强大语言模型对复杂关联知识的检索与生成能力。

此前，LightRAG 已支持 Neo4j、Memgraph 等多种图数据库。此次集成，将 NebulaGraph 的强大数据处理能力与 LightRAG 的智能检索框架相结合，为处理千亿级节点和边的知识图谱 RAG 应用提供了坚实底座。

这对构建企业 AI 应用而言，这意味着开发者既可以依托 NebulaGraph 获得生产级图数据管理能力，也可以享受 LightRAG 在知识抽取与双层检索方面的能力。

# 特别致谢

**在此，我们特别感谢此次集成的代码贡献者 @xlshao2021**。正是 ta 敏锐地捕捉到了广大用户对 NebulaGraph 支持的真实需求，并投入时间和精力，从代码实现到测试，完整地完成了这一关键开发工作。

这一贡献不仅直接丰富了 LightRAG 的存储后端生态，也展现了一个优秀开源社区应有的活力——用户提出需求，贡献者付诸行动，核心维护者以建设性的方式响应。

我们期待 @xlshao2021 和所有对 `dev-nebula-graph `分支感兴趣的开发者，能继续维护和更新这一集成，共同推动它在更多企业级场景中落地生根。

---
如果你正在构建企业知识库、GraphRAG 或 AI Agent 应用，现在可以使用 NebulaGraph 作为 LightRAG 的图数据库后端，体验图原生架构带来的性能与扩展能力。

欢迎加入 NebulaGraph 社区，与更多开发者一起探索 GraphRAG、Ontology 与 Agent 的下一代企业 AI 架构。
``

 LightRAG 合并了社区 PR #3536，正式新增 NebulaGraph 作为官方支持的图数据库存储后端。

LightRAG 现已支持 NebulaGraph，推动 GraphRAG 生态发展

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/tip.png)

你有没有过这样的经历？刚下载一个社交 App，它就给你推荐了多年未见的老同学，或是隔壁部门可能有过一面之缘的同事。你心里不禁犯嘀咕：“它怎么知道的？”

其实，这背后很可能是**图数据库**在默默工作。它把整个社交平台制造成一张巨大的**关系网**，通过分析这张网里错综复杂的连接，来做出更懂你的推荐。

今天，NebulaGraph 就通过一个简单的 Demo，带你一窥这位“关系大师”是怎么工作的。

> Demo 链接
> https://www.nebula-graph.com.cn/demo
> 欢迎在 NebulaGraph 官网体验多场景 Demo，亲自动手验证图数据库的能力～

## 一、图模型设计

> 💡在实际使用中，可对 Schema 进行相应修改与管理，为便于在线体验，本 Demo 暂不支持。
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/1.png)

在正式推理开始前，我们得先知道上文提到的关系网是怎么搭起来的。

你可以把这张网想象成三个简单的部分：

* **人（节点）**：代表每个用户。
* **关系（边）**：“好友”、“关注”、“点赞”、“评论”这些让每个用户之间，产生关系的互动行为。
* **内容/社群/Tag（节点）**：比如一篇“旅游攻略”，或者一个“篮球爱好者群”。

> 💡在真实的业务里， 社群通常可以作为用户的一个属性来存储。但在我们这个演示里，特意将其单独建模成了一个节点。这是为了让你更直观地看清“用户 – 社群 – 内容”这条完整链条，感受图数据库在多跳关系查询上的优势。实际生产环境里，完全可以根据业务需求灵活调整模型。

图数据库要做的，就是把它们之间千丝万缕的联系，全部存进去，并且让这些关系可以被随时查询和分析。

节点类型包括下表：

| 节点类型 | 标签 | 核心属性 |
| :--- | :--- | :--- |
| 用户（自然人） | `Person` | `person_id` (唯一标识), `name` (昵称/姓名), `city` (所在城市), `register_time` (注册时间) |
| 社区/圈子 | `Community` | `community_id` (唯一标识), `name` (社区名称), `topic` (主题分类), `created_time` (创建时间) |
| 内容/帖子 | `Content` | `content_id` (唯一标识), `title` (标题), `category` (内容分类), `publish_time` (发布时间) |
| 用户兴趣标签 | `UserTag` | `tag_name` (标签名，如“AI”、“旅行”) |

边类型包括下表：

| 边类型 | 起始节点 → 目标节点 | 说明 |
| :--- | :--- | :--- |
| `Friend` | `Person` → `Person` | 好友关系（双向社交） |
| `FollowKOL` | `Person` → `Person` | 关注 KOL/大V（单向社交） |
| `MemberOf` | `Person` → `Community` | 加入社区/群组 |
| `Forward` | `Person` → `Content` | 转发/分享内容 |
| `Like` | `Person` → `Content` | 点赞/喜欢内容 |
| `Comment` | `Person` → `Content` | 评论内容 |
| `HasInterest` | `Person` → `UserTag` | 用户兴趣标签 |
| `Cites` | `Content` → `Content` | 内容引用/关联 |

了解完图数据库要做什么后，我们首先要在图数据库中，把基本规则创建起来。

首先，创建图类型与图空间，并执行以下语句定义节点、边结构及属性：


```
CREATE GRAPH TYPE IF NOT EXISTS `social_recommendation` AS {
NODE TYPE `Person` (LABEL `Person`{`person_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `city` STRING DEFAULT NULL, `register_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`person_id`)}),
NODE TYPE `Community` (LABEL `Community`{`community_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `topic` STRING DEFAULT NULL, `created_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`community_id`)}),
NODE TYPE `Content` (LABEL `Content`{`content_id` STRING NOT NULL, `title` STRING DEFAULT NULL, `category` STRING DEFAULT NULL, `publish_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`content_id`)}),
NODE TYPE `UserTag` (LABEL `UserTag`{`tag_name` STRING NOT NULL, PRIMARY KEY (`tag_name`)}),
EDGE TYPE `Friend` (`Person`)-[LABEL `Friend`{`since_time` ZONED DATETIME NOT NULL, `closeness` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`since_time`)}]->(`Person`),
EDGE TYPE `MemberOf` (`Person`)-[LABEL `MemberOf`{`join_time` ZONED DATETIME NOT NULL, `role_name` STRING DEFAULT NULL, MULTIEDGE KEY(`join_time`)}]->(`Community`),
EDGE TYPE `Forward` (`Person`)-[LABEL `Forward`{`forward_time` ZONED DATETIME NOT NULL, `action_weight` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`forward_time`)}]->(`Content`),
EDGE TYPE `Like` (`Person`)-[LABEL `Like`{`like_time` ZONED DATETIME NOT NULL, `score` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`like_time`)}]->(`Content`),
EDGE TYPE `Comment` (`Person`)-[LABEL `Comment`{`comment_time` ZONED DATETIME NOT NULL, `content_text` STRING DEFAULT NULL, MULTIEDGE KEY(`comment_time`)}]->(`Content`),
EDGE TYPE `FollowKOL` (`Person`)-[LABEL `FollowKOL`{`follow_time` ZONED DATETIME NOT NULL, `interaction_level` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`follow_time`)}]->(`Person`),
EDGE TYPE `HasInterest` (`Person`)-[LABEL `HasInterest`{`weight` DOUBLE DEFAULT NULL}]->(`UserTag`),
EDGE TYPE `Cites` (`Content`)-[LABEL `Cites`{`cite_time` ZONED DATETIME DEFAULT NULL}]->(`Content`)
};
CREATE GRAPH `social_recommendation` :: `social_recommendation`;
```

## 二、数据导入

> 💡本 Demo 仅预置 30 名用户及数千条社交关系，实际导入时，数据量可达千亿级甚至更多。

定义完“规则”，我们执行以下语句，导入数据。


```
-- 导入用户节点
TABLE `person_data` { `person_id`, `name`, `city`, `register_time` } =
("p001", "Alice", "Beijing", "2024-01-05T09:00:00 +0800"), ("p002", "Bob", "Beijing", "2024-01-06T10:30:00 +0800"), ("p003", "Charlie", "Beijing", "2024-01-07T11:00:00 +0800"), ("p004", "David", "Beijing", "2024-01-08T14:20:00 +0800"), ("p005", "Evan", "Beijing", "2024-01-09T15:00:00 +0800"), ("p006", "Fiona", "Beijing", "2024-01-10T16:45:00 +0800"), ("p007", "George", "Beijing", "2024-01-11T09:15:00 +0800"), ("p008", "Hannah", "Beijing", "2024-01-12T10:30:00 +0800"), ("p009", "Ivan", "Beijing", "2024-01-13T11:45:00 +0800"), ("p010", "Julia", "Beijing", "2024-01-14T13:00:00 +0800"),
("p011", "Kevin", "Shanghai", "2024-01-15T09:00:00 +0800"), ("p012", "Linda", "Shanghai", "2024-01-16T10:30:00 +0800"), ("p013", "Mike", "Shanghai", "2024-01-17T11:00:00 +0800"), ("p014", "Nancy", "Shanghai", "2024-01-18T14:20:00 +0800"), ("p015", "Oscar", "Shanghai", "2024-01-19T15:00:00 +0800"), ("p016", "Paula", "Shanghai", "2024-01-20T16:45:00 +0800"), ("p017", "Quinn", "Shanghai", "2024-01-21T09:15:00 +0800"), ("p018", "Rachel", "Shanghai", "2024-01-22T10:30:00 +0800"), ("p019", "Steve", "Shanghai", "2024-01-23T11:45:00 +0800"), ("p020", "Tina", "Shanghai", "2024-01-24T13:00:00 +0800"),
("p021", "Uma", "Hangzhou", "2024-01-25T09:00:00 +0800"), ("p022", "Victor", "Hangzhou", "2024-01-26T10:30:00 +0800"), ("p023", "Wendy", "Hangzhou", "2024-01-27T11:00:00 +0800"), ("p024", "Xavier", "Hangzhou", "2024-01-28T14:20:00 +0800"), ("p025", "Yvonne", "Hangzhou", "2024-01-29T15:00:00 +0800"), ("p026", "Zack", "Hangzhou", "2024-01-30T16:45:00 +0800"), ("p027", "Amy", "Hangzhou", "2024-01-31T09:15:00 +0800"), ("p028", "Brian", "Hangzhou", "2024-02-01T10:30:00 +0800"), ("p029", "Cathy", "Hangzhou", "2024-02-02T11:45:00 +0800"), ("p030", "Derek", "Hangzhou", "2024-02-03T13:00:00 +0800")
USE `social_recommendation`
FOR re IN `person_data`
INSERT (@`Person` {`person_id`: re.`person_id`, `name`: re.`name`, `city`: re.`city`, `register_time`: CAST(re.`register_time` AS ZONED DATETIME)})
-- 导入社群节点
TABLE `community_data` { `community_id`, `name`, `topic`, `created_time` } =
("c001", "AI与大模型研究", "Technology", "2023-12-01T08:00:00 +0800"), ("c002", "电商运营交流", "Business", "2023-12-05T09:00:00 +0800"), ("c003", "硬核数码科技", "Hardware", "2023-12-10T10:00:00 +0800"), ("c004", "城市慢生活", "Lifestyle", "2023-12-15T11:00:00 +0800")
USE `social_recommendation`
FOR re IN `community_data`
INSERT (@`Community` {`community_id`: re.`community_id`, `name`: re.`name`, `topic`: re.`topic`, `created_time`: CAST(re.`created_time` AS ZONED DATETIME)})
-- 导入内容节点
TABLE `content_data` { `content_id`, `title`, `category`, `publish_time` } =
("ct001", "图数据库在AI时代的机遇", "Tech", "2024-03-01T08:00:00 +0800"), ("ct002", "2024电商新风向标", "Business", "2024-03-02T09:00:00 +0800"), ("ct003", "深度解析PageRank算法", "Tech", "2024-03-03T10:00:00 +0800"), ("ct004", "我的极简桌面搭配", "Life", "2024-03-04T11:00:00 +0800"), ("ct005", "机械键盘轴体科普", "Hardware", "2024-03-05T12:00:00 +0800"),
("ct006", "LLM微调实战指南", "Tech", "2024-03-06T13:00:00 +0800"), ("ct007", "直播带货的底层逻辑", "Business", "2024-03-07T14:00:00 +0800"), ("ct008", "周末探店：魔都咖啡", "Life", "2024-03-08T15:00:00 +0800"), ("ct009", "显卡选购避坑指南", "Hardware", "2024-03-09T16:00:00 +0800"), ("ct010", "如何高效管理时间", "Life", "2024-03-10T17:00:00 +0800")
USE `social_recommendation`
FOR re IN `content_data`
INSERT (@`Content` {`content_id`: re.`content_id`, `title`: re.`title`, `category`: re.`category`, `publish_time`: CAST(re.`publish_time` AS ZONED DATETIME)})
```

数据导入完成后，社交数据在图数据库里就变成了这样一张图（Graph）。
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/2.png)

## 三、关键查询示例

在 NebulaGraph Demo 的 console 界面中，输入图数据库查询语句，点击 run 按钮，系统就会执行一段查询指令，并把结果以**可视化关系图**的形式呈现出来。

比如每个用户是一个小圆点，关系是连接圆点的线条。你可以拖拽、缩放这张图，直观地看到人与人之间的连接路径，让推荐结果看得见、摸得着。

在这里，我们用四类查询语句和对应的可视化页面，进一步让你了解图数据库是如何让社交软件，精准推荐「你可能认识的人」。

> 💡在 Demo 中，已经完成了 schema 设计和数据导入，大家可以在 console 页面，任意探索社交场景的不同语句、玩法。

### 1. 查找某人的 1-3 度好友

**目的：**全面掌握目标用户的社交网络范围，发现潜在的兴趣传播路径和社群影响力范围。


```
USE `social_recommendation`
MATCH p=(src@`Person` {`person_id`: "p001"})-[:`Friend`]-{1,3}(friend)
RETURN p
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/3.png)

**基于图的解释**：该图展示了从用户 p001 出发，经过 1 到 3 跳好友关系能到达的所有用户节点及路径。

### 2. 熟人好友推荐

**目的**：基于“朋友的朋友是朋友”的社交理论，通过共同好友数量为用户推荐可能认识的人。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p001"})-[:`Friend`]-(mutual_friend)-[:`Friend`]-(candidate)
WHERE candidate.`person_id` <> "p001" // 排除自己
AND NOT EXISTS((src)-[:`Friend`]-(candidate)) // 排除已经是好友的人
RETURN candidate.`person_id` AS recommended_friend,
candidate.`name` AS name,
count(mutual_friend) AS mutual_friends_count
ORDER BY mutual_friends_count DESC
LIMIT 10
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/4.png)

**基于表格的解释**：为用户 p001 推荐共同好友最多的前 10 位潜在朋友。`mutual_friends_count `越高，推荐的理由越充分，用户接受推荐的概率越大。

### 3. 兴趣社群推荐 (基于朋友圈子)

**目的**：通过分析用户好友的社群加入行为，推测用户可能也感兴趣的社群，实现社群推荐。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p001"})-[:`Friend`]-(friend)-[:`MemberOf`]-(community)
WHERE NOT EXISTS((src)-[:`MemberOf`]-(community))
RETURN community.`name` AS community_name,
community.`topic` AS topic,
count(friend) AS friends_joined_count
ORDER BY friends_joined_count DESC
LIMIT 5
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/5.png)

**基于表格的解释**：为用户 p001 推荐其好友们最常加入的 5 个社群。`friends_joined_count `越高，说明该社群在当前用户的社交圈子中越流行，推荐价值越高。

### 4. 基于相似行为的内容推荐

**目的**：找到与目标用户有相同转发行为的相似用户，然后将这些相似用户点赞过的其他内容推荐给目标用户，实现协同过滤推荐。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p002"})-[:`Forward`]->(common_content)<-[:`Forward`]-(similar_user)-[:`Like`]->(recommended_content)
WHERE NOT EXISTS((src)-[:`Like`]->(recommended_content))
AND NOT EXISTS((src)-[:`Forward`]->(recommended_content))
RETURN recommended_content.`title` AS content_title,
similar_user.`name` AS liked_by_user,
count(common_content) AS similarity_score
ORDER BY similarity_score DESC
LIMIT 10
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/6.png)

**基于表格的解释**：为用户 p002 推荐由与其转发行为最相似的 10 位用户所喜欢的内容。`similarity_score `代表推荐内容与用户兴趣的相似度权重，`liked_by_user `字段提供了推荐理由。

## 四、总结

综上所述，图数据库的核心理念其实并不复杂，其实就是将“人与人”、“人与内容”之间的关系作为一等公民进行存储与计算。然而，正是这一思路的转变，为推荐系统带来了质的变化。

回顾前文所述的所有查询示例，可以清晰地看到，借助 NebulaGraph 构建的社交兴趣关联网络，推荐系统在以下四个维度上实现了显著提升：

**1. 发现多层社交路径**：突破传统推荐系统局限于个体历史行为的视野，图数据库可沿好友、关注等链路穿透至三度、四度关系，挖掘深层社交联系与影响力传导路径。

**2. 提供可量化指标**：基于共同好友数、相似行为频次等结构化数据，为每条推荐提供可量化的信任度依据，如“你们有8位共同好友”，让推荐结果有据可循。

**3. 统一查询模式**：熟人推荐、社群推荐、协同过滤等多样化策略，均可通过图数据库的统一查询语言实现，无需为每种逻辑单独搭建技术栈，显著降低开发复杂度。

**4. 天然路径回溯**：图数据库可清晰展示推荐结果的完整产生链路（如“A的好友B点赞了C，故推荐C给A”），为策略优化与用户沟通提供透明化支撑。

总而言之，图数据库以一种更贴近人类认知直觉的方式，将世界视作一张相互连接的网络，正是这一视角的转换，使社交推荐从“猜你喜欢”进化为“基于关系的精准匹配”。如果您的产品正面临社交推荐的效率瓶颈，不妨从绘制一张关系图谱开始探索新的可能。

> 💡本 Demo 展示了基础查询，仅作为简单场景下的 NebulaGraph 使用参考。在实际生产环境中，还可结合 PageRank、标签传播、连通分量等图算法，实现更智能的社区发现与兴趣扩散。

✦

如果你觉得 NebulaGraph 能帮到你，或者你只是单纯支持开源精神，可以在 GitHub 上为 NebulaGraph 点个 Star！

每一个 Star 都是对我们的支持和鼓励✨

**GitHub：https://github.com/vesoft-inc/nebula**

官网：https://www.nebula-graph.com.cn/

论坛：https://discuss.nebula-graph.com.cn/

✦

图数据库在社交推荐的应用教程

Demo｜图数据库如何让社交软件精准推荐「你可能认识的人」？

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

---

很多技术团队都走过同样的路：先选一个大模型，然后把公司里的文档、手册、报告塞进向量数据库，再搭一个 RAG 问答系统。原型跑起来那天的感觉特别好，问什么答什么，反应快，看起来像模像样。

但系统真正投入业务之后，问题就来了。

一旦问题变得复杂，系统就开始答非所问。有时候它给出的答案看起来头头是道，但细查来源，发现推理过程根本站不住脚。

团队换过更贵的模型，效果有改善，但一到复杂问题就崩的现象，始终没有根除。

后来大家慢慢意识到：问题可能不在模型本身，而在于知识被喂给模型之前的那一步——检索。

# 一、传统 RAG 正在把企业知识切碎

RAG（检索增强生成）是目前企业用大模型的普遍做法。用户提问，系统先从知识库找出相关文字，连问题一起丢给大模型，让模型根据这些文字回答。

传统 RAG 依赖向量检索，做法是：

* 把每篇文档切成文本块（chunk），比如每块 500 字
* 把每个块转化成高维向量
* 用户提问时，把问题也转化成向量，去库里找语义最相似的块

对一般场景中的简单问答，这个方法有效。

但企业里的真实问题，极少是这种点对点查询。因为企业知识的核心是关系。

* 归因关系：如设备故障手册里的故障现象和根本原因
* 传导关系：如产业链分析报告的上游价格和下游需求
* 前后依赖关系：如 SOP 流程文档的不同步骤
* 层级关系：如产品手册的零部件和子系统

**而传统 RAG 的第一步：切文本块，恰恰把这些关系切断了。**

> “客户 A 为什么被判定为高风险？”

背后可能涉及：用户 → 设备 → IP → 联系人 → 黑名单账户 → 历史交易 → 欺诈团伙，这不是一个文本块能回答的问题。

> “某设备关联过哪些异常账号，这些账号之间有没有共同联系人？”

这里需要的是关系推理、多跳遍历、结构化关联，而不是语义相似。

使用传统 RAG，非常可能出现以下几大问题[1]。

## （一）关系缺失

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/1.webp)

文档之间天然存在引用、衍生、对立等复杂关系，向量数据库将文档切分为孤立的片段后，数据的关联随之减弱。

一个因果链条可能跨越三个段落，被切成三个独立文本块后，关系被破坏。一个产品特性可能分散在不同章节，被切碎后，模型再也看不到完整画像。

## （二）语义鸿沟

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/2.webp)

语义相似度 ≠ 上下文相关性 。举个相似但不相关的例子，保温杯与保温大棚，两者在转换成 Embedding 后的向量相似性很高，因为它们在很大比例上共享“保温”这一语义特征。但在一些场景下，想要了解保温杯却召回了保温大棚的信息。一个是喝水的，一个是用于农业种植的，完全不相关。

RAG 在索引阶段即使设置了比较高置信度，也很可能因为其相似性而得到不相关的信息。

## （三）全局推理乏力

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/3.webp)

"所有文档的核心观点是什么？"、"政策中最重要的五点信息是什么？"。这类需要跨文档综合分析、提炼的全局性、社区级问题，恰恰是向量检索的局限之处。

# 二、企业知识天然就是一张图

有没有一种方式，能**完整保留知识之间的关联**？

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/4.webp)

**答案是图数据库（Graph Database）。图数据库由节点和边构成。节点代表事物，边代表关系，每个节点和边都可以定义其属性。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/5.webp)

事实上，NebulaGraph 在微软之前就率先提出了 GraphRAG[2]，而且微软在论文中也引用了我们的 GraphRAG 相关工作[3]。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/6.webp)

NebulaGraph 是分布式开源图数据库，主要面向大规模、高性能的应用场景，支持千亿点、万亿边的超大规模数据集。目前，在 DB-Engines 的图数据库排行榜上，我们排名全球第二[4]。

**企业知识本质上就是一张巨大的图**，只是平时藏在文档、表格、邮件里，没有被显式表达出来。

产业研报，变成图：

节点：上游企业、中游厂商、下游需求、价格指标、产能数据
边：上游→中游（供应关系）、中游→下游（需求关系）、价格→产能（影响关系）

设备维护手册，变成图：

节点：设备型号、故障现象、可能原因、检测方法、解决措施
边：现象→可能原因、原因→检测方法、方法→解决措施

这些关系一旦被显式构建出来，企业知识就不再是散乱的文本，而是一个**可以被系统遍历和推理的网络**。这就是 GraphRAG 最简单的出发点。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/7.webp)

GraphRAG 不是简单地给 RAG 加一个图数据库。它的本质是抽取文档中的实体和它们之间的关系，让大模型在关系网络上做路径探索和逻辑推理，而不是在碎片里做相似匹配。

# 三、GraphRAG：从“找相似的”到“找相关的”

图技术如何解决传统 RAG 的三大挑战？

## （一）解决文档切分难题

向量数据库的第一步是切文本块。

图模型提供了完全不同的思路。文档、章节、段落可以作为具有丰富属性的节点存在，并通过边明确表达其间的层级关系和引用关系。语义被结构性地保留下来，不需要靠“切”来牺牲完整性。

## （二）重建上下文关联

一个多级部门文档体系，在向量数据库中，这些文档被切成文本块后是“平权”的——一级和三级的内容混在一起，无法保留层级、来源和引用关系。

在图数据库中，可以清晰地建模“发布”“引用”“归属”等关系。一篇三级报告引用了一级纲领的某条原则，这个关系可以被显式记录下来。当用户问“这份报告的合规依据是什么”，系统可以沿着引用边一路回溯到纲领原文，形成可追溯、可解释的知识链条。

## （三）解锁复杂推理能力

对于关联类问题。图数据库可以通过子图搜索、路径查询轻松找出两个节点之间的连接路径，即使这条路径跨越了多个中间节点。

对于总结推理类问题，图数据库可以利用社区发现、中心性分析等图算法，识别出知识网络中最关键、最聚合的信息群，而不是像向量检索那样简单返回相似度最高的几个段落。

##  （四）小结

保留结构、重建关联、支持推理，这三大核心能力正是 GraphRAG 区别于传统 RAG 的本质所在。并且结果更精确，更重要的是每一步推理路径都可以完整展示给用户。

# 四、Fusion GraphRAG：**NebulaGraph 的自我超越**

## （一）Fusion Graph Index（融合图索引）

技术不会止步。随着企业数据越来越复杂——PDF、Excel、PPT、图片、时序数据混在一起，GraphRAG 遇到了新挑战：**如何在一个系统里同时处理文档结构、实体关系、语义相似性？**

**为此，NebulaGraph 提出了原创的 Fusion GraphRAG 架构。**

Fusion GraphRAG 在知识图谱之上，创新地增加了一层 **Fusion Graph Index（融合图索引）**，将非结构化文档解析为层次化目录树结构：文档 → 章节 → 段落 → 文本块 → 图表。

这种树状结构直接置于 LLM 的推理上下文中，成为它可以主动遍历和推理的上下文内索引。

也就是说，Fusion GraphRAG 让文档的层次化结构本身即可作为可推理的索引，让 LLM 根据问题意图动态决定“去哪里找”，而非静态匹配“什么看起来像”，给 LLM 装上了智能导航。

这种能力的本质，是**让检索从静态匹配，开始进入动态结构推理阶段。**

## （二）四大索引能力

因此，在 Fusion GraphRAG 中，实际上**存在四类核心索引能力：**

* 图索引负责实体关系与多跳路径推理；
* 向量索引负责语义相似召回；
* 全文索引负责关键词精准匹配；
* 融合图索引则负责文档结构导航与上下文推理。

四种索引能力各司其职，又动态协同。

* 简单 FAQ 场景下，向量检索可以快速返回结果；
* 复杂关系分析则更多依赖图路径推理；
* 专业术语与法规查询适合全文检索；
* 长文档、多章节、跨引用场景，则由融合图索引主导结构导航。

这一设计带来了显著的效率提升：

* 相比使用大模型抽取知识图谱，索引构建速度提升约 10 倍；
* 在与微软 GraphRAG 的对比中，索引阶段更是快了近 20 倍，同时问答准确率更高。

# 五、NebulaGraph AI 应用平台

Fusion GraphRAG 是技术方案。企业需要的是**可以直接用的产品**。

NebulaGraph AI 应用平台正是基于 Fusion GraphRAG、以 NebulaGraph 图数据库为引擎的完整产品。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/8.webp)

## （一）核心能力

* **零代码搭建智能助手**：通过可视化界面导入知识资产、配置检索策略，不用写代码
* **自然语言直接转换图查询语言**：业务人员能够自主构建算法，无需依赖研发团队，快速将业务规则落地图分析中
* **多类型索引统一存储**：将向量、全文、图和融合图索引建立在一个平台内，系统自动选择最优索引策略
* **多模态解析**：PPT、Word、Excel、PDF、图片可快速解析。
* **企业级权限隔离**：不同部门知识集相互隔离，可按区域、产品线做二级隔离
* **模型无关**：底层大模型可随时更换，支持 GPT、通义、 DeepSeek、 GLM 等大模型。

## （二）生态完整

我们构建了完整的 AI 应用开发生态：

* **Nebula AI Application SDK**：为开发者提供灵活调用的工具包。
* **Nebula AI 应用平台**：零代码开箱即用的端到端平台，用户只需选择知识库，即可创建专属 AI 应用。


# #（三）场景多元

**目前，NebulaGraph AI 应用平台已在以下场景中通过实际业务检验。**

* 金融与数据分析：财报分析与跨文档校对、历史交易文档查询对比、产业链AI研究（如黑色系）；
* 工业与智能制造：故障树处理与排故引导、工业决策辅助；
* 法律合规与合规：法律法规条款查询、合同合规性审核；
* 企业通用智能助手：钉钉/企微机器人问答、网站 AI 搜索、业务流程入库与图查询、新零售企业内部智能助手（员工培训/文档查找/销售数据分析/多国法务合规等）。

## （四）正确率显著提高

在开源 KG-RAG 评测集（专门测试多跳推理，问题平均需要2-4跳）上，**召回率和回答正确率比 SOTA 高出 10% 以上。**

在金融类法律法规的真实企业场景中，人工评分正确率达 95%。

# 六、用户案例

## （一）中国船舶集团第七O八研究所：故障树处理与引导排故

**1. 挑战**

客户有大量的非结构化文档， 文档内有故障树描述（树状描述， 或者文字描述）、

引导排查故障的方法（维修记录等），且涉及高端船舶制造，产品设计及排障流程复杂。

**2. 成效**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/9.webp)

故障平均排查时间大幅缩短。同时，每次成功排故后，工程师的查询路径被系统记录下来，数千个故障场景的推理路径沉淀为企业可复用的数字资产。新工程师遇到类似问题时，系统可以直接推荐历史成功路径。

这是行业首个船舶生成式人工智能驱动的实际应用场景通过实现图驱动的检索增强智能体，优化了信息检索的准确性和速度，提高了系统的灵活性和适应性。

## （二）某期货企业：产业链 AI 研究助手

**1. 挑战**

某期货企业的研究员每天要跟踪黑色系产业链。上游焦煤、焦炭、铁矿石的价格和库存，影响中游钢厂的产能决策，再传导到下游建筑、制造、出口的需求。研究员同时盯着十几个数据源，外加大量历史研报和实时资讯，导致一份日报需要耗时 4-6h。

**2. 成效**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/10.png)

显著减少人工分析时间，单份日评制作时间降低至 30min 以内，自动化生成专业、及时、准确的黑色系期货日评报告。

# 七、重新定义 AI 如何理解知识

回到开头的困惑，为什么接了模型、建了向量库，复杂问题还是答不好？答案已经清晰了。

你给大模型看的，是被切碎的、断了关系的文字碎片，却指望它能理解那些依赖复杂关系才能回答的问题。

传统 RAG、GraphRAG 与 Fusion GraphRAG 代表了检索增强生成技术从简单语义匹配，到全局结构理解，再到动态推理导航的演进路径。

在这条路上，NebulaGraph 从未缺席。从率先提出 GraphRAG 方案，到推出原创的 Fusion GraphRAG 架构，再到今天的 NebulaGraph AI 应用平台，我们一直在做同一件事：**重新定义 AI 如何理解知识。**

> **填写[咨询问卷](https://wj.qq.com/s2/15344088/w7ei/)，与我们取得联系**

---

✨💡 NebulaGraph AI 应用平台为企业版产品

引用

[1]RAPTOR- RECURSIVE ABSTRACTIVE PROCESSING FOR TREE-ORGANIZED RETRIEVAL， arXiv:2401.18059

[2][Graph RAG: 知识图谱结合 LLM 的检索增强.](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515631&idx=1&sn=5215688c309d84c428b6b770e7c0dfc1&scene=21#wechat_redirect)

[3]From Local to Global: A Graph RAG Approach to Query-Focused Summarization, arXiv:2404.16130

[4][NebulaGraph 全球图数据库排名第二.](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21#wechat_redirect)

NebulaGraph 如何用 Fusion GraphRAG 重新定义企业知识检索

NebulaGraph AI 应用平台：四种索引融合，重新定义 AI 如何理解知识

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

---
2025 年全球图数据库市场规模为 28.5 亿美元，预计将从 2026 年的 36 亿美元增长到 2034 年的 202.9 亿美元。无论是风控、推荐，还是知识图谱，许多公司早已拥有一套图系统，数据动辄几十亿节点、上百亿关系，甚至更大。

但一个很少被公开讲出来的现实是，**大多数公司的图，其实“算不动”。**

经典的图算法，如 PageRank、社区发现、最短路径，已被广泛应用于生产环境。问题在于，当关系规模真的上来之后，这些算法开始变得不再工程可行，耗时太慢，或者不敢跑全量。

**企业真正需要的，已经从把海量关系存下来，转向在海量关系上做计算**。并且这个过程不应该再依赖研发和产品层层转译，而是让业务人员自己能制定规则，直接落地更智能、更贴近业务逻辑的分析，同时能够快速构建图算法，把效率真正提上来。

NebulaGraph Analytics，正是在这个背景下出现的。

## 一、在超大规模图上直接运行复杂算法

NebulaGraph Analytics 切入的核心，是让用户在超大规模图上灵活自定义复杂算法。

这是一款深度运行复杂图算法的图分析平台，相较于 Apache Spark GraphX **资源消耗降低至约 20%，计算性能提升约 5–10 倍**，帮助用户高效洞察潜在的结构与模式。

其核心价值在于开放而灵活的自定义算法能力——用户不仅可以调整参数适配数据特征，更能基于业务需求编写专属算法。

为什么自定义图算法如此关键？

* **通用算法难以直接落地**：绝大多数标准图算法无法直接解决业务问题，需要根据具体场景微调模型、参数甚至算法逻辑。

* **业务规则需自主可控**：风控等场景涉及核心业务规则与敏感逻辑，无法交由外部厂商实现。

* **算法迭代速度决定风险**：风险与业务模式持续变化，算法需快速迭代，等待外部开发周期往往错失最佳时机。

* **业务效果需紧密耦合**：算法优化高度依赖业务经验反复调试，底层厂商难以承接业务效果的交付目标。

因此，能让用户自主编写自定义算法的图计算产品，才是真正契合业务需要的产品。

## 二、NebulaGraph Analytics 的关键能力

在大规模图计算进入生产环境后，更应该关注这些核心约束。

* 算法是否可扩展

* 计算成本是否可控

* 是否支持业务定制

* 是否能够融入现有数据体系

* 是否具备持续运行能力

NebulaGraph Analytics 的能力设计，正围绕这些约束展开。

## 1.面向业务的自定义图算法能力

在实际应用中，标准图算法往往只能覆盖一部分需求。

例如在风控、资金分析或资产关联场景中，企业通常需要结合业务规则，对算法逻辑进行扩展或重构。这类需求很难通过预置算法直接满足。

NebulaGraph Analytics 提供基于 GQL 的自定义算法能力，允许用户直接定义计算逻辑，让业务人员能够自主构建算法，无需依赖研发与产品团队，将业务规则更智能、更贴合实际地落地到图分析中。

* 将算法表达与图结构统一在同一语义体系内，业务人员只需聚焦业务逻辑，而非底层计算框架。

* 基于 GQL 语言实现，门槛远低于 C++ 等语言，业务人员仅需极小的学习成本，即可读懂、编写、修改。

* 结合大模型能力，提供对应的 skills，输入自然语言，直接生成可运行的算法，显著缩短算法开发、排期、上线周期，将原本数周的工作压缩至低成本、短时间完成。

* 避免在外部系统中重复构建计算逻辑，支持面向具体业务问题的算法高效定制。

从系统视角来看，这意味着图分析能力从调用已有算法，演进为构建面向业务的图计算模型——让算法开发回归业务本身，而非技术的复杂度。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/nebula-analytics/analytics-1.png)

在欢迎页面，单击「立即开始」按钮，即可跳转业务开发页面，在业务开发页面中可直接创建和运行分析作业。

此外，欢迎页面还提供了常用算法的链接。单击某个算法链接，快速查看其代码实现，并通过自定义来创建自己的分析作业。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/nebula-analytics/analytics-2.png)

进入任务开发页面，项目面板用于管理项目和文件，编辑器面板用于编辑所选文件中的过程，以临时模式运行过程，或创建作业以定时运行过程。

## 2. 面向异构环境的数据接入能力

企业数据通常分布在多个存储系统中，包括图数据库、数据湖以及对象存储等。

如何在异构环境下高效接入数据，是图分析落地的前提。

NebulaGraph Analytics 提供多源数据接入能力，支持从以下数据源导入数据：

* NebulaGraph 图数据库

* 本地存储系统

* HDFS

* Amazon S3

* Google Cloud Storage

同时支持多种主流数据格式，包括：

* CSV

* Parquet

* ORC

这一能力使图分析可以在不改变现有数据架构的前提下进行扩展，降低系统集成成本。从架构角度看，能高效地将图计算能力嵌入现有数据体系。

## 3. 面向生产环境的作业管理与调度能力

图分析在实际业务中通常不是一次性计算，而是持续运行的分析流程。

例如：

* 定期更新图指标（如中心性、社区结构）

* 持续监测异常模式

* 支持下游系统实时或准实时调用结果

NebulaGraph Analytics 提供可视化作业管理能力，用于：

* 图分析任务的开发与配置

* 作业执行过程管理

* 定时调度与自动化运行

作业管理页面包含两个页签：作业和运行记录。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/nebula-analytics/analytics-3.png)

如上图所示，作业页签展示了所有作业。可按名称搜索作业，并按触发类型过滤作业，并对作业进行增删改查、暂停中止等作业管理工作，

作业详情页，将提供作业 ID、过程、计算资源、定时、运行记录等信息。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/nebula-analytics/analytics-4.png)

运行记录页签提供运行记录，可自定义时间范围进行筛选，并支持搜索由特定作业触发的运行，或按状态或触发类型过滤运行记录。

# 三、NebulaGraph Analytics 的应用场景

NebulaGraph Analytics 的应用场景，本质上集中在高关系复杂度与高结构依赖的业务领域。

在用户管理中，用户价值不再只是行为结果，而是其所处关系网络的位置。通过图分析，可以识别关键影响节点和高价值群体，从而支撑更精准的运营策略。

在风险控制中，欺诈往往呈现为网络结构而非单点异常。通过社区发现、路径分析等方法，可以在全图范围内识别协同欺诈与资金链路，实现从单点识别，向结构识别的转变。

在资金与审计中，图分析可以还原复杂资金流路径，识别异常链路与关键节点，使原本难以追踪的过程具备可计算性。

而在资产管理与金融场景中，图结构则用于刻画隐性关联与风险传导路径，从而支持系统性风险评估与决策优化。

# 四、总结：场景化、规模化、平台化

NebulaGraph Analytics 围绕大规模图计算构建了完整的系统能力，包括：

* 通过自然语言自定义图算法

* 面向大规模数据的计算效率

* 对多数据源的兼容能力

* 可视化管理平台

当关系规模进入万亿时代，图算法的核心挑战不再是如何实现，而是如何高效计算。NebulaGraph Analytics 通过 GQL 与大模型能力的结合，显著降低了算法开发门槛，业务人员可以直接聚焦业务逻辑，将算法开发周期从数周缩短至数小时。

技术复杂度被系统吸纳，业务意图得以直达计算核心，让图算法真正成为可落地、可被业务自主驾驭的基础设施。

> NebulaGraph Analytics 为企业版 5.x 全新推出的图分析平台，如需咨询更多产品性能及报价，请填写商务咨询问卷～
> https://www.nebula-graph.com.cn/contact

---

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

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)

可自定义图算法的图分析平台 NebulaGraph Analytics

AI 时代的万亿关系分析计算：NebulaGraph Analytics

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

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

在用户使用 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 分离是如何做到这种性能提升的呢？这篇文章给你答案~