作为时下热门的数据库产品，图数据库（GraphDatabase）已经连续几年在 DB-Engines 榜单上蝉联增长最快的数据库类型，并在欺诈检测、社交网络、实时推荐、知识图谱、数据治理等多个领域都有丰富的落地。

那么，图数据库跟大众最熟知的 MySQL 关系型数据库相比有哪些区别？又在哪些场景中更具有优势呢？下面我们一起来探讨一下吧。

# 什么是图数据库

为了方便大家理解，先介绍下图数据库的基本概念。

图数据库是一种将关联数据的实体作为顶点，关系作为边来存储的特殊类型数据库，能够高效地对这些点边结构进行存储、检索和查询。

> 比如，当前为大家所熟知的企业知识图谱采用的就是这种点边类型的数据存储结构，类似于天眼查、[企查查](https://www.nebula-graph.com.cn/posts/qi-cha-cha-knowledge-graph-practice)——

![企业知识图谱](https://docs-cdn.nebula-graph.com.cn/books/images/enterprise-relations.png)

与传统的关系数据库相比，图数据库把数据间的关联关系也作为数据的一部分进行存储，关联上还可以添加标签、方向以及属性，因此可以帮助我们更好地理解和利用复杂的数据关系。

# 图数据库和关系数据库的主要区别

尽管图数据和关系模型都可以存储数据关系，但它们的做法并不相同，以下是详细的区别：

- **数据模型**：关系型数据库使用表格来组织和存储数据，其中每个表格有一定数量的列和行，每行代表一个记录。而图数据库使用点边结构来存储数据，其中节点代表实体，边代表实体之间的关系。

- **存储格式**：图数据库将实体存储为节点，将关系存储为边。关系数据库将数据存储在具有行和列的表中，通过 JOIN 操作进行查询。

- **查询语言**：关系型数据库通常使用 SQL（结构化查询语言）来查询数据。而图数据库使用类似于 Cypher、Gremlin 等查询语言，能更高效地支持复杂的图形遍历和查询。

- **索引**：图数据库通常使用无索引联结，这意味着每个节点都连接到数据库中的每个其他节点，而关系数据库则使用索引指针连接相关数据。

# 图数据库相较于关系数据库的优势

**1. 图数据库更擅长处理复杂的关系数据**

在许多应用场景中，数据往往是具有复杂的关联关系。例如社交网络中的人与人之间的关系、电商平台中商品与用户之间的关系等等，这些数据之间的关系非常复杂，传统的关系型数据库无法很好地处理和展示这些数据。

图数据库正是为了解决这类复杂的数据结构而设计的。图数据库将数据看做一个由节点和边构成的图形结构，这使得查找和理解数据变得更加容易，而毫秒级的查询速度也能在帮助企业快速作出决策、规避潜在风险时至关重要。

**2.图数据库的数据结构更灵活**

由于图数据库采用的是节点和边的数据结构，可以根据业务需求灵活地扩展节点和边的属性。这意味着数据不需要事先定义好结构，可以随时根据需要进行修改和扩展，这种灵活性使得图数据库更加适合处理需要频繁变更的夜晚数据。

**3.图数据库具有更高的查询效率**

传统的关系型数据库在处理复杂数据的时候，需要进行多次关联查询，这会导致查询效率的下降。而图数据库则采用基于图的查询方式，通过遍历节点和边来查找数据，可以大大减少查询的次数，从而提高查询的效率。

**4. 图数据库更具有灵活性**

相对于关系型数据库，图数据库的数据模型更加灵活。图数据库的数据模型不仅可以表示实体之间的简单关系，还可以表示更复杂的关系，如层次结构、网络和多对多关系等。这使得图数据库更适合处理非结构化和复杂数据。

**5.图数据库可以更好地支持非结构化数据**

在实际的应用场景中，很多数据并不是严格的结构化数据，而是半结构化数据和非结构化数据。例如，文本数据、图像数据、视频数据等等。传统的关系型数据库并不擅长处理这些半结构化数据和非结构化数据。而图数据库可以通过图模型来存储这些半结构化数据和非结构化数据，实现更加灵活和高效的数据管理和查询。

**5.图数据库更容易理解**

图数据库非常适合进行可视化展示，因为它是由节点和边构成的图形结构，每个节点和边都有自己的属性和关系。因此，可以使用各种可视化工具来展示和分析数据。

> 例如，我们可以使用图形界面展示社交网络中人与人之间的关系，也可以使用 3D 图形展示城市之间的交通网络，用地图展示物流网络中货物的运输路径等等。

这种可视化效果不仅能够让业务人员更加直观地理解数据，同时也可以帮助他们更好地进行数据分析和决策。

**6. 图数据库可以更好地支持知识图谱和人工智能应用**

由于图数据库的图模型可以很好地表示实体之间的关系，因此图数据库可以很好地支持知识图谱的构建和查询。

知识图谱是一种用于表示和存储知识的图形数据库，它可以用来支持各种人工智能应用，如智能搜索、智能推荐、智能问答等。此外，图数据库还可以与 AI 人工智能算法相结合，从而实现更加智能化的数据分析和挖掘。

# 总结：关系型数据库 vs 图数据库 应该如何选择？

图数据库和关系数据库之间的根本区别在于如何存储和处理关系。关系型数据库采用「行列」表格的形式存储数据，在各领域都有广泛应用，但遇到庞大、复杂、动态的数据场景时非常容易遇到性能瓶颈。而图数据库特殊的点边结构存储数据，在处理海量关联数据时有相当突出的性能优势——**以擅长超大规模数据集的 NebulaGraph 为例，即使处理亿万级别数据也只有毫秒级的查询时延，目前已被包括腾讯、美团、微众银行、小红书、快手等1000+ 知名企业应用于金融风控、实时推荐、知识图谱等业务场景**。

同样需要注意的是，图数据库与关系数据库并不是替代品，而是各自服务于不同的目的，选择合适的数据存储及展示方式将为更好地挖掘数据价值提供更好的帮助。

# 常见问题解答

## 图数据库与关系数据库有何不同？

图数据库使用图结构进行语义查询，并使用节点、边和属性来表示和存储数据。另一方面，关系数据库使用表和它们之间的关系来存储数据。图数据库用于查询复杂的关系，而关系数据库用于更简单的关系结构。此外，图形数据库通常比关系数据库需要更少的连接。因此，图数据库在处理复杂数据时可以更快、更高效。

## 图数据库比关系数据库好吗？

在很大程度上是的。图数据库优于关系数据库，因为它们更灵活，可以处理更复杂的数据关系。关系数据库是基于数据的表结构，数据一旦入库就很难改变。另一方面，图形数据库基于数据的图形结构，易于更改。考虑到数据变得越来越复杂，对于大多数优先考虑复杂数据操作的用例，图数据库要好得多。

## 什么时候可以考虑使用图数据库？

一般来说，**任何能够将数据表示为相互连接的节点网络的应用场景都可以考虑使用图数据库**，例如，在社交网络中，用户的朋友彼此也是朋友。图数据库可以快速找到用户好友的所有好友。相反，关系数据库需要执行多个连接才能找到相同的信息。通过对关系进行优先排序，图数据库可以提供对数据的更深入洞察。

## 图数据库不适合做什么？

图数据库非常适合存储具有复杂关系的数据，例如社交网络或财务数据。但是，图数据库不太适合存储可以轻松以表格格式表示的数据，例如产品目录或客户订单。

---
相关推荐：

[《越来越火的图数据库，到底是什么？｜NebulaGraph 星球说》](https://www.nebula-graph.com.cn/posts/what-is-graph-database)







图数据库相较于关系型数据库有什么区别？图数据库的优势是什么？一起跟随 NebulaGraph 来看一看吧。

跟关系型数据库相比，图数据库的优势在哪里？｜NebulaGraph 星球说

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/aliyun/%E5%85%AC%E4%BC%97%E5%8F%B7.jpg)

大数据时代，数据价值水涨船高，却很少有人提及，对于企业来说，从如山一般增长的数据中挖掘价值，到底意味着什么。

这是各行各业都存在的需求痛点。传统的关系型数据库并不擅长进行关联查询，无论是从效率还是运算速度上考虑，表连接的查询成本都是巨大的，且具有结构性的安全隐患。

“所有技术的发展，都离不开业务的需求。”

国内图数据库头部服务商「NebulaGraph」CEO叶小萌告诉36氪，图数据库等NoSQL数据库的诞生，本身就是为了解决关系型数据库在业务表达中的原生缺陷。图数据库以点代表实体，边代表实体之间的关系，能够更直观、更高效地存储和处理海量关联数据，在金融风控、欺诈检测、社交推荐、知识图谱等场景中都有广泛应用。

「NebulaGraph」母公司「悦数科技」成立于2018年，是一家专注于分布式图数据库，并在移动大数据、数据存储管理等领域拥有丰富研发和项目管理经验的技术型企业。并推出了云上超大规模图数据库「NebulaGraph Cloud」，实现了产品的云化。

# 分布式图数据库：结构灵活，弹性极致

早在2011年，Neo Technology的开源数据库Neo4j就获得了1060万美元融资，宣告了图数据库的巨大价值潜力。而如今，使用图结构进行语义查询，已经被实践在更多的行业应用中。除了大众最为熟知的知识图谱和社交网络之外，个性化推荐、风险分析、身份验证、行业研究、AI、NLP（自然语言处理）等在大多数产业数字化过程中都至关重要的技术领域，也在见证图数据库的异军突起。

除了天然的多层关联关系分析能力之外，因为基于图模型，图数据库也具有天然的可解释性和更好的可视化能力。另一方面，由于点边分离，图数据库比关系型数据库更接近于人类直观的认知逻辑，并能够把这种关系思维更清晰地呈现出来。

技术迭代，一直都是一种朝着人性化迈进的主动选择。

从底层逻辑来分析数据库的核心原理，不难发现，数据库作为一种结构化的解决方案，其应用目的大多都是基于对现实世界中非结构化关系的高效表达。因此，在技术语言的简化、人性化趋势下，越能直接、自然地贴近现实场景下的节点关系网络，在插入更大数据量级的同时削弱计算本身的抽象化特性，也就越有机会迭代掉传统的主流框架，成为时下最流行的商业数据库。

不过，图数据库也存在一些痛点。比如，图查询语言的标准化（ISO-GQL）工作还在进行中。此外，尤其在国内市场，图数据库厂商多为初创型企业，在可规模化和多渠道打通能力上略显不足。在商业化阶段，「NebulaGraph」需要考虑的事情更多，包括更快速的部署实践用户体验和更高的安全标准。

为此，「NebulaGraph Cloud」似乎正在向我们印证，向云服务做集成，也许会是图数据库下一个发展阶段的答案。

作为国内分布式图数据库的标杆产品，「NebulaGraph」自身的一大优势来自于：采用了存储与计算分离的架构，支持终端用户计算层和存储层可以根据各自的情况弹性扩容。这使图数据库具有了云原生的特征，云端部署则能够有效地屏蔽了数据库部署、性能调优、运维等繁杂过程，同时带来“近乎无限”的极致弹性。

# 商业化阶段：开放与“云集成”

早在2005年左右，NebulaGraph 的核心研发团队就开始在国内外多个知名企业参与图数据库相关工作。2015 年，叶小萌正式加入蚂蚁金服，开始主导研发高性能分布式图数据库GeaBase。

彼时，一个令人兴奋的数据库世界开始生成。从Neo4j的成熟，到云数据仓库Snowflake的出现，尽管距离全球知名咨询机构Gartner宣布“图数据库已经成为当下数据分析的基础”还有六年左右的时间，但图数据库的市场早就已经准备好了随时爆发。

2019年，采用原生分布式架构的高性能图数据库「NebulaGraph」正式发布，继续在中国乃至全世界范围内推广图计算技术。根据中国信通院的预测，2025年，图分析在数据和分析创新中的占比将提升至80%。

在2013年开始成为数据库增速最快的子领域之前，图数据库已经经历了漫长的技术拓荒时期，而其真正的商业化历程也不过几年时间，还需要大量的时间和人为努力去给予想象力。

成立三年后，「NebulaGraph」开始做商业化，而在「NebulaGraph Cloud」上线阿里云计算巢后的短短几个月里，「NebulaGraph」已经增加了数十家试用用户，其中有相当一部分客户已经完成签约。

在国产图数据库等ToB软件走向商业化的过程中，前沿技术正在和云服务体验产生1+1>2的效果。无论是「NebulaGraph」所代表的新兴技术厂商，还是已经与各行各业的企服服务商展开了长期合作的阿里云计算巢，积极拥抱生态的开放性，既是顺应技术的结构性趋势，也是解决国内企服领域“圈地”现象的有效途径。

事实上，数据库本身就是一个开放程度很高的领域。随着技术应用的复杂化和行业人才流动加大，技术从业者对于框架的取舍直接决定着企业客户对于商业化解决方案的选择。叶小萌介绍道，「NebulaGraph」很多商业化的线索和实例都来自于社区。

开源降低了技术人员的体验成本，而对于更复杂、更大范围内的企业客户来说，最大的商业化成本在于初创厂商需要在长期的沟通和教育中，反复证明软件的安全性和可用性。同时，也能帮助有图数据库需求的企业实现应用人才的积累。从这一角度来说，阿里云作为国内最大的云服务平台，能够帮助「NebulaGraph」的目标客户通过自助服务的方式，来缩短从试用到购买的决策流程。

基于二者技术特点与服务特性的有机结合，「NebulaGraph Cloud」作为一款云原生图数据库产品可以为对于终端用户提供以下几个优势：

第一，自动化部署，大幅提升部署效率。阿里云提供了统一的基础设施，企业无需自行采购硬件，可以根据业务的灵活度和资源需求弹性调配云资源，实现快速上线。基于阿里云计算巢提供的ROS（资源编排），NebulaGraph实现了云上自动化部署，几分钟内即可交付一个图数据库集群，相比传统以天、甚至以周为单位的交付周期，有极大的提升。

第二，在计算巢平台上的高度集成，可以为最终用户提供更具性价比的方案。在用户私有部署的情况下，需要把数据库部署在一个具有强存储计算能力、价格昂贵的服务器上。但通过云的技术能力，利用阿里云提供的实例、对象存储等高性价比的云服务，能为最终客户提供一套极具性价比的解决方案。例如，基于全新的第四代AMD EPYC处理器打造的阿里云g8a实例，可以为终端客户提供强劲算力，帮助客户加速业务创新、降本增效，持续为客户创造价值。

另一方面，通过云的弹性能力和「NebulaGraph」分布式特性的有机结合，用户在数据量增长过程中对集群规模进行扩容，也能够得到高性价比和稳定的服务。

第三，为用户提供更短的软件试用和决策路径。计算巢的软件免费试用中心，可以很好解决传统软件试用流程冗长、高试错成本的痛点，提供快速、开箱即用的云上应用新体验。在计算巢软件免费试用中心，用户可以直接试用NebulaGraph产品，节省了数周的审批和对接时间，为用户带来了更方便、快捷的一体化试用和决策流程，试用体验大大提升。

第四，更强的可用性和安全性。传统模式下，企业采购硬件资源，数据库部署在自建IDC并由企业监管和运维。接入业务后，企业IT人员需要时刻关注数据库集群状态来保障可用性，而云计算作为技术载体，天然具备跨越时空的优势。「NebulaGraph Cloud」内置了多种角色，用户可以为指定图空间增加不同角色权限的数据库用户，保证业务数据安全。

# 数据价值挖掘：生于云，长于云

“云计算的本质是技术和开放。对于企业服务领域,云需要更加开放,通过技术手段成为伙伴发展的效率倍增器。”阿里云弹性计算产品线总经理张献涛表示，阿里云计算巢的愿景，是构建一个开放的企业服务应用生态，助力中国软件企业生于云、长于云，拥有持续的生命力。

这一生态性的目标，也与「NebulaGraph」的产品理念不谋而合。

“只有当软件分工越来越细化、标准化的时候，才能够更容易彼此集成在一起。”

同样地，在叶小萌看来，国内企服市场标准化、集成化的趋势必将来临。一致的前进方向成为了合作的驱动力，对软件应用生态的坚持也是「NebulaGraph」能够成为阿里云计算巢上第一家图数据库合作伙伴的重要原因。

如今，云计算正在从单一的计算能力发展为体系化的创新。对于企业来说，“上云”既是一个技术选择，也可以成为企业数字化的起点。

作为面向ISV（独立软件服务商）的云集成PaaS平台，阿里云计算巢致力于帮助技术厂商将产品和服务与云原生的能力相结合，从而提升软件服务在交付、部署、管理等环节的效率和用户体验。

Gartner研究显示，目前云服务的增速和渗透率十分可观，大量的商业软件正在从完全私有本地化服务逐步转向基于云服务的商业模式。对此，艾瑞数据亦有所证明：2021年，中国整体云服务市场规模达到了3280.2亿元 ，增速为45.4%。云服务目前在供给端已经形成较为稳固的市场格局，上云、用云也成为了需求侧的广泛共识。

在可以预见的未来，云原生图数据库能够从知识图谱、机器学习及模型优化、数据特征提取分析等多维的角度来与人工智能相结合，释放更大的数据力量，也是图数据库成为SaaS/DaaS产品的关键步骤。

“超出我们预期的是，对于「NebulaGraph Cloud」的用户，我们几乎没有像其他用户一样去深度参与他们的决策过程。”叶小萌着重强调了阿里云计算巢的高效试用及部署流程。在企业上云和企服软件云化的过程中，试用体验是最重要的指标之一。计算巢提供的POC免费试用中心，相比用户需要“手动提交申请、手动创建资源”的传统试用流程，更好地解决了试用流程冗长、高试错成本的痛点，真正做到了自动化部署下的开箱即用。 「NebulaGraph」作为计算巢上首批开通免费试用的服务商之一，也已经充分感受到了其作为企业云化“切入口”的效率与体验价值。

数据关联和价值挖掘的挑战，属于每一家企业。而「NebulaGraph Cloud」也将借助阿里云计算巢，一起帮助企业基于云构建新的数据价值机会，让数据更好地生于云，长于云。


---
本文转载自 36Kr ，原文参见：[《NebulaGraph：打造灵活弹性的云原生图数据库，与阿里云计算巢共同拥抱开放生态》](https://36kr.com/p/2159756734914567)

“超出我们预期的是，对于「NebulaGraph Cloud」的用户，我们几乎没有像其他用户一样去深度参与他们的决策过程。”

NebulaGraph x 36Kr 专访：如何打造灵活弹性的云原生图数据库

在当今的数字化世界中，数据已经成为了我们生活和工作的重要组成部分。传统数据库已经无法支持所有的业务场景，特别是在存储海量复杂数据、结构动态变化、需要深度关联查询的场景下，关系型数据库往往速度极慢甚至根本无法计算。

**图数据库的出现打破了这种局限**。实践证明，图数据库非常适合用来在系统中实时探索、持久化海量数据间的复杂关系。人们习惯于借助图的方式来思考问题，而图数据库以人类的思维模式在高维空间中映射实际世界中的关联，这能帮助业务人员更快地将行业经验转化为数据表示，减少技术与业务之间的沟通成本，同时也让计算结果更具有可解释性。

据 Gartner [预测](https://www.nebula-graph.com.cn/posts/Gartner-global-GDMS-representative-manufacturer)，随着图的使用、普及和成熟度不断提高，到 2025年图技术市场将增长到 32 亿美元，复合年增长率为 28.1%。而根据世界知名的数据库排名网站 DB-Engines.com 的统计，**图数据库在近十年是受到最广泛关注、发展趋势最迅猛的数据库类型**。

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

那么，到底什么是图数据库？它与传统的关系型数据库或者 SQL 数据库有哪些不同？为什么它如此重要？下面不妨跟 NebulaGraph 一起来探讨。

# 什么是图数据库

简单来说，图数据库是一种非关系型的数据库，它使用图来表示数据之间的关系，而不是使用表格或者 JSON 文档。

在图数据库中，数据以节点和边的形式存在，**节点代表数据实体，而边则表示节点之间的关系**。

![什么是图数据库](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/SEO/01.png)

图数据库的**把数据间的关联关系也作为数据的一部分进行存储，边上还可添加标签、方向以及属性**，这使得图数据库非常适合存储和处理复杂的关联数据。因为图可以直观地可视化关系，并且无须大量具体化操作即可快速探索海量数据深度关联关系。

例如，在社交网络中真实用户通常被表示为「点」，用户之间的点赞、关注、评论等行为则被表示为「边」。与此同时，边上还可以体现时间、空间（地理位置）等维度信息。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/SEO/073d1ea9f4b344308c98913194b590e0.png)

使用传统的关系型数据库很难处理这种复杂的关系，而图数据库则可以直观展示这些关联，并能够轻松存储和管理上亿级别的数据，极大程度地提高查询效率，也打开了数据应用的想象空间。

案例参考：[美团是怎样使用 NebulaGraph 图数据库对 6 亿用户进行实时美食、医美商家推荐的](https://www.nebula-graph.com.cn/posts/meituan-graph-database-platform-practice)




# 为什么要用图数据库

相比于传统的关系型数据库和 NoSQL 数据库，图数据库具有很多独特的优势。

## 1、图数据库更擅长处理大规模数据之间的关联关系

图数据库可以处理大规模的数据，包括亿级别的数据。传统的关系型数据库和 NoSQL 数据库虽然可以存储大量的数据，但是在处理复杂的关系时往往会变得非常低效，而图数据库通过使用节点和边的形式，无需大量的 Join 操作即可轻松地处理节点之间的复杂关系。

![img](https://pic2.zhimg.com/80/v2-0cdb429d7497fdf902e1aae5018407f9_1440w.webp)

> 测试显示：在一个包含 100 万人，每个人约有 50 个朋友的社交网络中找最大深度为 5 的朋友，**图数据库在 2 度以上查询效率将明显超过关系型数据库**，而且在关系型数据库无法执行的深度查询场景下仍能实现秒级执行。


## 2、图查询语言相较于 SQL 更高效

图数据库支持高效的查询。传统的关系型数据库通常使用 SQL 语言进行查询，而 NoSQL 数据库则使用各种不同的查询语言，但是它们都很难处理复杂的查询。相比之下，图数据库使用图查询语言（例如 Cypher），这种语言可以用更简洁的查询语句轻松地处理复杂的图结构查询。

![图形用户界面, 文本, 应用程序  描述已自动生成](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/SEO/04.png)

## 3、图数据结构更灵活、更直观、更易于理解

图数据库采用非结构化的数据格式，以人类的思维模式在高维空间中映射实际世界中的关联，相较于表结构的数据更直观易懂。它可以轻松地扩展以支持新的节点和边类型，并且可以轻松地适应数据模式的变化。这意味着，图数据库可以应对不断变化的业务需求，并且可以很容易地进行数据模式迁移。

![https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/visualization%20tool%20release%20note/1.png](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/visualization%20tool%20release%20note/1.png)

# 图数据库有哪些类型

## 1、属性图

属性图模型由顶点、边及其属性构成。顶点和边都可以带有属性，节点可以通过“标签（Label）”进行分组。表示关系的边总是从一个开始点指向一个结束点，而且边是一定是有方向的，这使得图成为了有向图。关系上的属性可以为节点的关系提供额外的元数据和语义。

![图数据库](https://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/what-is-a-graph-database/figure2.png)

## 2、RDF 图

RDF 图（Resource Description Framewor）的顶点和边上没有属性，只有一个资源描述符，这是 RDF 与属性图模型间最根本的区别。在 RDF 中每增加一条信息都要用一个单独的节点表示。比如，在图中给表示人的节点添加姓名。在属性图中只需要在节点添加属性即可，而在 RDF 中必须添加一个名字的单独节点，并用 hasName 与原始节点相连。

RDF 可以水平扩展但不能快速横向扩展关系，因为它们将三元组存储为单独的元素，所以必须从独立事实创建连接并增加延迟以执行图查询。由于其在延迟和规模方面的缺点，主要应用于离线分析。

# 图数据库适用于哪些场景

**图数据库可以应用于很多领域，特别是当需要处理的场景符合以下几点特征时，建议首选图数据库**——

1.需要处理海量、复杂的关联数据

2.需要快速实现深度关系查询

3.需要灵活调整数据模型以响应业务变化

4.需要立体的可视化呈现

另外，图数据库也可以与人工智能技术相结合，实现更加智能化的数据管理和应用。许多行业领先的知名企业正在通过图数据库与深度学习技术相结合，实现智能推荐和预测功能。

目前，我们在**金融、政府、互联网、医疗、运营商、制造等多个行业的社交网络、知识图谱、欺诈检测、药物图谱、供应链管理和物联网等场景中**都可以看到图数据库的身影。

如果你对图数据库感兴趣，但还不知道从哪里入手，选择一款有开源版本的图数据库是个不错的起点，比如 NebulaGraph。

![NebulaGraph 数据库生态系统](https://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/nebulagraph-ecosystem.png)

**NebulaGraph 拥有完整的图数据生态，包括社区、文档、培训支持**。不仅可以 [免费下载](https://www.nebula-graph.com.cn/download) 开源版本直观感受图数据库的特性，而且 NebulaGraph 还拥有国内最大的开源图技术社区，可以随时随地和 数千名真实使用者进行经验交流、技术分享和使用咨询。

当然，如果有更高的应用需求或者需要专业技术团队支持的话，**支持万亿级存储，毫秒级查询延时的 [NebulaGraph 企业版] (https://www.nebula-graph.com.cn/contact)将是不二之选——100% 自主研发支持信创，目前还有最长 30 天[云上免费试用](https://market.aliyun.com/products/56024006/cmgj00059955.html?spm=5176.730005.result.1.3ae23524nmkopu&innerSource=search_nebulagraph#sku=yuncode5395500004)，快来近距离感受超原生分布式图数据库的魅力吧**！

---

*报告来源：Jim Webber，Emil Eifrem，Ian Robinson，Graph Database（2nd Edition).O'Reilly Media,Inc.2013：chapter 2*

本文介绍了图数据库的基础概念，一起来了解下人人都在讨论的图数据库 GraphDatabase 到底是什么。

越来越火的图数据库，到底是什么？｜NebulaGraph 星球说

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/ngql-cheatsheet-cn-01.jpg)

本文旨在让新手快速了解 nGQL，掌握方向，之后可以脚踩在地上借助文档写出任何心中的 NebulaGraph 图查询。

## 视频

本教程的视频版在[B站这里](https://bilibili.com/video/BV1PT411P7w8)。

## 准备工作

在正式开始 nGQL 实操之前，记得先**看过文档「快速入门流程」，部署、连接过 NebulaGraph，并且看过了「常用命令」**。如果你还没看过这两个文档，为了跟上进度，记得先快速过一遍，上面两个文档链接可在文末「参考资料」中获取。

### 我们的目标是

本教程目的在于让大家大概知道了 NebulaGraph 的查询语句后，解决“不知道什么样的查询应该用什么语句”的问题。

### nGQL 是什么

我们先强调一下概念：nGQL 是 NebulaGraph Query Language 的缩写，它表示 NebulaGraph 的查询语言，可以不严谨地分为这 5 部分：

- NebulaGraph 独有 DQL（Data Query Language）查询语句
- NebulaGraph openCypher DQL
- NebulaGraph DML（Data Mutation Language）写语句
- NebulaGraph DDL（Data Definition Language) Schema 语句
- NebulaGraph Admin Queries 管理语句

这里，作为简明教程一把梭，我们只关注前两个部分，后边的内容会在 Part 2 中介绍。

### nGQL 速查表 cheatsheet

大家可以保存下这份单页速查表，一次了解所有 nGQL 的用法。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/ngql-cheatsheet-cn.webp)

## NebulaGraph 独有 DQL

NebulaGraph 的独有读查询语句的设计非常简洁，对初学者非常友好。它结合了管道的概念，做到了只涉及了几个关键词就可以描述出大多数的图查询模式。**由于篇幅的问题，所有 DQL 查询语句的更多用法记得查阅本文的「参考资料」**。

简单来说，nGQL 的独有 DQL 一共分成四类语句：

- 图拓展 / 遍历：`GO`
- 索引反查：`LOOKUP`
- 取属性：`FETCH`
- 路径与子图：`FIND PATH` 与 `GET SUBGRAPH`

和两个特别的元素：

- 管道：`|`
- 引用属性: `$` 开头的几个符号，用来描述一些特定的上下文

### 用 GO 来图拓展 / 遍历

`GO` 的语义非常直观：从**给定的起点**，向外拓展，按需**返回终点**、起点的信息。

```sql
# 图拓展
GO 3 STEPS FROM "player102" OVER follow YIELD dst(edge);
   ───┬───      ───┬───────      ─┬────       ──┬────── 
      │            │              │   ┌─────────┘       
      │            │              │   │                 
      │            │              │   └── 返回最后一跳边的终点
      │            │              │                     
      │            │              └────── 从 follow 这个边[出方向]探索
      │            │                                    
      │            └───────────────────── 起点是 "player102"
      │                                                 
      └────────────────────────────────── 探索 3 步
```

这里只是做了一个简单的 `GO` 语法示例，像 GO 实现的反向、双向拓展，指定可变跳数遍历等，更多 GO 语句用法可查阅参考资料。

### LOOKUP 基于索引反查 ID

和 `GO` 的从已知的点出发相反，`LOOKUP` 是一个类似于 SQL 里 `SELECT` 语义的关键字，它**实际的作用也类似与关系型数据库中的扫表**。

`LOOKUP` **需要手动创建相应 TAG、边类型上索引才能进行相关查询**。

#### 为什么 `LOOKUP` 需要索引？

因为 NebulaGraph 中的数据默认是按照邻接表的形式存储，在分布式设计中，扫描一个类型的点、边是非常昂贵的，所以它被默认禁止了。NebulaGraph 索引的存在增加了类似于表结构数据库的排序数据，可以用来做像是 `SELECT` 的查询。

```sql
# 索引反查
LOOKUP ON player WHERE player.name == "Tony Parker" YIELD id(vertex);
          ──┬───  ──────┬──────────────────────────  ──┬──────       
            │           │          ┌───────────────────┘             
            │           │          │                                 
            │           │          └──────────── 返回查到点的 VID
            │           │                                            
            │           └─────────────────────── 过滤条件是属性 name 的值
            │                                                        
            └─────────────────────────────────── 根据点的类别/TAG player 查询
```

本文仅作 LOOKUP 语法的使用入门，关于索引原理和使用，比如：创建索引会有什么代价？索引会加速读么？记得查看文末的参考资料。

### FETCH PROP 获取属性

如字面意思，如果我们知道一个点、边的 ID，想要获取它上边的属性，这时候我们要用 `FETCH PROP` 而非 `LOOKUP`。

```sql
# 取属性
FETCH PROP ON player "player100" YIELD properties(vertex);
              ──┬───  ────┬─────       ─────────┬──────── 
                │         │         ┌───────────┘         
                │         │         │                     
                │         │         └─────── 返回点的 player TAG 下所有属性
                │         │                               
                │         └───────────────── 从 "player100" 这个点获取
                │                                         
                └─────────────────────────── 获取 player 这个 TAG 下的属性
```

### 路径查找 FIND PATH

如果我们要找到指定两点之间的所有路径，一定要用 `FIND PATH`。

```sql
# 起点终点间路径
FIND SHORTEST PATH FROM "player102" TO "team204" OVER * \   
     ──┬─────            ───────────┬─────────── ───┬───    
  YIELD│path AS p; ┌────────────────┘               │       
       │────┬────  │     ┌──────────────────────────┘       
       │    │      │     │                                  
       │    │      │     └───────── 经由所有类型的边出向探索
       │    │      │                                        
       │    │      └─────────────── 从给定的起点、终点 VID
       │    │                                               
       │    └────────────────────── 返回路径为 p 列
       │                                                    
       └─────────────────────────── 查找最短路径
```

### 单点子图 GET SUBGRAPH

和路径查找类似，如果我们只给定一个起点和拓展步数，用 `GET SUBGRAPH` 可以帮我们获取同样的 BFS 出去的子图。

```sql
# 单点 BFS 子图

GET SUBGRAPH 5 STEPS FROM "player101" \           
             ───┬─── ─────┬──────────             
  YIELD VERTICES AS nodes, EDGES AS relationships;
        ────┬───┼─────────┼───────────────────────
   ┌────────┘   │         │                       
   │            │         └─────── 从 "player101" 开始触发
   │            │                                 
   │            └───────────────── 获取 5 步的探索
   │                                              
   └────────────────────────────── 返回所有的点、边
```

### 利用管道和属性引用符

NebulaGraph 的管道设计和 Unix-Shell 的设计很像，可以将简单的几种语句结合起来，有强大的表达力。

```sql
# 使用通道
GO FROM "player100" OVER follow YIELD dst(edge) AS did  | \  
    ─────┬──────────────────────────────────────────── ─┬─   
  GO FROM│$-.did OVER follow YIELD dst(edge);           │    
         │────┬──     ┌─────────────────────────────────┘    
         │    │       │                                      
         │    │       └──────── 管道将左边的 AS 输出作为右边语句输入
         │    │                                              
         │    └──────────────── 从管道左边的 did 属性开始探索
         │
         └───────────────────── 第一个查询语句
```

除了以上的集中表达之外，NebulaGraph 独有查询语句还有聚合的表达参考 `GROUP-BY`，另外在文档里还有一个 `Cheatsheet`供大家查询一些复杂的例子。

## NebulaGraph openCypher DQL

从 NebulaGraph v2.0 起，openCypher 的 `MATCH` 语句也被 NebulaGraph 原生支持了。虽然 NebulaGraph 这里是一个“方言”，有一些使用细节差异。

```
MATCH <pattern> [<clause_1>] RETURN <output>  [<clause_2>];
```

MATCH 的基本表达是由 `(v:tag_a)` 包裹的点和 `-->` 或者 `<-[:edge_type_1]-` 表达的边组成的模式，再与 `RETURN` 结合表达输出。

如果你从 Cypher 的查询语言入门图数据库，可以从下边几个例子了解到若干 NebulaGraph 里的使用细节差异：

- 增加了 `WHERE id(v) == "foo"` 的表达；
- `==` 表达相等判断而不是 `=`；
- 点的属性表达需要填写 TAG，例如 `v3.player.name` 而不是 `v3.name`；

```
MATCH (v:`player`{name:"Tim Duncan"})-->(v2)<--(v3) \
    RETURN v3.`player`.name AS Name;

MATCH (v:`player`) \
    WHERE NOT (v)--() \
    RETURN v;

MATCH (v:`player`)--(v2) \
    WHERE id(v2) IN ["player101", "player102"] \
    RETURN v;

MATCH (m)-[]->(n) WHERE id(m)=="player100" \
OPTIONAL MATCH (n)-[]->(l) WHERE id(n)=="player125" \
    RETURN id(m), id(n), id(l);
```

以上，为本次简明教程的第一集。

## 参考资料

* 快速入门 NebulaGraph：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/1.quick-start-workflow/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/1.quick-start-workflow/)
* nGQL 常见命令：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/4.nebula-graph-crud/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/4.nebula-graph-crud/)
* GO 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/3.go/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/3.go/)
* 全方位讲解 NebulaGraph 索引原理和使用：[https://discuss.nebula-graph.com.cn/t/topic/8074](https://discuss.nebula-graph.com.cn/t/topic/8074)
* LOOKUP 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/5.lookup/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/5.lookup/)
* FETCH PROP 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/4.fetch/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/4.fetch/)
* GET SUBGRAPH 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/16.subgraph-and-path/1.get-subgraph/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/16.subgraph-and-path/1.get-subgraph/)
* 管道 ｜ 文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/4.pipe/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/4.pipe/)
* 引用符 $ 文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/5.property-reference/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/5.property-reference/)
* GROUP-BY：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/8.clauses-and-options/group-by/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/8.clauses-and-options/group-by/)
* nGQL Cheatsheet：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/6.cheatsheet-for-ngql-command/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/6.cheatsheet-for-ngql-command/)
* MATCH 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/2.match/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/2.match/)

