NebulaGraph v2.0 GA Overview

2020 年 6 月发布了 NebulaGraph 1.0 GA 之后，越来越多的用户开始尝鲜图数据库技术。在这个过程中，我们收集到了诸多来自社区用户的问题和需求，加上产品自身的演进需求，NebulaGraph 2.0 的开始就自然而然地很快被提升了日程。在历时近一年，经过多个预备版本后，NebulaGraph 2.0 GA 终于跟社区见面了。

2.0 版本规划

在版本规划阶段，根据现有用户的意见、图数据库乃至大数据领域的发展趋势、社区的声音，经过广泛的讨论，最终确定 2.0 版本重点要在以下几个方面发力：

• 提升查询性能。高吞吐、低延时地处理超大数据量是 NebulaGraph 天然的架构优势，在和用户接触的过程中，我们发现很多用户都是因为市面上现有的图数据库产品满足不了业务数据量增长带来的挑战，转而使用 NebulaGraph，因此，在 2.0 版本中继续保持我们在超大数据量实时查询场景下的优势，是用户需要的。
• 保证稳定性。作为一款数据库产品，稳定性无论如何强调也不为过。1.0 GA 之后，有越来越多的用户将 NebulaGraph 用于生产业务，任何轻微的系统抖动，都会给业务造成巨大的影响。同时，用户的业务在不断演进、数据量也在不断增加，我们应该保证 Nebula 集群能随着业务演进和数据量增长始终保持稳定运行。
• 加强系统开放性。2.0 我们新增了几个重要的 feature，同时对底层实现逻辑做了一些优化，使得 NebulaGraph 具备更强的开放性。可以兼容 openCypher，让 Neo4j 用户零学习成本使用 NebulaGraph；能够对接更多图分析算法，满足用户离线分析和图计算需求。
• 确保运维便捷。分布式数据库的运维复杂度是单机数据库无法比拟的，我们在 2.0 版本为用户提供了一些运维的工具，尽量简化 NebulaGraph 的部署、升级、备份、监控等，同时帮助用户更准更快地定位问题。

围绕上面几点原则，我们做了大量的重构、改进、优化，力求把 NebulaGraph 打造成一款生产可用且易用的图数据库产品，有些是用户可以感知的（比如查询更快，运维更简单等），有些则是用户感知不到的优化，为整个系统的稳定性和性能添砖加瓦。

查询性能优化

在 2.0 版本中，我们为 NebulaGraph 设计了一套全新的数据类型系统，统一 Storage，Graph，Client 各个子系统中的数据类型，减少各个子系统甚至子模块之间不必要的数据类型转换以及序列化反序列化。

同时，我们在 2.0 版本对查询引擎完成了一次重构，引入了语义分析、优化、调度等多个系统模块。通过语义分析提前结束不合法的语句，为系统减少了不必要的资源开销，同时能够给用户带来更加可读的报错信息。在 1.0 版本中，我们的语句执行都靠单独的执行器来完成，这极大的限制了我们对 Query 在系统中执行进行优化。因此在 2.0 中，我们对查询中涉及的计算行为进行了必要的抽象，设计了多个算子，将查询拆分成由多个算子组成的执行计划，并通过为 NebulaGraph 设计的 RBO 进行优化。我们将在后续工作中持续迭代，优化各个算子，执行计划，以及用户的实际用例。

在资源调度上，我们重新设计了调度器模块，旨在更合理的为执行计划调度系统资源。

保证稳定性

我们在 2.0 版本的系统稳定性方面做了大量的工作。在查询引擎层，我们构建了全新的测试系统，包括单元测试、集成测试、性能测试。基于 BDD 的集成测试框架，帮助我们快速验证集成测试用例，极大地减小了测试编写的难度。基于 Jmeter 的性能测试框架目前也已经进入正轨，当前的版本已经能够帮助我们快速的验证性能问题。完善的测试系统设施，帮助开发者实现更高效、更稳定的功能，保障了整个系统的稳定性。在存储层，2.0 也重构和增强了chaos 测试系统，来保保证存储层的可靠性和稳定性。

系统开放性

在 2.0 版本中，我们重构了 Query Engine 的执行方式，把原来的执行器（Executor）完成的各项任务拆解为独立的模块，提供更好的封装性和可测性。现在系统的架构主要有解析器（Parser）、验证器（Validator）、优化器（Optimizer）、执行器（Executor）和调度器（Scheduler）组成。模块化的架构不仅让 Nebula 的系统结构清晰，更好维护，也让我们面对新的需求时更加游刃有余。

在过去的一年时间里，我们重写了绝大多数 Query 层的代码，在新的架构下不仅兼容了 1.0 的 nGQL 的功能，也开始支持 openCypher 中的 MATCH 查询，并且做到两者尽量复用相同的运行机制和代码实现。在验证器中，我们增强了语义校验，原来需要到运行时才能知道的错误，现在“编译时”就能捕获。优化器实现了部分基于规则的优化（RBO），在现有的框架下添加优化规则也变得更加容易。此外，我们基于异步的调用方式也重写了执行器的实现，让其专注于具体的计算和求值，错误处理、状态保存和任务调度等都交予执行框架处理。整个系统更加模块化，面对扩展也更加的开放，进一步降低了社区参与的门槛。

在这一版中，我们也开始逐渐丰富 Nebula 自带的算法能力，最短路径、全路径、子图等功能也都悉数获得支持。我们还补充了很多的标量函数、聚集函数和列表函数，同时支持了 string 类型的顶点 ID 和 NULL 值等，这些都给用户带来更多表达上的便利。此外，Nebula 在底层的存储上也做了大量的修改和优化。通过在 RAFT 中添加 leaner 角色来对接 Elasticsearch 系统，Nebula 也初步拥有了全文索引的能力；在 partition 中引入 Zone 和 Group 的抽象来支持异地多活的需求；重新设计 Index 的实现大幅提升带索引的数据导入性能等等。上面的这些大多属于奠基性的工作，在基础夯实之后，相信在不断的迭代中，Nebula 会在接下来的一年里迎来“更快、更稳、更强”的大发展。

便捷的运维

在运维方面，2.0 版本的 NebulaGraph 提供了 Kubernetes 环境下的 2.0 的配套 Helm Charts 部署文件，用户只需要使用 Helm 几条简短的命令就可以快速部署一套 NebulaGraph 集群，由于 2.0 内部组件具有域名地址通信的能力，因此部署文件可简化用户配置，用户只需要按照实际场景提供充裕的调度节点即可。为方便现有用户从其他版本升级到 2.0 GA，我们开发了升级工具。同时，Backup & Restore 工具以及 Dashboard 都在紧锣密鼓的开发测试中。

这里是 NebulaGraph 2.0 的 GitHub repo：https://github.com/vesoft-inc/nebula-graph，欢迎来试！这里有完整的文档供你参考：https://docs.nebula-graph.io/2.0/。使用中遇到任何问题，欢迎来用户论坛一起交流：https://discuss.nebula-graph.com.cn/c/users/5。