本文旨在让新手快速了解 nGQL，掌握方向，之后可以脚踩在地上借助文档写出任何心中的 NebulaGraph 图查询。

nGQL 简明教程 vol.01 快速入门

来自复旦大学计算机科学技术学院的肖仰华教授在NebulaGraph 2022 年度用户大会上分享了知识图谱最新的研究进展，一起来了解图计算技术是如何帮助知识图谱应对知识表示、获取、评估等方面挑战的。

肖仰华教授：知识图谱与图计算研究分享｜NUC 2022



![图数据库中的”分布式”和“切图” ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/wechat.jpg)

今天，我试着简要综述几类不同的图数据库的分布式与切图的设计，希望可以帮助大家了解不同项目、产品的设计差异。如果有理解不对的地方，欢迎留言讨论。 

 

## 什么是分布式系统 

一般来说，分布式系统是一组计算机程序的集合，这些程序利用跨多个独立节点的资源来实现共同的目标；这里的独立节点，硬件上大多是指商用服务器(Commodity Servers)而不是大型主机（Mainframe）；这里的跨节点协同，硬件上大多是基于以太网设备或者更高端的 RMDA 设备。 

## 为什么我们需要分布式系统？ 

使用分布式技术的主要目的，本质上是用软件技术+廉价硬件来换取昂贵硬件设备（比如主机）的成本；特别是在大多数私有机房环境——而不是公有云端或者超算条件下，此时采购成本是商业决策的重要依据。  

除了降低硬件成本外，分布式技术带来的另一个好处是其“扩展性”，通过在原有商用服务器的数量基础上，增加几台服务器，再结合分布式软件的调度和分发能力，使得新加入的这几台服务器也再额外提供更多的服务； 

相比于每次扩容都要 1 比 1 采购更多的等数量服务器，或者购买更高配置的服务器；分布式技术这一方面使得采购计划可以按需扩容，降低了一次性的大额资本支出；另一方面也使得业务容量可以更加容易规划。 

## 分布式系统的基础问题 

在分布式技术中，由于数据的存储和计算需要跨多个独立节点来实现，因此不得不涉及到一系列基础技术。在本文中我们只讨论两个：一是提供数据（和服务）的拷贝或者副本的问题；二是对于那些庞大数据的存储和计算该如何分发到各个独立节点上完成？ 

 

### 一、数据的副本问题 

 

由于是商用服务器，其硬件上的可靠性和维护远远低于主机，网线松动、硬盘损坏、电源故障在大型机房中几乎每小时都在发生，是常态；处理屏蔽这些硬件问题是分布式软件系统要解决的基本问题。一个常用的方式是为数据（和其服务）提供更多的拷贝或者副本，这些副本存在于多台商用服务器上，当一些副本发生故障时，由正常的副本继续提供服务；并且当访问压力增加时，还可以增加更多的副本来增加服务能力。此外，还需要通过一定的技术手段来保证这些副本的”一致性”，也就是每个服务器上各个副本的数据是一样的。当然，在图数据库中，副本问题也存在；其处理方式和大多数大数据、RDBMS 会较为类似。 

 

### 二、是数据的切分问题 

单台服务器的硬盘、内存、CPU 都是有限的，TB、PB 级别的数据通过一定的办法分发到各个服务器上，这称为”切片”。当一些请求要访问多个切片时，分布式系统要能够将这些请求拆散分发到各个正确的分片上，并将各分片的返回重新“拼装”成完整的结果。 

 

## 图数据中的切分问题：切图 

 

在图数据库中，这个分发过程被形象的称为”切图”：就是把一个大图切成很多的小图，把对于这些小图的存储或者计算再放置在不同的服务器上。相比大数据、RDBMS 的大多数方案，值得一些特别的说明。 

 

我们先考虑一个静态的（不会发生变化的）图结构，比如“CiteSeer数据集”，这里面记录了 3312 篇论文，以及这些论文之间的引用关系；这是一个很小规模的数据集，因此工程上，我们可以基本相信对于这个数据集的处理，基本可以交给单个服务器。 

再对于 twitter2010 这个数据集，其中有 1271 万个顶点和 2.3 亿条边，对于今天(2022)的主流服务器来说，相对可以轻松处理；但对于 10 年前的服务器来说，可能就需要选购非常昂贵的高端服务器才行。 

但对于 WDC 数据集(Web Data Commons)，其中有 17 亿个顶点和 640 亿条边，这样规模的计算这对于当前单台主流服务器来说也相当困难了。 

 

另一方面，由于人类社会数据产生的速度快于摩尔定律，而数据之间的交互与关系又指数级高于数据产生的速度；“切图”似乎是一个不可避免的问题；但这听上去似乎和各种主流分布式技术里面的数据分片和散列的方式没啥区别。毕竟那么多大数据系统，不都要”切”吗 

 

等等——图真的那么好”切”吗？ 

![图数据中的切分问题：切图 ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/11.jpeg)

遗憾的是，并不是。图领域里面，”切图”是一个在技术、产品和工程上需要仔细权衡的问题。 

 

## 切图面临的三个问题 

 

**第一个问题，切在哪里？**在大数据或者 RDBMS 中，我们根据记录或者字段来进行 行切 row-based 或者 列切 column-based，也可以根据 ID 规则进行切分；这些在语义和技术都比较直观。可是图的特点是它的强连通性，一个点通过一些边，关联上了另外一些点，这些点又通过它们的邻边关联上了更多的点，就像全世界的 web 网页，几乎都通过超链接关联在一起，那对于图来说，切在哪里才是语义上直观与自然的。(如果用RDBMS的术语，相当于有大量的外键情况下，如何切分)。当然，也存在一些天然语义上的图切片方式，例如在新冠疫情下，各种毒株在中国的传染链条和国外的链条已经天然是两个不同的网络结构。但此时，引入了第二个问题。 

 

**第二个问题，如何保证切了之后，各分片的负载是大致均衡的？**天然形成的图符合幂率定律——20% 的少数节点连接了 80% 的其他节点，这些少数节点也称为“超级节点”或者“稠密点”。这意味着少数超级节点关联了大多数其他的平平无奇的节点。因此可以预计含有超级节点的分片（服务器）的负载和热点会远远大于其他不含超级节点的分片。 

![Experiments in quantum complex networks in The Azimuth Project ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/1.png)

互联网上网站通过超链接形成的关联网络可视效果，其中的超级网站（节点）清晰可见 

第三个问题，当图网络逐渐演化增长，图的分布和连通性也逐渐发生了改变，原有的切分方法逐渐失效，该如何评估和进行重分布。下图是人类大脑 860 亿个神经元之间的连接可视图，随着学习、锻炼、睡眠、衰老，神经元连接甚至在周级别就会发生显著的变化；原先得到的切片方式可能完全跟不上变化。 

![Brain Connections Colorful Stock Footage Video (100% Royalty-free)  1010776790 | Shutterstock ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/2.png)


当然还有其他很多要考虑的问题细节，本文也尽量避免引入太多的技术术语。 

 

遗憾的是，虽然有这些问题（当然其实还有更多），在技术角度并没有一个通用的最优方案，各个产品针对其重点不得不进行取舍，下面是一些举例。 

 

## 不同图数据库的切图方式 

 

### 1. “分布式”但不”切图” 

这种思路的典型做法是 Neo4j 3.5 虽然采用了分布式的架构，但不进行图切分 

采用分布式的目的，是为了保证写入的多副本一致性和读负载能力。 

也就是说每个服务器中都保留了”全量”的图数据，因此图数据不能大于单机的内存和硬盘容量；而通过增加写副本，可以保证写入过程中单机失效问题；通过增加读副本，可以提供更多的读请求能力（不能提高写请求的能力）。 

可以看到对于前面的三个问题，这种方案在产品层面直接避免。但是理论上，这样的方案称为“分布式”并没有什么问题。 

多说一句，由于是单机，数据库意义上的 ACID 在技术上较为简单。 

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/3.png)

Neo4j 3.5 的因果集群架构 

[https://medium.com/neo4j/querying-neo4j-clusters-7d6fde75b5b4 ](https://medium.com/neo4j/querying-neo4j-clusters-7d6fde75b5b4)

 

### 2. 分布式，由用户来”切图” 

这个典型的代表是 Neo4j 4.x Fabric。根据业务情况，用户指定将每个部分的子图放在一个(组)服务器上,例如在一个集群内，E号产品的图放在 E号服务器上，N号产品的图放在N号服务器上。(当然，为了服务本身的可用性，这些服务器还可以采用上文中 Causal Cluster 的方案。)在这个过程中，不论是查询还是写入，都需要用户指定要访问哪个服务。 Fabric 辅助用户代理路由。这个方案和 RDBMS 的分表非常类似，用户在使用过程中自己指定要使用那个分区或者分表，”切分”这个动作，用户是有着完全的掌控。 

 

可以看到对于前面的三个问题，这种方案在产品层面完全交给了用户来决定。当然，这样的方案也可以称为“分布式”。 

 

多说一句，虽然可以保证E服务器内部的 ACID。但因为存在一定数量的边”横跨”两个服务器，技术上不保证这些”横跨”边操作的 ACID。 

![Sharding Graph Data with Neo4j Fabric - Developer Guides ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/4.png)

Neo4j Fabric 架构 

[https://neo4j.com/developer/neo4j-fabric-sharding/](https://neo4j.com/developer/neo4j-fabric-sharding/) 

 

### 3. 非对等分布式，”切图”， 粗颗粒度的副本 

在这种方案中，既有多副本，也有“切图”，这两个过程也都需要少量用户的介入。

![非对等分布式，”切图”， 粗颗粒度的副本 ](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/5.png)

描述已自动生成 

Tigergraph 的切图方案 

[https://www.youtube.com/watch?v=pxtVJSpERgk](https://www.youtube.com/watch?v=pxtVJSpERgk)


在 TigerGraph 的方案中，点和边（在编码后），会分散到多个分片上。 

上面的三个问题，第 1 和 2 可以通过编码部分的技巧来部分缓解，并将部分查询或者计算的决策（单机还是分布式模型）交给用户决定来实现权衡。 

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/6.png)

描述已自动生成 

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/7.png)

描述已自动生成 

TigerGraph 的单机查询模式和并行计算模式 

多说一句，这样一组分片必需要完整并一模一样的复制多份（因此扩容颗粒度是整个图，而不是某个分片）。相对扩容时的单次支出较大。 

 

### 4. 全对等分布式，”切图”，细颗粒度的副本 

还有一些方案的架构设计目的中，相对把图的扩展性/弹性排在整个系统设计最高的优先级。其假设是数据产生的速度快于摩尔定律，而数据之间的交互与关系又指数级高于数据产生的速度。因此必须要能够处理这样爆炸增长的数据，并快速提供服务。 

在这种架构中，通常的显著特点是把存储层和计算层物理上分开，各自实现细颗粒度的扩容能力； 

数据分片由存储层负责，通常用 hash 或者一致性 hash 的方案进行切分，根据点的 ID 或者主键进行散列。（回答第一个问题） 

图形用户界面, 应用程序

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/8.png)

Nebula Graph 的架构  

Wu, Min, et al. "Nebula Graph: An open source distributed graph database." arXiv preprint arXiv:2206.07278 (2022). 

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/9.png)


Li C, Chen H, Zhang S, et al. ByteGraph: A High-Performance Distributed Graph Database in ByteDance[J]. 

 

为了处理超级节点和负载均衡(第二个问题)，再引入一层数据结构(B+tree)，将大的超级节点拆分成更多小的处理单元。并（工程上）实现线程间的负载切换，和独立扩容计算层。对于第三个问题，通过引入细颗粒度的切片，单独实现部分切片的扩容 

![不同图数据库的切图方式](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/distributed%20and%20sharded%20DBA/10.png)


中度可信度描述已自动生成 

当然，这种方案也可以称为“分布式”。 

 

以上四种方案，在产品和技术层面做了不同的权衡，各种侧重以适合各自的用户业务场景。但它们都可以称为“分布式”。 

 

## 扩展阅读 

* 图的切分问题 

在单机上如何进行切图，已经得到了大量的研究。这里推荐工具 METIS （[http://glaros.dtc.umn.edu/gkhome/metis/metis/overview](http://glaros.dtc.umn.edu/gkhome/metis/metis/overview)） 

在分布式环境的切图是一个比(fei)较(chang)困难的问题。这里推荐一些业界的讨论 

* [https://dgraph.io/blog/post/db-sharding/]([https://dgraph.io/blog/post/db-sharding/) 

* [https://hal.inria.fr/hal-01401338/document](https://hal.inria.fr/hal-01401338/document) 

* [https://docs.janusgraph.org/advanced-topics/partitioning/](https://docs.janusgraph.org/advanced-topics/partitioning/) 

关于“伪分布式”(Pseudo-Distrubuted Mode) 

一般来说，这是用单服务器上的运行模拟在多个服务器的运行；特别适合于学习或者调试。 

* 关于图领域的综述 

Sahu, S., Mhedhbi, A., Salihoglu, S., Lin, J., ¨Ozsu, M.T.: The ubiquity of large graphs and surprising challenges of graph processing: extended survey. VLDB J. 29(2-3), 595–618 (2020) 

Sakr, S., Bonifati, A., Voigt, H., Iosup, A., Ammar, K., Angles, R., Yoneki: The future is big graphs: a community view on graph processing systems. Communications of the ACM 64(9), 62–71 (2021) 

 

## Disclaimer 

1.以上提到的技术方案，是作者的理解和分享，如有错误欢迎指出，并没有商业竞争目的。 

2.为了降低读者理解难度,做了很大程度的简化，并不表示原方案是如此简单。 

---
NebulaGraph 的开源地址：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) 觉得使用体验还不错的话，给我们的 GitHub 点个 ❤️ 鼓励下开源路上的我们呢~

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


图数据库的分布式与切图的设计都有哪些？不同点又是什么？本文带你一探究竟。

图数据库中的”分布式”和“切图” 

从18世纪图论的出现到现在，经过多年的沉淀 Graph DBMS 发生了哪些变迁？图数据库未来在技术、产品、产业上又会有哪些发展？

图行业的一些观察：以图数据库为例｜NUC 2022

> 本文整理自 NebulaGraph 创始人兼 CEO 叶小萌在 NUC 2022 上的分享，欢迎关注 NebulaGraph 官网博客专栏查看更多 [资讯](https://www.nebula-graph.com.cn/tags/%E6%96%B0%E9%97%BB%E8%B5%84%E8%AE%AF) · [干货](https://www.nebula-graph.com.cn/tags/%E7%89%B9%E6%80%A7%E8%AE%B2%E8%A7%A3) · [案例](https://www.nebula-graph.com.cn/tags/%E7%94%A8%E6%88%B7%E6%A1%88%E4%BE%8B) 分享。

![NUC2022-图数据库未来发展分享](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/NUC-17.jpg)

欢迎，今天到场的各位嘉宾。

去年的 NUC 大会我大概介绍了一下图数据库的发展历程以及 NebulaGraph 的产品情况，今年大会的主题是 The future of the big data——大数据的未来，所以想花十几分钟时间分享下我这段时间在图数据库未来方向上的一些想法。

# 图数据库现状：增长势头不减，新老行业各有突破

今天报名的观众大多数都是 NebulaGraph 的用户，大家应该差不多都是在这两三年，最多三四年里开始接触和使用图数据库的，其实整个国内基本也是这样一个趋势。国内的投资机构、图数据库新兴企业，基本上也是在过去三四年的时间里，像雨后春笋一样兴起的。

这几年， NebulaGraph 的实名用户增长速度也非常快。这里可以分享个数据——从 2021 年的第一季度到目前，NebulaGraph 整个的实名用户的差不多是 6 倍多的增长。**这不光说明了大家对我们产品的认可，也反映了图数据库市场正在走向成熟**。

![高速增长的图数据库需求](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/01.jpeg)

与此同时，越来越多商业化用户需求在不断冒出来。右边就是我们观察到的，目前图数据库需求比较旺盛的领域。

**从最早的互联网企业的社交图谱应用，发展到推荐、风控等领域。然后就是金融行业，包括银行、证券、期货、保险等企业，我们把电信运营商也包含了在这里面**。这些企业对图数据库的需求也是差不多在过去的 3-4 年逐渐起来的，而且逐渐变得成熟，我们看到图数据库的需求进入正逐渐进入这些企业的业务主链路，应用在比如反欺诈、反洗钱、反骗保、投研分析等等领域。

第三个领域其实非常有意思，是高端制造。从去年开始我们接触很多这个领域的用户，在这里有汽车制造，有高端电子产品制造等等，我们把电力能源部门也归在了这一类里面。这一类企业对图数据库的需求来自于，例如供应链的管理，生产流程管理，产品维修管理，用户管理等等一整套的流程管理，所以说增长速度还是非常快的。

那么大家可能会问，供应链管理这个话题已经比较老了，我记得最早是在上个世纪 90年代出现的，也就差不多 20 多年前出现了，为什么现在又有？其实之前的供应链管理可能比较简单，就是管理供应商——他们提供了哪些批次、哪些原材料，那么这种管理的数据量其实很小。现在随着技术的不断前进，供应链管理的重心开始发生变化，或者说从供应端开始转向了消费端。

举个例子，比如汽车制造，原来只是关心谁提供了轮胎，谁提供了引擎等等这样一些部件，这个数据量其实不多；但如果需要追踪每一辆汽车上、每一个零部件是由哪个厂家提供的呢？大家知道一辆汽车可能有几万甚至十几万零部件，那么大一点的汽车制造厂，一个月就可以生产十几万辆汽车对吧？如果说我们把每一辆汽车上的零部件，乘以一年生产的汽车总数量，如果追踪到这样细的粒度的话，这个数据量就非常惊人了。**所以说我们看到业务的发展，正从原来的供应端开始向消费端在迁移，过程当中数据量暴增，这个时候就产生了对图数据库的一个必然的需求**。

第四个领域是知识图谱。几十年前大家可能已经知道有知识图谱，但原来只支持一跳两跳的关系查询，现在会走得更深。比如做一些复杂的逻辑推理的时候，可能是需要往下走十几步。原来知识图谱的数据可能是存储在传统的关数据库里，但是随着数据量变大以及对关系查询复杂度变高，传统的关系型数据库就搞不定了——在这种情况下，大家对图数据库的依赖就越来越强。

**除此之外，我们还看到了图数据库在新药研发、芯片设计、甚至 Web3 、数字货币、元宇宙等一些新兴领域的应用开始出现**。所以说，为什么我们说未来已来？因为这些技术其实都代表着未来，可能在未来三五年甚至十年出现的技术中，图技术都有它的应用场景。

# 聊聊 NebulaGraph 未来发展的两个重点 

上面大家已经看到，图数据库行业整个的发展非常快，那么在未来的 3-5 年时间里面，哪几样东西对图数据库的影响会比较大呢？我也分享下我的看法。

![关系型数据库查询语言SQL的发展历史](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/02.jpeg)

## 1. 推动图数据库行业标准化

**历史总是重复上演，所以我们不妨先回顾一下关系型数据库的标准查询语言 SQL 的历史**—— 

1970年，Dr. E. F. Codd 博士发表了《A Relational Model of Data for Large Shared Data Banks》这篇论文，原来他们还不叫 Database，因为没有 Database，当时他们称为 “Data Banks”，其实就是现在的数据库。论文里介绍了他们在大型数据库里的一个关系模型，这就奠定了后来关系代数的基础。

基于这篇论文， IBM 开发了一个查询语言 —— 全称叫 Structured English Query Language ，取首字母就是 SEQUEL。到了几年后，大概 在 79 年之前，他们觉得SEQUEL 这个名字太长了，逐渐就把这个名字改成了 SQL，但发音还是一样的。

**这就是我们大家非常熟悉的，而且是目前整个数据业界唯一一个标准查询语言 SQL 的来历**。79 年时，一家叫 Relational Software 的公司推出了第一款基于 SQL 的商业化数据库；但大家知道这个时候 SQL 其实还没有成为行业标准，只是 IBM 推出的一个查询语言而已。而这家名叫 Relational Software 的公司，相信很多人都没有听过，就已经推出了基于 SQL 的数据库。但后来这家公司改了个名——Oracle，这个名字相信在座的各位就都听说过了，对吧，就是后来的甲骨文公司。

关系型数据库 在 80 年代的发展其实还是很慢的，到了 87 年，SQL 被 ANSI（美国国家标准局）接受为一个标准，有的人把它称为 SQL-86，但这只是美国的一个标准，因为 ANSI 是美国的标准化组织；所以后来他们又通过国际标准化组织，就是 ISO，在 87 年时接纳了基于 ANSI 86 的标准，推出了 87 年的 SQL 标准，业界把它称为SQL-87。当然后续它还推出了很多版本，包括 89 年、92 年，到现在最新的，大家比较熟悉的 99 年版本。

**那么，推出查询语言标准的好处是什么**？

第一个，各大院校开始开设数据库这门课程了，因为他们可以用统一的标准来教授 SQL；第二从企业界来看，因为这有这样一个标准，所以很多数据库如雨后春笋一样冒出来，大家都来支持 SQL。

那么刚刚说到的 Relational Software，就是后来的 Oracle，它是其中最大的受益者。因为这个标准的推出使得业界对数据库的接受程度非常快。我们查了几个数据， Oracle是 86 年上市的公司，他们在 90 年的时候，全球总收入是 10 亿美金不到，到了 95 年就已经达到了 30 亿美金，2000 年的时候就已经达到了 100 亿美金，10 年间有差不多10倍的增长，作为一个数据库企业可以说是非常快了，**当然这背后有很多原因，但其中一个很大的原因，我们认为是来自于这个标准**。

![图数据库查询语言的现状](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/03.jpeg)

**再回过头来看一下图数据库的现状**。

现在的图数据库领域是一个比较分散的状态，光 query language 就有很多种，当然其中比较有名的或者说用户量比较大的是 Cypher，这个大家知道是 neo4j 的查询语言。然后还有 PGQL、[以及 NebulaGraph 推出的 nGQL](https://www.nebula-graph.com.cn/posts/sql-vs-ngql-comparison)，我们也列在这里了。其他的还有 gSQL、GraphQL、Gremlin 等等。甚至还有一些图数据库，号称支持某些语言，但其实他们提供只是一个查询的API，用户要自己去调用 API 来取数据去实现一些算法。

**那么所有这些带给用户的是什么？一个是选择成本，另外一个就是迁移成本，从研发的角度来看，各式各样的语言学习成本也非常高，所以造成了图数据库的普及非常难**。

![Graph-Query-Language的现状](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/04.jpeg)

比较幸运的是，几年前，业界或者说国际标准化组织也看到了这样一个问题，所以大概在差不多 3-4 年前，就在我刚刚说的图数据库高速发展这几年，包括 Oracle、Neo4j 在内的一些公司，就组成了这样一个 workgroup，这个组织是在标准化组织ISO-IECJTC1-SC32-WG3 下面的，目的就是希望推出一个图数据库查询语言（Graph-Query-Language，简称 GQL）的标准。

当然整个标准的制定和推进是一个相当漫长的过程，那么到现在的话，基本上这个标准已经接近最终的版本了。具体内容这里就不展开说了，大概就是一个比较完善的查询语言，包括数据定义、数据查询、数据操作等等，**而最关键的是，它跟 SQL 是一个姊妹篇，就是说跟我们刚才介绍的 SQL 有非常好的结合**。这个工作组把 GQL 里面的很重要的一部分 patttern matching，我们说的图的路径的模式匹配这样一部分抽出来，把这部分作为 SQL的一个 extension，就是把它作为SQL的一个扩展包，并制定了一个新的标准，就是对 SQL 的拓展。我们很高兴地看到，这个标准基本上已经被 SQL 的工作组接受了，那么这个东西其实也是 GQL 的核心，从一开始 GQL 和 SQL 之间就是一个紧密结合的关系。

**统一图查询语言 GQL 为什么这么重要**？

可以看到 GQL 是整个数据领域的第二个查询语言标准。数据库大家都知道，经过几十年的发展，数据库的种类已经是非常多了，对吧？数据库的种类少说十、二十种肯定是有的，大家比较熟悉的可能有比如像时序数据库、文档数据库等等，但这些数据库都没有自己的语言，要么就用 SQL，要么有一些自己的、各式各样的一些查询语言，但都没有这样另外制定一个标准——**只有图数据库，现在国际标准化组织认识到了它的重要性，所以要制定这样一个图查询语言的标准**。这个标准可能是在明年年底或者后年年初会正式对外发布，一旦发布之后，它对投资客户就像前面 SQL 在 80 年代后期推出标准一样，会对整个行业带来一个巨大的推动作用。

![NebulaGraph 在制定标准中的参与和推动作用](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/05.jpeg)

 **再讲一下 NebulaGraph 在制定标准中的参与和推动作用**。

我们作为图数据库公司，主要通过这样的两个不同的途径——一是是通过国际化组织，大家都知道的 ISO，它的成员基本都是国家，并不是公司本身，我们在国内主要就是通过 ISO 在国内的代表电子四所，通过他们积极参与到 GQL 的制定当中，是目前的一条路径。

第二条路径的话是通过另外一个组织叫 LDBC，这个大家可能会比较熟悉。LDBC 是12 年左右由 Facebook 的一个实习生做出来的。当时 Facebook 做关系图谱，社交图谱怎么查询、怎么来判断图数据库或图查询效率？这位实习生就想来做一个 Benchmark，后来就变成了 LDBC。现在 LDBC 也是一个很重要的组织，它跟 GQL的工作组有非常紧密的结合联系，而 [NebulaGraph 现在也是 LDBC 的成员之一](https://www.nebula-graph.com.cn/posts/join-in-ldbc)，也会通过我们在 LDBC 里面的影响力去影响这个标准。

## 2. 把握图数据库的主要应用场景

![NebulaGraph在图数据库语言标准中所做的贡献](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/06.jpeg)

除了标准之外，我们再聊一聊图数据库未来的应用场景。

**我认为图数据库更多的应用是在时效性。为什么这么说**？大家可以看到目前图数据库主要的应用场景，从技术角度来区分，可以分成四类。第一类是实时关系探索，第二类是实时的异步计算，就是从实施的业务实时的 query 里面分出来的异步计算的这样一个分支，它不会影响业务的实时性，但是有它在整个数据计算的时效性会比较高。第三个的话就是全图分析，这个就是我们所理解的 AP，就是事后分析。第四个是图算法，这也是图和其他大数据不一样一个地方，因为图上面有很多算法，比如说社群发现、最短路径等等这样一些算法，那么这个算法也是基于全图计算的。

在这四类应用里我们可以看到，前两类比较偏 TP，也就是说我们说的 online service 或者说在线服务；后两类偏 AP 一些，也就是事后分析。

![图数据库的分析计算OLAP能力解决了痒点](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/07.jpeg)

**我认为相对于 TP，事后分析的场景更多是解决用户的痒点，而不是痛点**。

为什么这么说呢？首先在事后计算时，图计算框架不是不可替代的。大家知道图的计算框架有很多，最早的从谷歌的 Pregel 到后来的比如 GraphX，还有很多这样一些离线的图计算框架，它可以做图分析的一些算法，但这个东西并不是不可替代的，我们用传统的大数据系统也可以做同样的事情。

比如说阿里，原来阿里比较有名的一个，基于 MapReduce  的一个大数据计算框架叫ODPS ，在 ODPS 上他们也做了一个图的计算框架对吧？但是它是基于 ODPS 这个 MapReduce 算法来做的，所以说可以看到包括 Graphx，本身其实也不是一个纯粹的图计算的框架，它也是基于下面的基于流式计算 Spark 来做的对吧？

所以可以看到，图计算框架本身所做的所有事情，用传统大数据计算框架也都能做，唯一不同的地方是什么？可能不同的地方在于用传统大数据框架来做的话，效率会慢一点。如在右边那张图显示的，用图的计算框架做的话只要 3 个小时，用传统大数据框架来做，可能要 5、6个小时，那么对用户来说，3 小时和 6 个小时的差别有吗？肯定是有，但其实没有那么大。

![图数据库的OLTP实时更新和探索能力解决了痛点](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/future-of-graph-database/08.jpeg)

**那么回到刚刚说的 AP ，我们认为，图数据库的实时计算能力可以解决在线业务的痛点问题**。大家知道如果是在线的业务中，查询速度如果比较慢的话，它对业务就会产生影响。

举个例子，比如说金融行业的风控，银行转账的风控场景，之前我们的风控都是做事后分析，现在绝大多数的银行或者金融行业用的基于图的分析，是不是有欺诈或洗钱行为基本都是离线分析，所谓离线就是 T+1 去分析今天好像有两笔交易是有欺诈行为的或者有洗钱风险的，**这样做的问题是，当你分析出来有风险的时候，其实这个钱已经出去了，转账已经发生了，对吧？资损已经发生了**。

所以说从业务角度来说，他更希望什么？他更希望看到的是在事中，也就是说当这笔交易发生的时候，就能够进行判断，如果这笔交易有风险，我就要进行拦截，因为这样对业务的好处就是我能直接减少损失。那么要把它做到能实时的、直接拦截的话，对整个的风控数据查询的性能要求就非常高。

因为大家知道，比如说整个的交易链路，如果我们希望用户转一笔钱的时候，他的体验比较好的话，就需要在比较短的时间，比如说半秒钟或者更短的时间内完成这笔交易。当然，整个链路当中要做很多事情，其中可能有一部分是做风控，给了风控比如 100 毫秒，风控系统必须在 100 毫秒内给我一个结果，说有风险还是没风险。当风控评估超时的时候，系统基本上都是认为这个东西是没有风险，就直接过了。这时问题就来了，如果说你超时或者 100 毫秒内做不了判断的话，对整个的业务带来的风险就越高。那么这样也就是说在图数据库里，如果你要去做一些一跳两跳三跳这种查询的时候，你的延时就必须只能在规定时间内完成，完不成就直接影响到风控动作的完成。

所以，能不能很快地完成查询，其实就是解决了业务的一个痛点问题。**当我们效率足够高的时候，就可以赋能业务去做更多的这样一些事情。而当我们能力不强的时候，业务只能依赖于事后分析**。

基于以上这两个的判断，我们也可以聊聊  NebulaGraph 未来两年大致的发展。一方面我们会全面支持 ISO GQL，便于快速实现标准化的对接。另一方面 NebulaGraph 也会持续提升查询性能和并发度。作为一个分布式系统，我们还需要有更强的弹性能力，以便能够支持更大的数据量。当然，我们也不会放弃 AP，因为离线分析跟在线分析一起组成了图这块的闭环，所以我们也会去集成更强的计算框架以及图学习框架，打造一站式的图解决方案，**敬请各位期待**。 

那么，以上就是我今天要跟大家分享的内容，谢谢大家。

 
 NUC 2022 往期精彩内容回顾：

- [NebulaGraph 图数据库用户大会圆满结束，精彩不落幕…](https://www.nebula-graph.com.cn/posts/nebula-graph-user-conference)

- NUC 2022｜干货内容分享：官网 [博客](https://www.nebula-graph.com.cn/tags/NUC2022)

-  NUC 2022｜嘉宾现场视频：B站 [专栏](https://space.bilibili.com/472621355/channel/seriesdetail?sid=2721519)


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

![关注公众号](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/overview/640.png)



随着图数据库在新老行业的应用不断兴起以及国际标准化组织 ISO 发起的图查询语言GQL标准化发布在即，国产分布式图数据库 NebulaGraph 未来之路将怎么走。

聊一聊图数据库应用的现状和 NebulaGraph 未来发展｜NUC 2022


![GraphX 图计算实践之模式匹配抽取特定子图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/graphx-practice-data-extra.jpg)

# 前言		

NebulaGraph 本身提供了高性能的 OLTP 查询可以较好地实现各种实时的查询场景，同时它也提供了基于 Spark GraphX 的 [nebula-algorithm](https://github.com/vesoft-inc/nebula-algorithm) 库以便支持实时的图算法，这里给 Nebula 点个赞，很不错！

但实践过程中，我发现部分 OLAP 场景中，想实现模式匹配分析，Nebula 的支撑就显得不那么完善了。

这里我对模式匹配的解释是：在一张大图中，根据特定的规则抽取出对应的子图。

举一个简单的例子，比如想要对每个点都进行二度扩散，并按照一定逻辑过滤，最终保留符合要求的二度扩散的子图，这样的任务用 nebula-algorithm 就不太好实现了。

当然，上面这个例子我们可以通过编写 nGQL 语句——查询出对应的数据，但 Nebula 的优势在 OLTP 场景，针对特定点进行查询。对于全图数据的计算，无论是计算架构还是内存大小都不是特别适合的。所以，为了补充该部分（模式匹配）的功能，这里使用 Spark GraphX 来满足 OLAP 的计算需求。

# GraphX 介绍

[GraphX](https://spark.apache.org/docs/latest/graphx-programming-guide.html) 是 Spark 生态的一个分布式图计算引擎，提供了许多的图计算接口，方便进行图的各项操作。关于 GraphX 的基础知识我这里不进行过多的介绍了，主要是介绍一下实现模式匹配的思路。

实现模式匹配主要是依赖于一个重要的 API：**PregelAPI**，它是一种 BSP（BSP：Bulk Synchronous Parallel，即整体同步并行）计算模型，一次计算是由一系列超步实现的。

只看定义不是特别好理解，所以直接介绍它在 GraphX 中的实现，了解它是如何使用的。

## Pregel 运行原理

源码定义如下：

```java
  def pregel[A: ClassTag](
      initialMsg: A,
      maxIterations: Int = Int.MaxValue,
      activeDirection: EdgeDirection = EdgeDirection.Either)(
      vprog: (VertexId, VD, A) => VD,
      sendMsg: EdgeTriplet[VD, ED] => Iterator[(VertexId, A)],
      mergeMsg: (A, A) => A)
    : Graph[VD, ED] = {
    Pregel(graph, initialMsg, maxIterations, activeDirection)(vprog, sendMsg, mergeMsg)
  }
 
```

相关参数含义如下：

* initialMsg: 节点的初始化信息，调用 vprog 函数处理 initialMsg；
* maxIrerations：最大迭代次数；
* activeDiraction：控制 sendMsg 发送的方向，只有满足方向要求的三元组才会进入下一次迭代；
* vprog：更新节点信息的函数。节点收到消息后，执行相关逻辑更新节点信息；
* sendMsg：节点和节点之间发送消息，参数为一个三元组，并且满足 activeDiraction 的方向条件，把消息 Msg 发送给 VertexID，VertexID 可以是 src 点也可以是 dst 点；
* mergeMsg：当同一个 VertexID 接收到多条消息时，合并多条消息为一条，便于 vprog 处理。

只看定义和逻辑同样不太清楚，所以下边再介绍一下 Pregel 的迭代流程：

1. 对于一个 graph 对象，只有激活态的点才会参与下一次迭代，激活态的条件是完成了一次发送/收到消息 A 的动作；
2. 首先初始化所有节点，也就是每个点都调用一次 vprog 方法，参数为 initialMsg，这样使所有节点都在激活态；
3. 然后是将图划分为若干三元组 Triplet，三元组的组成是：src点，edge，dst 点，只保留激活点 activeDirection 方向的三元组；
4. 执行 sendMsg 方法，将消息 A 发送给一个 VertexID 的点，由于返回值是一个 Iterator，也就是可以同时给 src、dst 发送消息，若发送 Iterator.empty 则认为没有发送消息；
5. 由于一个 VertexID 的点会收到多条消息，所以调用 mergeMsg 方法合并消息，合并为一个 A；
6. 合并之后调用 vprog 更新节点的消息，这样就完成了一次迭代；
7. 重复 3-6 的步骤，执行 maxIterations 次迭代或者所有的点都不是激活态则退出，完成 Pregel 的所有计算。

# 模式匹配的思路

知道 Pregel 的计算原理之后，那么怎么实现模式匹配呢，主要就是**根据迭代的思想，不停地将边信息聚合到点上，在迭代的过程中控制发送消息的逻辑来实现特定模式的路径**。

我们可以定义消息为多条路径的集合，发送消息时就是对发送点的路径集合中，每条路径都增加一个边 e，这样就实现了路径的遍历，其实对于一个点来说，本质就是一个广度优先遍历的过程。

还是以二度查询为例，看如下例子：

![GraphX 图计算实践之模式匹配抽取特定子图](https://www-cdn.nebula-graph.com.cn/nebula-blog/graphx-practice-data-extra-01.jpeg)

首先，对每个点都执行一次初始化，每个点的属性为一个空的路径集合，路径集合使用**二维数组**表示，使所有点成为激活态。

然后，进行第一次迭代，可以看到会有两个三元组  `A-E1->B`，`B-E2->C`，那么很容易可以得到这次迭代的结果：`A：[]`，`B：[[E1]]`，`C：[[E2]]`

再进行第二次迭代，这里要做限制，已经发送过的路径不再发送，也就是判断 E 是否已被接收了，防止重复发送的情况。所以第二次迭代的结果就只有 `B-E2->C` 这个三元组有效，也就是把 B 的集合中的每条路径分别增加一个 E2，并发给 C，C 将路径合并即可，那么结果就是：`A：[]`，`B：[[E1]]`，`C：[[E2]`，`[E1,E2]]`。

此时 C 节点上的集合中就有了 E1，E2 两条边，刚好是 A 节点 2 度遍历的结果。

这里举的是简单例子，只是说明这样的一个思路，**核心逻辑就是传递边来实现路径遍历**，实际上每个节点会收到许多点的信息，那么可以将点的结果进行过滤，按照头结点分组即可。实现看如下例子：

![GraphX 图计算实践之模式匹配抽取特定子图](https://www-cdn.nebula-graph.com.cn/nebula-blog/graphx-practice-data-extra-02.jpeg)

在这个例子中根据要求，能得到的结果就是 A 和 G 的2度路径子图，迭代的结果我不再赘述，直接列出C，F节点的属性：`C：[[E2],[E6],[E1,E2],[E5,E6]]`，`F：[[E4],[E3,E4]]`，当然点 H，B，D 也有路径，但其实可以清楚的看到想要的结果是在 C，F 节点上的。

那么，结果有了但它是分散的，怎么合并起来呢？我们可以将每个点路径的第一个边的起始点拿出来作为 key，因为迭代时每条路径是有序的，其实这个 key 就是目标点，比如 E1，E3 的起始点都是 A，E5 的起始点是 G，我们将每条路径都增加一个key，变更为`key:path`，过滤掉小于 2 条边的路径，再按照key分组，就得到了目标点对应的子图路径了，这样是不是就拿到了 A 和 G 各自的2度点边了呢！

# 思路延伸

2 度扩散这个例子还是比较简单的，实际业务中，会有很多的情况，当然图的结构也会比较复杂，比如：

1. 不同标签的点如何遍历
2. 不同类型的边如何遍历
3. 出现环路如何解决
4. 边的方向是有向还是无向
5. 多条边如何处理
6. ...

等等的这些问题，但是核心点不变，就是基于 Pregel 实现广度优先遍历，累积边形成路径信息，**主要的逻辑基本都在于 sendMsg 这个方法，来控制发或者不发，来决定路径的走向，以满足模式匹配的业务要求。一次迭代就是积累一层的路径信息，所以迭代次数与图的深度一致**。在迭代完成后，每个点上都有一些结果，他们可能是中间结果，也可能是最终结果，一般按照指定 key（一般是头结点）分组再进行一些业务逻辑的过滤（比如路径长度），即可得到指定结构的子图，接下来就可以用于业务的分析操作了。

此外，还可以借助 [GraphFrames](https://graphframes.github.io/graphframes/docs/_site/index.html) 来实现诸如：二度扩散，这种简单的模式匹配。通过使用类似 Spark SQL 的算子，十分容易的得到计算结果，大大减少代码的难度。但是由于文档较少，又不如 GraphX 多种算子的灵活，对于复杂的模式还是不太推荐的，感兴趣的可以去了解一下。

# 总结

利用 GraphX 的 Pregel API 进行广度优先遍历来实现模式匹配的好处：

1. GraphX 有多种图算子可以灵活处理图数据；
2. 基于 Pregel，使用路径当做消息可以灵活控制模式子图的结构，理论上可以实现任何结构的模式提取；
3. 能够支持较大数据量的全图模式匹配，弥补 Nebula 图库 OLAP 的不足；
4. 无缝集成到大数据生态圈，方便结果的分析使用。

使用这种方式虽然能够实现模式匹配，但是也有很多缺点，比如说：

1. 每次迭代的消息都是路径集合，越往后消息会越大，导致 JOIN 的数据量很大，内存占用较高。可以通过优化过滤掉不必要发送的信息来解决；
2. 迭代的次数有限，太多了则会出现内存爆炸，不过一般业务中超过 10 层以上的情况也很少；
3. 由于节点 ID 通常是 String，需要提前做映射表，计算完又要转换回来，导致计算过程中 shuffle 的次数很多。

针对上面问题，如果你有更好的实现方案，或者通过其他计算引擎能够更好的实现，请务必与我交流指导！

最后，虽然 GraphX 使用起来上手有一定难度，计算也高度依赖内存，但瑕不掩瑜它仍然是一款优秀的图计算框架，尤其是分布式的特性能够进行大量数据的计算，同时 Spark 又能较好地与大数据生态集成，又有官方提供的 [nebula-spark-connector](https://github.com/vesoft-inc/nebula-spark-connector) 方便读写 Nebula 数据，使用起来还是非常不错的。

我的分享就到这里了，欢迎大家交流更好想法！

> 我是繁凡，一名大数据开发工程师，目前从事图谱产品开发，致力于大规模图数据在业务中的使用。最近使用 GraphX 实践了一些业务要求的模式匹配开发，在这里分享一些使用的思路。

---

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

如何实现模式匹配，抽取特定子图？在本文中社区用户繁凡分享了他的实践思路。

GraphX 图计算实践之模式匹配抽取特定子图


![graph-query-language-review](https://www-cdn.nebula-graph.com.cn/nebula-blog/graph-query-language-review.png)

# 前言

最近在对图查询语言 GQL 和国际标准草案做个梳理，调研过程中找到下面这篇 mark 了没细看的旧文（毕竟收藏就是看过）。做个简单的记录。

# 摘要

本短文会涉及到的图查询语言有 Cypher、Gremlin、PGQL 和 G-CORE。

# 背景

本文主要摘录翻译自 [Tobias2018] （见参考文献），并未涉及到 SPARQL 和 RDF，只讨论了属性图。

文章撰写的时间是 2018 年，可以看做 GQL（Graph Query Language）的一些前期准备。GQL 有多个相关的起源，参见下面这张图。

![graph-query-language-review](https://www-cdn.nebula-graph.com.cn/nebula-blog/gql-overview.png)

因为 Cypher 的历史和 Neo4j 紧密相关，本文会提一些 Neo4j 早期的历史。[Angles2008]（见参考文献）和 [Wood2012]（见参考文献）是两个不错的关于图模型和图查询语言的总结。

# 年表简述

* 2000 年，Neo4j 的创始人产生将数据建模成网络（network）的想法。
* 2001 年，Neo4j 开发了最早的核心部分代码。
* 2007 年，Neo4j 以一个公司的方式运作。
* 2009 年，Neo4j 团队借鉴 XPath 作为图查询语言，Gremlin 最初也是基于这个想法。
* 2010 年，Neo4j 和 Marko Rodriguez 采用术语属性图（Property Graph）来描述 Neo4j 和 Tinkerpop / Gremlin 的数据模型。[PG2010]（见参考文献）
* 2011 年，第一个公开发行版本 Neo4j 1.4 发布了第一个版本的 Cypher。
* 2012 年，Neo4j 1.8 为 Cypher 增加写入图的能力。
* 2012 年，Neo4j 2.0 增加了标签和索引，Cypher 成为声明式的语言。
* 2015 年，Oracle 为 PGX 发明查询语言 PGQL。
* 2015 年，Neo4j 将 Cypher 开源为 openCypher。
* 2015 年，LDBC 成立图查询语言工作组。
* 2016 年，LDBC 工作组开始设计 G-CORE。
* 2017 年，WG3 工作组开始讨论如何将属性图查询能力引入 SQL。
* 2017 年，LDBC 工作组完成了 G-CORE 的初始设计 [GCORE2018]（见参考文献）。
* 2018 年，Cypher 形式化语义的论文发表 [Cypher2018] （见参考文献）。

# Gremlin、Cypher、PGQL 和 G-CORE 的演进

## Neo4j 的早期历史

Neo4j 和属性图这种数据模型，最早构想于 2000 年。Neo4j 的创始人们当时在开发一个媒体管理系统，所使用的数据库的 schema 经常会发生重大变化。为了支持这种灵活性，Neo4j 的联合创始人 Peter Neubauer，受 Informix Cocoon 的启发，希望将系统建模为一些概念相互连接的网络。印度理工学院孟买分校的一群研究生们实现了最早的原型。Neo4j 的联合创始人 Emil Eifrém 和这些学生们花了一周的时间，将 Peter 最初的想法扩展成为这样一个模型：**节点通过关系连接，key-value 作为节点和关系的属性**。这群人开发了一个 Java API 来和这种数据模型交互，并在关系型数据库之上实现了一个抽象层。

虽然这种网络模型极大的提高了生产力，但是性能一直很差。所以 Neo4j 联合创始人 Johan Svensson 花精力，为这种网络模型实现了一个原生的数据管理系统。这个就成为了 Neo4j。 在最初的几年，Neo4j 作为一个内部产品很成功。在 2007 年，Neo4j 的知识产权转移给了一家独立的数据库公司。

Neo4j 的第一个公开发行版中，数据模型由节点和有类型的边构成，节点和边都有 key-value 组成的属性。Neo4j 的早期版本没有任何的索引，应用程序只能从根节点开始自己构造查询结构（search structure）。因为这样对于应用程序非常笨重，Neo4j 2.0（2013 年 12 月发布）引入了一个新概念——点上的标签（label）。基于点标签，Neo4j 可以为一些预定义的节点属性建立索引。

**节点、关系、属性、关系只能有一个标签、节点可以有零个或者多个标签，以上这些构成了 Neo4j 属性图的数据模型定义**。后来增加的索引功能，让 Cypher 成为了与 Neo4j 交互的主要方式。因为这样应用开发者只需要关注于数据本身，而不是上段提到的那个开发者自己构建的查询结构（search structure）。

> 图或者说网络类型的数据模型（多对多的关系）和其数据库的历史，可以追溯到 80 年代。见 Kleppmann 2017第二章（见参考文献部分）。

## Gremlin 的创造

最初与 Neo4j 的查询方式是通过 Java API。应用程序可以将查询引擎作为库嵌入到应用程序中，然后使用 API 查询图。如果是自定义查询引擎，然后应用程序远程访问服务器，这样就比较困难。

就在这段时间，NOSQL 这个概念开始出现。NOSQL 型的数据库引擎一般用 REST 和 HTTP 来交互和查询。Neo4j 的早期员工 Tobias Lindaaker（和 Ivarsson）考虑用 HTTP 的方式访问 Neo4j 会是一种更好的办法。他们观察到很多的查询语句可以表达为：**图到树的投影映射（projection）**。典型的，从根节点开始遍历一个扩张树（spanning tree），然后返回叶子节点。基于这样的观察，并参考一些树结构的查询语句，比如 XPath，也许可以作为一种图的查询方式。而且，XPath 的语法和一般 URI 的语法很像。这样 XPath 查询可以很自然的作为 HTTP GET 中 URI 的一部分。Neo4j 的联合创始人 Peter Neubauer 喜欢这个想法，找了一个朋友 Marko Rodriguez 来干。两天后，Marko 做了一个原型，用 XPath 作为图查询，Groovy 提供循环结构，分支，和计算。 这个就是 Gremlin 最初的原型。 2009 年 11 月发布了第一个版本。

后来，Marko 发现同时用两种不同的解析器（XPath和Groovy）有很多问题，就将 Gremlin 改为基于 Groovy 的一种内置的领域特定语言（DSL）。

## Cypher 的创造

Gremlin 和 Neo4j 的 Java API 一样，最初用于表达如何查询数据库的一种过程（Procedural）。它允许更短的语法来表达查询，也允许通过网络远程访问数据库。Gremlin 这种过程式的特性，需要用户知道如何采用最好的办法查询结果，这样对于应用程序开发人员来说仍旧有负担。基于声明式语言 SQL 的成功：SQL 可以将获取数据的声明方式和引擎如何获取数据分开，Neo4j 的工程师们希望开发一种声明式的图查询语言。

2010 年，Andrés Taylor 作为工程师加入 Neo4j，在此之前他是 SQL DBA。他开始了一个项目，受 SQL 启发，其目标是开发图查询语言，而这种新语言 Cypher 于 2011 年 Neo4j 1.4 发布。

Cypher 的语法基础，是用 "ascii 艺术(ascii art)" 来描述图模式。这种方式最初来源于 Neo4j 工程师团队在源代码中评注如何描述图模式。可以看下图的例子：

![graph-query-language-review](https://www-cdn.nebula-graph.com.cn/nebula-blog/the-origin-of-cypher.png)

> ascii art 简单说，就是如何用可打印文本来描述点和边。Cypher 文本用（）表示点，-[]->表示边。(query)--[modeled as]->(drawing) 来表示起点 query，终点 drawing，边 modeled as。

> 对于程序员来说，当然可以设计一个 API 表示操作点，一个 API 表示操作边. 但这样就不是 SQL 这种声明式语言的目的，对于非程序员使用也太困难。

Cypher 第一个版本实现了对图的读取，但是需要用户说明从哪些节点开始查询。只有从这些节点开始，才可以支持图的模式匹配。

> 略微学术一点的说， graph patterns（或者 motifs finding）和 navigational expression 是两种不同的图查询操作[Renzo2017][databricks2020]（见参考文献部分）。不同语言这两种操作的语义是有一定差别的。

在后面的版本，2012 年 10 月发布的 Neo4j 1.8 中，Cypher 增加了修改图的能力。但查询还是需要指明从哪些节点开始。

2013 年 12 月，Neo4j 2.0 引入了 label 的概念，label 本质上是个索引。这样，查询引擎就可以利用索引，来选择模式所匹配到的节点，而不需要用户指定开始查询的节点。

> 有没有熟悉的感觉？

随着 Neo4j 的普及，Cypher 有着广泛的开发者群体 ，和各行各业的使用。

> 图查询语言也有声明式（Decalarative）和命令式（Imperative）的区别，前者（Cypher）相比后者（Gremlin）更强调目的和手段分离，更依赖于执行优化。但在工程上，两者思想并没有那么大的区别，后者也会有延迟计算和优化，前者也可以部分命令式的思想。好的优化在工程上并不是那么容易，专业的用户比查询引擎更清楚如何求取、访问、加工数据[Renzo2017][Deutsh2020]。

## openCypher - 一种推进和标准化Cypher的开源过程

2015 年 9 月，Neo4j 开放了 Cypher 查询语言，通过开源的方式来治理。这个新主体的治理主体是 openCypher Implementors Group（oCIG）。

2016 年，openCypher 项目发布 EBNF 和 ANTLR4 ，Neo4j 也贡献了很多基于 Apache 2.0 的语言功能测试集（openCypher Technology Compatibility Kit, TCK）。将这些作为语言标准定义，任何人都可以为该语言提交新的提议。2016 年，SAP HANA Graph 发布了基于 Cypher 的查询部分的实现，Agens Graph 和 Redis Graph 在 2017 年支持了 Cypher。2017 年 oCIG 也进行了一系列线上线下的会议，讨论语言功能扩展等。

>这个治理和讨论方式可以通过如下方式：[https://github.com/opencypher/openCypher/blob/master/CIP-PROCESS.adoc](https://github.com/opencypher/openCypher/blob/master/CIP-PROCESS.adoc)

oCIG 发布 openCypher，采用英语语言作为规范，对应了 Neo4j 3.3.0 版本中的 Cypher。

## PGQL 的创建

2015 年，Oracle 为 PGX 引擎开发了图查询语言 PGQL。PGQL 受 Cypher 的启发，也和 Cypher 很接近。

## G-CORE 的创建

Linked Data Benchmarking Council（LDBC）定义了一种厂商无关的基准测试。在开发这个基准测试的过程中，他们发现市面上没有标准的查询语言来表达图查询。为了处理这个问题，成立了一个特别工作组，调研市面上已经存在的图查询语言和框架，定义图查询必须的功能，然后为现有语言提供修改建议。

2016 年，他们想设计一种新语言，而不是对于现有语言的修改。主要原因是不想受现有语言的模型的限制。

G-CORE 是由 LDBC 工作组设计的，但主要受 Cypher 的启发，采用一样的语义。

# 结论

Cypher 是 PGQL 和 G-CORE 的共同祖先。这几个语言的语法和语义都非常的接近。PGQL 更接近一些早期的 Cypher，而 G-CORE 更期望语法和语义上都与 Cypher 兼容。

# 一些个人看法

除去学术上的探索和一些零散的工程尝试，以 Cypher 作为主流属性图查询语言工程实践的历史基准，也就 10 年的时间。在前面的几年 2010-2013，Cypher 自身在基础图功能上还有不少缺失，比如索引、图模式，迭代到 2014 年才产生当前使用的一个主流版本，并且还在持续演化 [Nadime2018]（见参考文献部分）。

重头全新设计一种图语言其实很难，很可能会把前人走过的路（坑）再走（掉）一遍（G-CORE 和 nGQL）。这是 GQL 第一个不容易的地方。

一个标准化组织中，有学术和商业机构，各自诉求也很不相同，商业机构已经各自有庞大的商业使用群体，这是第二个不容易的地方。

制定完的标准，最后是否会被市场所接受和采纳（vendor、custormer、developer、 goverment），又需要多少的布道。这是 GQL 第三个不容易的地方。

除了核心基础的图操作以外的特性，比如 SQL、pregel [Grzegorz2010]（见参考文献部分）、GNN，每个语言 PGQL、GSQL 甚至 Neo4j 自己都各自采用了完全不同的方式来支持这些特性，要不要考虑这些新出现的特性。这是 GQL 第四个不容易的地方。

再想想 GQL 和 Apache Tinkerpop/Gremlin 这两条完全不同的路，这是一个变化很快的时代，计算机又是一个更强调 de facto 标准的行业，GQL 并不容易。(打脸）

# 参考文献

* [Angles2008] Renzo Angles and Claudio Gutierrez, “Survey of Graph Database Models”, ACM Computing Surveys, Vol. 40, February 2008
* [PG2010] Marko A. Rodriguez and Peter Neubauer, “The Graph Traversal Pattern”, April 2010
* [Wood2012] Peter Wood, “Query Languages for Graph Databases”, SIGMOD Record 2012
* [Cypher2018] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor, “Cypher: An Evolving Query Language for Property Graphs”, SIGMOD 2018
* [GCORE2018] Renzo Angles, Marcelo Arenas, Pablo Barceló, Peter Boncz, George Fletcher, Claudio Gutierrez, Tobias Lindaaker, Marcus Paradies, Stefan Plantikow, Juan Sequeda, Oskar van Rest, and Hannes Voigt, “G-CORE A Core for Future Graph Query Languages”, SIGMOD 2018
* [Cypher9] openCypher, “Cypher Query Language Reference”, Version 9, Nov. 2017
* Renzo2017 Renzo Angles, Marcelo Arenas, Pablo Barceló, Aidan Hogan, Juan Reutter, and Domagoj Vrgoč. 2017. Foundations of Modern Query Languages for Graph Databases. ACM Comput. Surv. 50, 5, Article 68 (November 2017), 40 pages.
* Kleppmann2017 Kleppmann, Martin: Designing Data-Intensive Applications. Beijing : O'Reilly, 2017. - ISBN 978-1-4493-7332-0
* [Tobias2018] Title: An overview of the recent history of Graph Query Languages. Authors Tobias Lindaaker, U.S. National Expert.Date: 2018-05-14
* Deutsh2020 Alin Deutsch, Yu Xu, Mingxi Wu, and Victor E. Lee. 2020. Aggregation Support for Modern Graph Analytics in TigerGraph. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (SIGMOD '20). Association for Computing Machinery, New York, NY, USA, 377–392.
* Grzegorz2010 Grzegorz Malewicz, Matthew H. Austern, Aart J.C Bik, James C. Dehnert, Ilan Horn, Naty Leiser, and Grzegorz Czajkowski. 2010. Pregel: a system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of data (SIGMOD '10). Association for Computing Machinery, New York, NY, USA, 135–146.
* Nadime2018 Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. 2018. Cypher: An Evolving Query Language for Property Graphs. In Proceedings of the 2018 International Conference on Management of Data (SIGMOD '18). Association for Computing Machinery, New York, NY, USA, 1433–1445.
* databricks2020[https://docs.databricks.com/spark/latest/graph-analysis/graphframes/user-guide-scala.html#motif-finding](https://docs.databricks.com/spark/latest/graph-analysis/graphframes/user-guide-scala.html#motif-finding)

喜欢这篇文章？来来来，给我们的 [GitHub](https://github.com/vesoft-inc/nebula-graph) 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

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

# 推荐阅读

- [聊聊图数据库和图数据库的小知识](https://nebula-graph.com.cn/posts/graph-database-knowledge-volume-1/)
- [NebulaGraph 技术总监陈恒：图数据库怎么和深度学习框架进行结合？](https://nebula-graph.com.cn/posts/integrate-graph-database-with-deep-learning-framework/)
- [聊聊图数据库和图数据库的小知识 Vol.02](https://nebula-graph.com.cn/posts/graph-database-knowledge-volume-2/)
- [图数据库爱好者的聚会在谈论什么？](https://nebula-graph.com.cn/posts/graph-database-fans-chat/)

来简单了解下图查询语言 Cypher、Gremlin、PGQL 和 G-CORE 的诞生契机和演进历史。

图查询语言的历史回顾短文


![sql-vs-ngql](https://www-cdn.nebula-graph.com.cn/nebula-blog/sql-vs-ngql.png)

这篇文章将介绍图数据库 **NebulaGraph** 的查询语言 [nGQL](https://docs.nebula-graph.com.cn/manual-CN/1.overview/1.concepts/2.nGQL-overview/) 和 [SQL](https://baike.baidu.com/item/%E7%BB%93%E6%9E%84%E5%8C%96%E6%9F%A5%E8%AF%A2%E8%AF%AD%E8%A8%80/10450182) 的区别。不过我们不会深入探讨这两种语言，而是将这两种语言做对比，以帮助您从 SQL 过渡到 nGQL。

SQL (Structured Query Language) 是具有数据操纵和数据定义等多种功能的数据库语言，这种语言是一种[特定目的编程语言](https://zh.wikipedia.org/wiki/%E7%89%B9%E5%AE%9A%E7%9B%AE%E7%9A%84%E7%A8%8B%E5%BC%8F%E8%AF%AD%E8%A8%80)，用于管理[关系数据库管理系统](https://zh.wikipedia.org/wiki/%E5%85%B3%E7%B3%BB%E6%95%B0%E6%8D%AE%E5%BA%93%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F)（RDBMS），或在[关系流数据管理系统](https://zh.wikipedia.org/wiki/%E5%85%B3%E7%B3%BB%E6%B5%81%E6%95%B0%E6%8D%AE%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F)（RDSMS）中进行流处理。

[nGQL](https://docs.nebula-graph.com.cn/master/3.ngql-guide/1.nGQL-overview/1.overview/) 是一种类 SQL 的声明型的文本查询语言，相比于 SQL， nGQL 为可扩展、支持图遍历、模式匹配、分布式事务（开发中）的图数据库查询语言。

# 概念对比
| 对比项 | SQL | nGQL |
| --- | --- | --- |
| 点 | \\ | 点 |
| 边 | \\ | 边 |
| 点类型 | \\ | tag |
| 边类型 | \\ | edge type |
| 点 ID | 主键 | vid |
| 边 ID | 复合主键 | 起点、终点、rank |
| 列 | 列 | 点或边的属性 |
| 行 | 行 | 点或边 |

# 语法对比

## 数据定义语言 (DDL)

数据定义语言（DDL）用于创建或修改数据库的结构，也就是 schema。

| 对比项 | SQL | nGQL |
| --- | --- | --- |
| 创建图空间（数据库） | CREATE DATABASE `<database_name>` | CREATE SPACE `<space_name>` |
| 列出图空间（数据库） | SHOW DATABASES | SHOW SPACES |
| 使用图空间（数据库） | USE `<database_name>` | USE `<space_name>` |
| 删除图空间（数据库） | DROP DATABASE `<database_name>` | DROP SPACE `<space_name>` |
| 修改图空间（数据库） | ALTER DATABASE `<database_name>` alter_option | \\ |
| 创建 tags/edges | \\ | CREATE TAG &#124; EDGE `<tag_name>` |
| 创建表 | CREATE TABLE `<tbl_name>` (create_definition,...) | \\ |
| 列出表列名 | SHOW COLUMNS FROM `<tbl_name>` | \\ |
| 列出 tags/edges | \\ | SHOW TAGS &#124; EDGES |
| Describe tags/edge | \\ | DESCRIBE TAG &#124; EDGE `<tag_name | edge_name>` |
| 修改 tags/edge | \\ | ALTER TAG &#124; EDGE `<tag_name | edge_name>` |
| 修改表 | ALTER TABLE `<tbl_name>` | \\ |

### 索引

| 对比项 | SQL | nGQL |
| --- | --- | --- |
| 创建索引 | CREATE INDEX | CREATE {TAG &#124; EDGE} INDEX |
| 删除索引 | DROP INDEX | DROP {TAG &#124; EDGE} INDEX |
| 列出索引 | SHOW INDEX FROM | SHOW {TAG &#124; EDGE} INDEXES |
| 重构索引 | ANALYZE TABLE | REBUILD {TAG &#124; EDGE} INDEX `<index_name>` [OFFLINE] |

## 数据操作语言（DML）

数据操作语言（DML）用于操作数据库中的数据。

| 对比项   | SQL                                                          | nGQL                                                         |
| :------- | :----------------------------------------------------------- | ------------------------------------------------------------ |
| 插入数据| INSERT IGNORE INTO `<tbl_name>` [(col_name [, col_name] ...)] {VALUES &#124; VALUE} [(value_list) [, (value_list)] | INSERT VERTEX `<tag_name>` (prop_name_list[, prop_name_list]) {VALUES &#124; VALUE} vid: (prop_value_list[, prop_value_list])   INSERT EDGE `<edge_name>` ( `<prop_name_list>` ) VALUES &#124; VALUE `<src_vid>` -> `<dst_vid>`[`@<rank>`] : ( `<prop_value_list>` ) |
| 查询数据 | SELECT                                                       | GO, FETCH                                                    |
| 更新数据 | UPDATE `<tbl_name>` SET field1=new-value1, field2=new-value2 [WHERE Clause] | UPDATE VERTEX `<vid>` SET `<update_columns>` [WHEN `<condition>`]    UPDATE EDGE `<edge>` SET `<update_columns>` [WHEN `<condition>`] |
| 删除数据 | DELETE FROM `<tbl_name>` [WHERE Clause]                      | DELETE EDGE `<edge_type>` `<vid>` -> `<vid>`[`@<rank>`] [, `<vid>` -> `<vid>` ...]    DELETE VERTEX `<vid_list>` |
| 拼接数据 | JOIN                                                         | `|`                                                          |

## 数据查询语言（DQL）

数据查询语言（DQL）语句用于执行数据查询。本节说明如何使用 SQL 语句和 nGQL 语句查询数据。

```sql
SELECT
 [DISTINCT]
 select_expr [, select_expr] ...
 [FROM table_references]
 [WHERE where_condition]
 [GROUP BY {col_name | expr | position}]
 [HAVING  where_condition]
 [ORDER BY {col_name | expr | position} [ASC | DESC]]
```

```sql
GO [[<M> TO] <N> STEPS ] FROM <node_list>
 OVER <edge_type_list> [REVERSELY] [BIDIRECT]
 [WHERE where_condition]
 [YIELD [DISTINCT] <return_list>]
 [| ORDER BY <expression> [ASC | DESC]]
 [| LIMIT [<offset_value>,] <number_rows>]
 [| GROUP BY {col_name | expr | position} YIELD <col_name>]

<node_list>
   | <vid> [, <vid> ...]
   | $-.id

<edge_type_list>
   edge_type [, edge_type ...]

<return_list>
    <col_name> [AS <col_alias>] [, <col_name> [AS <col_alias>] ...]
```

## 数据控制语言（DCL）

数据控制语言（DCL）包含诸如 `GRANT` 和 `REVOKE` 之类的命令，这些命令主要用来处理数据库系统的权限、其他控件。


| 对比项 | SQL | nGQL |
| --- | --- | --- |
| 创建用户 | CREATE USER | CREATE USER |
| 删除用户 | DROP USER | DROP USER |
| 更改密码 | SET PASSWORD | CHANGE PASSWORD |
| 授予权限 | GRANT `<priv_type>` ON [object_type] TO `<user>` | GRANT ROLE `<role_type>` ON `<space>` TO `<user>` |
| 删除权限 | REVOKE `<priv_type>` ON [object_type] TO `<user>` | REVOKE ROLE `<role_type>` ON `<space>` FROM `<user>` |

# 数据模型

查询语句基于以下数据模型：

## RDBMS 关系结构图

![RDBMS](https://www-cdn.nebula-graph.com.cn/nebula-blog/RDBMS.png)

## NebulaGraph 最小模型图

![Studio](https://www-cdn.nebula-graph.com.cn/nebula-blog/Studio.png)

本文将使用 NBA 数据集。该数据集包含两种类型的点，也就是两个标签，即 `player` 和 `team` ；两种类型的边，分别是 `serve` 和 `follow`。

在关系型数据管理系统中（RDBMS）中，我们用表来表示点以及与点相关的边（连接表）。因此，我们创建了以下表格：`player`、`team`、`serve` 和 `follow`。在 **NebulaGraph** 中，基本数据单位是顶点和边。两者都可以拥有属性，相当于 RDBMS 中的属性。

在 **NebulaGraph** 中，点之间的关系由边表示。每条边都有一种类型，在 NBA 数据集中，我们使用边类型 `serve` 和 `follow` 来区分两种类型的边。

# 示例数据

## 在 RDBMS 插入数据

首先，让我们看看如何在 RDBMS 中插入数据。我们先创建一些表，然后为这些表插入数据。

```sql
CREATE TABLE player (id INT, name VARCHAR(100), age INT);
CREATE TABLE team (id INT, name VARCHAR(100));
CREATE TABLE serve (player_id INT, team_id INT, start_year INT, end_year INT);
CREATE TABLE follow (player_id1 INT, player_id2 INT, degree INT);
```

然后插入数据。

```sql
INSERT INTO player
VALUES
   (100, 'Tim Duncan', 42),
   (101, 'Tony Parker', 36),
   (102, 'LaMarcus Aldridge', 33),
   (103, 'Rudy Gay',32),
   (104, 'Marco Belinelli', 32),
   (105, 'Danny Green', 31),
   (106, 'Kyle Anderson', 25),
   (107, 'Aron Baynes', 32),
   (108, 'Boris Diaw', 36),
   (109, 'Tiago Splitter', 34),
   (110, 'Cory Joseph', 27);

INSERT INTO team
VALUES
   (200, 'Warriors'),
   (201, 'Nuggets'),
   (202, 'Rockets'),
   (203, 'Trail'),
   (204, 'Spurs'),
   (205, 'Thunders'),
   (206, 'Jazz'),
   (207, 'Clippers'),
   (208, 'Kings');

INSERT INTO serve
VALUES
   (100,200,1997,2016),
   (101,200,1999,2010),
   (102,200,2001,2005),
   (106,200,2000,2011),
   (107,200,2001,2009),
   (103,201,1999,2018),
   (104,201,2006,2015),
   (107,201,2007,2010),
   (108,201,2010,2016),
   (109,201,2011,2015),
   (105,202,2015,2019),
   (109,202,2017,2019),
   (110,202,2007,2009);

INSERT INTO follow
VALUES
   (100,101,95),
   (100,102,91),
   (100,106,90),
   (101,100,95),
   (101,102,91),
   (102,101,75),
   (103,102,70),
   (104,103,50),
   (104,105,60),
   (105,104,83),
   (105,110,87),
   (106,100,88),
   (106,107,81),
   (107,106,92),
   (107,108,97),
   (108,109,95),
   (109,110,78),
   (110,109,72),
   (110,105,85);
```

## 在 NebulaGraph 插入数据

在 **NebulaGraph** 中插入数据与上述类似。首先，我们需要定义好数据结构，也就是创建好 schema。然后可以选择手动或使用 NebulaGraph Studio（NebulaGraph 的可视化工具）导入数据。这里我们手动添加数据。

在下方的 `INSERT` 插入语句中，我们向图空间 NBA 插入了球员数据（这和在 MySQL 中插入数据类似）。

```cpp
INSERT VERTEX player(name, age) VALUES
100: ('Tim Duncan', 42),
101: ('Tony Parker', 36),
102: ('LaMarcus Aldridge', 33),
103: ('Rudy Gay', 32),
104: ('Marco Belinelli', 32),
105: ('Danny Green', 31),
106: ('Kyle Anderson', 25),
107: ('Aron Baynes', 32),
108: ('Boris Diaw', 36),
109: ('Tiago Splitter', 34),
110: ('Cory Joseph', 27);
```

考虑到篇幅限制，此处我们将跳过插入球队和边的重复步骤。你可以点击[此处](https://oss-cdn.nebula-graph.io/doc/example_data.zip)下载示例数据亲自尝试。

![Nebula-Graph-Studio](https://www-cdn.nebula-graph.com.cn/nebula-blog/Nebula-Graph-Studio.png)

# 增删改查（CRUD）

本节介绍如何使用 SQL 和 nGQL 语句创建（C）、读取（R）、更新（U）和删除（D）数据。

## 插入数据

```sql
mysql> INSERT INTO player VALUES (100, 'Tim Duncan', 42);

nebula> INSERT VERTEX player(name, age) VALUES 100: ('Tim Duncan', 42);
```

## 查询数据

查找 ID 为 100 的球员并返回其 `name` 属性：

```sql
mysql> SELECT player.name FROM player WHERE player.id = 100;

nebula> FETCH PROP ON player 100 YIELD player.name;
```

## 更新数据

```sql
mysql> UPDATE player SET name = 'Tim';

nebula> UPDATE VERTEX 100 SET player.name = "Tim";
```

## 删除数据

```sql
mysql> DELETE FROM player WHERE name = 'Tim';

nebula> DELETE VERTEX 121;
nebula> DELETE EDGE follow 100 -> 200;
```

# 建立索引

返回年龄超过 36 岁的球员。

```sql
SELECT player.name
FROM player
WHERE player.age < 36;
```

使用 nGQL 查询有些不同，因为您必须在过滤属性之前创建索引。更多信息请参见 [索引文档](https://www.yuque.com/nebulagraph/2.query-language/4.statement-syntax/1.data-definition-statements/index.md)。

```cpp
CREATE TAG INDEX player_age ON player(age);
REBUILD TAG INDEX player_age OFFLINE;
LOOKUP ON player WHERE player.age < 36;
```

# 示例查询

本节提供一些示例查询供您参考。

## 示例 1

在表 `player` 中查询 ID 为 100 的球员并返回其 `name` 属性。

```sql
SELECT player.name
FROM player
WHERE player.id = 100;
```

接下来使用 **NebulaGraph** 查找 ID 为 100 的球员并返回其 `name` 属性。

```cpp
FETCH PROP ON player 100 YIELD player.name;
```

**NebulaGraph** 使用 `FETCH` 关键字获取特定点或边的属性。本例中，属性即为点 100 的名称。nGQL 中的 `YIELD` 关键字相当于 SQL 中的 `SELECT`。

## 示例 2

查找球员 Tim Duncan 并返回他效力的所有球队。

```sql
SELECT a.id, a.name, c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE a.name = 'Tim Duncan'
```

使用如下 nGQL 语句完成相同操作：

```cpp
CREATE TAG INDEX player_name ON player(name);
REBUILD TAG INDEX player_name OFFLINE;
LOOKUP ON player WHERE player.name == 'Tim Duncan' YIELD player.name AS name | GO FROM $-.VertexID OVER serve YIELD $-.name, $$.team.name;
```

这里需要注意一下，在 nGQL 中的等于操作采用的是 C 语言风格的 `==`，而不是SQL风格的 `=`。

## 示例 3

以下查询略复杂，现在我们来查询球员 Tim Duncan 的队友。

```sql
SELECT a.id, a.name, c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE c.name IN (SELECT c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE a.name = 'Tim Duncan')
```

nGQL 则使用管道将前一个子句的结果作为下一个子句的输入。

```cpp
GO FROM 100 OVER serve YIELD serve._dst AS Team | GO FROM $-.Team OVER serve REVERSELY YIELD $$.player.name;
```

您可能已经注意到了，我们仅在 SQL 中使用了 `JOIN`。这是因为 **NebulaGraph** 只是使用类似 Shell 的管道对子查询进行嵌套，这样更符合我们的阅读习惯也更简洁。

# 参考资料

我们建议您亲自尝试上述查询语句，这将帮您更好地理解 SQL 和 nGQL，并节省您上手 nGQL 的学习时间。以下是一些参考资料：

- [NebulaGraph Studio 用户指南](https://github.com/vesoft-inc/nebula-studio)
- [NebulaGraph GitHub 仓库](https://github.com/vesoft-inc/nebula)
- [NebulaGraph 快速入门文档](https://docs.nebula-graph.com.cn/)

> 作者有话说：Hi，Hi ，大家好，我是 Amber，NebulaGraph 的文档工程师，希望上述内容可以给大家带来些许启发。限于水平，如有不当之处还请斧正，在此感谢^^

喜欢这篇文章？来来来，给我们的 [GitHub](https://github.com/vesoft-inc/nebula-graph) 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

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



这篇文章将介绍图数据库 NebulaGraph 的查询语言 nGQL 和 SQL 的区别。

文档解读 ｜ SQL vs. nGQL


![nebula-graph](https://www-cdn.nebula-graph.com.cn/nebula-blog/Nebula01.jpeg)

图数据库（英语：Graph Database）是一个使用图结构进行语义查询的数据库。该系统的关键概念是图，形式上是点 (Node 或者 Vertex) 和边 (Edge 或者 Relationship) 的集合。一个顶点代表一个实体，比如，某个人，边则表示两个实体间的关联关系，比如 “你关注 NebulaGraph”的关注关系。图广泛存在于现实世界中，从社交网络到风控场景、从知识图谱到智能推荐。

# NebulaGraph 是什么

NebulaGraph 是一款开源的分布式图数据库，擅长处理千亿个顶点和万亿条边的超大规模数据集。提供高吞吐量、低延时的读写能力，内置 ACL 机制和用户鉴权，为用户提供安全的数据库访问方式。

作为一款高性能高可靠的图数据库，NebulaGraph 提供了线性扩容的能力，支持快照方式实现数据恢复功能。在查询语言方面，开发团队完全自研开发查询语言——nGQL，并且后续会兼容 OpenCypher 接口，让 Neo4j 的用户可无缝衔接使用 NebulaGraph。

# NebulaGraph 特性


- **开源**：NebulaGraph 代码开源，采用 Apache 2.0 License，用户可以从 GitHub 下载源码自己编译，部署。欢迎提交 pr，成为 Contributor。
- **可扩展性**：存储计算相分离的架构，当存储空间或计算资源不足时，支持对两者独立进行扩容，避免了传统架构需要同时扩容导致的经济效率低问题。云计算场景下，能实现真正的弹性计算。提供线性扩展的能力。
- **高可用**：全对称分布式集群，无单点故障。并且支持多种类型快照方式实现数据恢复，保证在局部失败的情况下服务的高可用性。
- **HTAP**: 支持 OLTP 实时查询的同时提供了 OLAP 的接口，真正在同一份数据上提供实时在线更新的前提下，也提供复杂分析和挖掘的能力。
- **安全性**：内置授权登录与 ACL 机制，提供用户安全的数据库访问方式，也可接入 LDAP 认证。
- **类 SQL 查询语言 nGQL**：类 SQL 的风格减少了程序员迁移的成本，同时具有表达能力强的优点。

# NebulaGraph 架构

![architecture](https://www-cdn.nebula-graph.com.cn/nebula-blog/Nebula02.png)


# NebulaGraph 1.0 功能

## 基础功能

- **多图空间**：支持多图空间，不同的图空间的数据物理隔离，并且可设置不同的副本数，以应对不同的可用性要求。
- **顶点**：支持基本增删改查操作，支持多种顶点类型，也支持同一顶点有多种类型。
- **边**：支持基本增删改查操作，支持有向图，支持节点间存在同一种类型或者不同类型的多条边。
- **Schema**：Tag / EdgeType 支持多种数据类型，支持对属性设置默认值。一个点可以设置多个 Tag。
- **聚合操作**：聚合函数 GROUP BY、排序函数 ORDER BY、限定函数 LIMIT 自由组合返回所需数据。
- **组合查询**：UNION，UNION DISTINCT，INTERSECT，MINUS 对数据集进行组合查询。
- **条件查询/更新**：IF...RETURN 和 UPDATE ... WHEN 根据指定条件查询/更新数据。
- **Partition**: 支持查看数据分片信息，以及 Partition 对应的 leader 信息。
- **顶点 ID 策略**：支持用户自定义 int64 ID, 内置 hash() 和 uuid() 函数生成顶点 ID。
- **索引**：支持索引、联合索引，对已建立索引的数据，按条件查找快速查找数据。
- **管道查询**: 管道符前面查询语句的输出可作为管道符后面命令的输入。
- **用户定义变量**：用户自定义变量可暂时将查询结果存储在自定义的变量中，并在随后查询语句中使用。
- **多种字符集**、**字符编码**

## 高级功能

- **权限管理**: 支持用户权限认证，支持用户角色访问控制。可轻松对接现有用户认证系统。 NebulaGraph 提供五种角色权限：GOD、ADMIN、DBA、USER 和 GUEST。
- **稠密点**：对于超级顶点支持蓄水池采样, 在只遍历一遍数据（O(N)）的情况下，随机的抽取k个元素。
- **集群快照**：支持以集群维度创建快照，提供在线的数据备份功能，快速恢复。
- **TTL**：支持设置数据的有效期，快速清理过期数据释放资源。
- **Job Manager**：Job 管理调度工具，目前支持 Compaction / Flush 操作。
- **支持在线扩缩容以及负载均衡**
- **图算法**：支持全路径 / 最短路径算法。
- **提供 OLAP 接口，对接图计算平台**。
- **监控接口**：支持系统状态监控、API 访问时间监控、性能数据监控等操作。

## 客户端

- [Java 客户端](https://github.com/vesoft-inc/nebula-java)：可自行编译或者从 mvn 仓库进行下载。
- [Python 客户端](https://github.com/vesoft-inc/nebula-python)：可通过源码安装或者 pip 进行安装。
- [Go 客户端](https://github.com/vesoft-inc/nebula-go)：可通过 `go get -u -v github.com/vesoft-inc/nebula-go` 安装使用。

## 周边工具

- **NebulaGraph Studio**：基于 Web 的可视化环境，提供图操作界面、图数据展示与分析。见 [NebulaGraph Studio](https://docs.nebula-graph.com.cn/2.0.1/nebula-studio/deploy-connect/st-ug-deploy/)
- **导入工具**
  - Nebula Importer，提供高性能的 CSV 文件导入工具，支持导入本地和远程文件。见 [Nebula-Importer](https://github.com/vesoft-inc/nebula-importer)
  - Spark Writer 基于 Spark 的分布式数据导入工具。见[ Spark Writer](https://github.com/vesoft-inc/nebula/blob/master/docs/manual-CN/3.build-develop-and-administration/3.deploy-and-administrations/server-administration/storage-service-administration/data-import/spark-writer.md)
- **导出工具**
  - Dump Tool，单机离线数据导出工具，可以用于导出或统计指定条件的数据。
- **第三方支持**
  - 对接 Prometheus 系统以及 Grafana 可视化组件，支持 Ansible 和 Kubernetes 部署，可实时监控集群的状态。


NebulaGraph 一个开源的分布式图数据库，如果你在使用过程中遇到问题，你可以在论坛：[https://discuss.nebula-graph.com.cn/](https://discuss.nebula-graph.com.cn/) 和 GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) 得到帮助 :)

图数据库 NebulaGraph 是什么？本文将带你了解它的特性和功能，并提前揭秘部分 NebulaGraph 1.0 功能