<p><img src="https://www-cdn.nebula-graph.com.cn/nebula-blog/performance-comparison.png" alt="性能测试对比" /></p>
<blockquote>
  <p>本文系腾讯云安全团队李航宇、邓昶博撰写</p>
</blockquote>
<p>图数据库在挖掘黑灰团伙以及建立安全知识图谱等安全领域有着天然的优势。为了能更好的服务业务，选择一款高效并且贴合业务发展的图数据库就变得尤为关键。本文挑选了几款业界较为流行的开源图数据库与 <a href="https://github.com/vesoft-inc/nebula">NebulaGraph</a> 进行了多角度的对比。</p>
<h2 id="post-图数据库介绍">图数据库介绍</h2>
<h3 id="post-neo4j">Neo4j</h3>
<p><a href="https://neo4j.com/">Neo4j</a> 是目前业界广泛使用的图数据库，包含社区版本和商用版本，本文中使用社区版本。</p>
<h3 id="post-hugegraph">HugeGraph</h3>
<p><a href="https://github.com/hugegraph/hugegraph">HugeGraph</a> 是百度基于 <a href="https://janusgraph.org/">JanusGraph</a> 改进而来的分布式图数据库，主要应用场景是解决百度安全事业部所面对的反欺诈、威胁情报、黑产打击等业务的图数据存储和图建模分析需求。具有良好的读写性能。</p>
<h3 id="post-nebulagraph">NebulaGraph</h3>
<p><a href="https://github.com/vesoft-inc/nebula">NebulaGraph</a> 是一款开源的分布式图数据库，采用 shared-nothing 分布式架构，擅长处理千亿节点万亿条边的超大规模数据集，从而更好地服务企业级应用。</p>
<h2 id="post-测试硬件环境">测试硬件环境</h2>
<p><img src="https://www-cdn.nebula-graph.com.cn/nebula-blog/hardware-environments.png" alt="硬件测试环境" /></p>
<h2 id="post-性能对比">性能对比</h2>
<p>我们使用不同量级的图从入库时间，一度好友查询，二度好友查询，共同好友查询几个方面进行了对比，结果如下：</p>
<p><img src="https://www-cdn.nebula-graph.com.cn/nebula-blog/test-results.jpeg" alt="测试结果" /></p>
<p>可以看到在导入性能上，数据量小的时候 NebulaGraph 的导入效率稍慢于 Neo4j，但在大数据量的时候NebulaGraph 的导入明显优于其他两款图数据库；在 3 种查询场景下， NebulaGraph 的效率都明显高于 Neo4j，与 HugeGraph 相比也有一定的优势。</p>
<h2 id="post-查询语言对比">查询语言对比</h2>
<p><img src="https://www-cdn.nebula-graph.com.cn/nebula-blog/query-language-comparsion.jpeg" alt="查询语言对比" /></p>
<p>从查询语句的角度出发，Gremlin 比较复杂，nGQL 和 Cypher 比较简练，从可读性角度出发，nGQL 比较类 SQL 化，比较符合大家的使用习惯。</p>
<h2 id="post-可视化对比">可视化对比</h2>
<p><img src="https://www-cdn.nebula-graph.com.cn/nebula-blog/visualization-comparsion.png" alt="查询语言对比" /></p>
<p>在可视化方面，所有的平台都还只处于可用状态，NebulaGraph 的选择性扩展在团伙挖掘中是一个加分项，但是在二度结果展示流畅度，展示结果自定义展示方面还有优化空间。</p>
<p>在比较了多款业内主要使用的开源数据库后，我们从性能，学习成本和与业务的贴合程度多个角度考虑，最终选择了性能出众，上手简单，能大幅提高业务效率的 NebulaGraph 图数据库。</p>
<p><strong>本文首发于</strong> <a href="https://discuss.nebula-graph.com.cn/">NebulaGraph 论坛</a>，<strong>阅读本文的你有任何疑问，欢迎前往论坛和作者进行讨论，原帖传送门</strong>：<a href="https://discuss.nebula-graph.com.cn/t/topic/1013">https://discuss.nebula-graph.com.cn/t/topic/1013</a> </p>

本文中，腾讯安全团队挑选了几款业界较为流行的开源图数据库与 NebulaGraph 进行了多角度的对比。

用户案例

周边工具

特性讲解

开发日志

技术分享

产品实践

社区动态

行业科普

新闻资讯

发版说明

安装部署

解决方案

架构系列

源码解读

NUC2022

性能报告

图数据库对比：Neo4j vs NebulaGraph vs HugeGraph

Nebula 架构剖析系列（零）图数据库的整体架构设计

NebulaGraph发布企业版 v3.4.0，深入探索数据价值

美团：主流图数据库厂商选型报告 NebulaGraph vs Dgraph vs JanusGraph

中国移动：NebulaGraph 图数据库在金融风控中的落地应用

如何用 NebulaGraph 图技术搞定 7 个典型社交网络应用？

![nebula-br local-store](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-02-1.webp.jpg)

看过我之前文章的读者可能知道我之前用 nebula-br 搭建过主备集群，具体实践过程不做赘述，有兴趣的小伙伴可以看下这个链接：nebula-br local-store 模式搭建主备集群实践 🔗

那么问题来了，为什么在已有 nebula-br 搭建集群的情况下，我又造了个“新轮子”，让 spark-connector 走上 nebula-br 的老路呢？在这里我来讲讲二者的优劣势：

**！注意**
文章内容仅代表个人观点，仅供参考。

## 主备集群搭建的选择

先从目前个人已知的可搭建备集群的开箱即用工具讲起，NebulaGraph 社区的相关搭建工具有：

- nebula-br
- nebula-spark-connector
- nebula-flink-connector

由于 nebula-flink-connector 和 nebula-spark-connector 实践原理较为相似，本文就不单独地讲述 nebula-flink-connector 如何搭建主备集群。

### 搭建备集群实践

nebula-br 主备集群是通过本地生成 snapshot 备份，然后传输到备集群进行恢复的方式。

- 优点：
  - 搭建速度快；

- 缺点：
  - 生成备份文件的时候会导致 Nebula 不可写，影响在线业务；
  - 环境搭建麻烦，需要在主备集群上运行 Agent 和 BR，此外恢复时需要读取备份文件，这些文件要么通过 S3 或者 NTFS 共享，要么就手动拷贝；
  - 从源集群备份还原到目标集群，目标集群将会被覆盖（也就是跟源集群保持一致，可以理解为目标集群将会被清空，然后还原源集群数据到目标集群）。

### spark-connector 搭建集群的优劣势

nebula-spark-connector 主备集群是通过 nebula-client 去 scan nebula 的数据，然后生成 INSERT 语句在备集群进行重放。

- 优点：
  - 开箱即用，针对小数据集群（低于 1 亿）基本上不需要任何开发直接使用；大数据集群（大于 1 亿）可能需要额外流量控制逻辑；
  - 同步时对源集群的读写影响较小（前提是需要控制导出并发控制）；
  - 同步粒度更精细，可以指定同步 Space、Tag、Edge；

- 缺点：
  - 导出导入的方式同步数据比较慢。就速度这点和官方交流了下，官方表示之前在某家公司业务上实测过速度，nebula-spark-connector 做同步是要比 nebula-br 快 3-5 倍。可能环境和参数有差异，如果读者你选择工具的时候，可以先测试下相关工具的性能数据。
  - 需要 Spark 环境支持；
  - 无法中断重启时接着上次 cursor 继续 scan；

这里稍微说下 nebula-flink-connector，个人感觉它跟 nebula-spark-connector 最大的区别在于 Spark 需要读完整个分区才会做 Write 操作，nebula-flink-connector 可以做到边读边写，理论上效率会高一点。

**nebula-spark-connector 原理**

![nebula-spark-connector](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-02-2.webp.jpg)

本图有任何理解错误的地方，麻烦在留言帮忙指出，感谢。


## 搭建备集群实践

nebula-spark-connector 的 GitHub 仓库地址：https://github.com/vesoft-inc/nebula-spark-connector，本文采用 nebula-spark-connector 的 release-3.6 分支，并以 Spark 3.x 为例。

首先，准备相关的运行环境：
```
`$ git clone -b release-3.6 https://github.com/vesoft-inc/nebula-spark-connector.git
$ cd nebula-spark-connector
$ mvn clean package -Dmaven.test.skip=true -Dgpg.skip -Dmaven.javadoc.skip=true -pl nebula-spark-connector_3.0,example -am -Pscala-2.12 -Pspark-3.0`
```

NebulaGraph 的导入导出可以直接使用 example 中的 Nebula2Nebula.scala 完成，通过上面 maven 打包命令后在 example 的 target 目录可得到 example-3.0-SNAPSHOT-jar-with-dependencies.jar 文件，提交 Spark 任务命令：

```
`spark-submit --master local \
 --conf spark.driver.extraClassPath=./ \
 --conf spark.executor.extraClassPath=./  \
 --class com.vesoft.nebula.examples.connector.Nebula2Nebula \
 example-3.0-SNAPSHOT-jar-with-dependencies.jar \
 -sourceMeta "xxxxx:9559" -targetMeta "yyyyy:9559" -targetGraph "yyyy:9669" -sourceSpace "source" -targetSpace "target" -includeTag "user" -excludeTags "aa,bb" -excludeEdges "cc,dd"  -limit 2  -batch 2 -p 8 -timeout 50000 -u root -passwd nebula`
```

参数解释：

- sourceMeta：源 nebula 服务 metad 地址（从哪里导出）
- targetMeta：目标 nebula 服务 metad 地址
- targetGraph：目标 nebula 服务 graphd 地址，多个地址以英文逗号隔开（导出数据重新组装 INSERT 语句将通过此地址进行提交）
- sourceSpace：源 nebula 的 Space，也就是要导出的 Space 名称
- targetSpace：目标 nebula 的 Space，也就是要导入的 Space 名称
- includeTag：指定导出的 Tag，不指定就全部 Tag 导出
- excludeTags：排除哪些 Tag 不进行导出同步
- excludeEdges：排除哪些 Edge 不进行导出同步
- limit：从源 nebula 导出时每次 scan 多少数据，值越大单次 scan 的数据量越大，对源 nebula 服务器的压力越大，在没有达到磁盘和网络 IO 的瓶颈前，理论上值越大导出更快
- batch：导出的数据多少一批打包成一条 INSERT 语句发送到目标 nebula 服务的 graphd 机器上进行执行
- p：也叫 writeParallel, 导出的数据拆分成多少个任务并行写，值越大速度越快，但是目标 nebula 服务器压力越大
- timeout：每次 scan 源数据的超时时间

### 优化改造

这里讲下为什么要做这些优化改造：

1.经我们线上验证，Nebula2Nebula 示例是一次所有 Partition 导出后才做导入操作，对于数据量非常大的情况下并不友好、效率太低，此外对 Spark 来说会占用太多的内存可能会导致内存不足；不过，官方表示他们不是所有的 Partition 导出之后才进行导入，而是边读边写，且消耗内存很小。因为我这边已经完成了相关的开发工作，边读边写的操作就留给读者你来实践了。

2.无法支持源 NebulaGraph storaged 地址为 127.0.0.1 的场景（一般属于单机场景），因为 Spark 任务导出的 storaged 地址是通过 metad 元数据获取，就会导致导出任务会请求 127.0.0.1 的 storaged；

3.缺少导出和导入统计，不知道当前已经导出多少数据量；
下面开始进入改造（解决上述问题）部分：

### 导出优化

本次的优化改造的导出优化：将 Partition 进行拆分，改成多线程的方式，每个线程处理一个 Partition。

Nebula2Nebula.scala 改造：增加 readParallel 参数，用于指定多少个线程可同时读取 nebula，控制读取速率，不然可能会对线上服务器照成影响：

```
`val readParallelOption = new Option("rp", "readParallelNum", true, "parallel for read data")
options.addOption(readParallelOption)

val readParallelNum: Int =
      if (cli.hasOption("readParallelNum")) cli.getOptionValue("readParallelNum").toInt else partitions
for (partitionId <- 1 to readPartition) {
      val task = new Runnable {
        def run(): Unit = {
          syncTagPartitionData(spark,
            sourceConfig,
            sourceSpace,
            limit,
            readPartition,
            targetConfig,
            targetSpace,
            batch,
            tag,
            writeParallel,
            user,
            passwd,
            overwrite,
            partitionBatch,
            eachScanWaitTime,
            partitionId
          )
        }
      }
      threadPool.execute(task);
    }`
```

NebulaOptions.scala 改造：增加参数可指定 Partition 读取，代码示例：

```
`var readPartitionId: Int = parameters.getOrElse(READ_PARTITION_ID, 0).toString.toInt`
```


SimpleScanBuilder.scala 改造：


```
`override def planInputPartitions(): Array[InputPartition] = {
 //读取指定的分区
  Array(NebulaPartitionBatch(Array(nebulaOptions.readPartitionId)))
}
case class NebulaPartitionBatch(partitions: Array[Int]) extends InputPartition`
```


NebulaPartitionReaderFactory.scala 改造：读取指定分区数据，代码示例：

```
`class NebulaPartitionReaderFactory(private val nebulaOptions: NebulaOptions,
                                   private val schema: StructType)
    extends PartitionReaderFactory {

  private val LOG: Logger = LoggerFactory.getLogger(this.getClass)

  override def createReader(inputPartition: InputPartition): PartitionReader[InternalRow] = {
    val partitions = inputPartition.asInstanceOf[NebulaPartitionBatch].partitions
    if (DataTypeEnum.VERTEX.toString.equals(nebulaOptions.dataType)) {
      LOG.info(s"Create NebulaVertexPartitionReader partitions:${partitions}")
      new NebulaVertexPartitionReader(partitions, nebulaOptions, schema)
    } else {
      LOG.info(s"Create NebulaEdgePartitionReader partitions:${partitions}")
      new NebulaEdgePartitionReader(partitions, nebulaOptions, schema)
    }
  }
}`

```

### 支持本地地址

下面开始支持导出 storaged 的地址为 127.0.0.1，示例代码参见：

Nebula2Nebula 改造：支持配置源 nebula 的 storaged 连接地址，示例代码见下：

```
`val sourceStorageOption =
      new Option("sourceStorage", "sourceStorageAddress", true, "source nebulagraph storage address")
options.addOption(sourceStorageOption)
NebulaReader.scala 改造：替换原来的 StorageClient，示例代码见下：
this.storageClient = new SpecialStorageClient(nebulaOptions, address.asJava, nebulaOptions.timeout)`
```

增加 SpecialStorageClient.scala: 用于获取 storaged 地址的时候返回指定的 storageAddress，示例代码见下：

```
`class SpecialStorageClient(nebulaOptions: NebulaOptions, addresses: util.List[HostAddress], timeout: Int = 10000, connectionRetry: Int = 3,
                           executionRetry: Int = 3, enableSSL: Boolean = false, sslParam: SSLParam = null)
  extends StorageClient(addresses, timeout, connectionRetry, executionRetry, enableSSL, sslParam) {

  private val LOG: Logger = LoggerFactory.getLogger(this.getClass)

  override def connect(): Boolean = {
    val success = super.connect()
    if (!success) {
      return success
    }
    val storageAddress = nebulaOptions.getStorageAddress
    if (storageAddress.isEmpty) {
      return success
    }
    setStorageAddress(storageAddress)
    LOG.info(s"Set special storage address:${storageAddress.asJava} | value:${nebulaOptions.storageAddress}")
    success
  }

  private def setStorageAddress(storageAddress: ListBuffer[HostAddr]) = {
    val clazz = this.getClass
    var field = classOf[StorageClient].getDeclaredField("metaManager")
    field.setAccessible(true)
    var metaManager = new SpecialStorageMetaManager(addresses, timeout, connectionRetry, executionRetry, enableSSL, sslParam)
    metaManager.setStorageAddress(storageAddress)
    field.set(this, metaManager)
  }
}

class SpecialStorageMetaManager(address: util.List[HostAddress], timeout: Int, connectionRetry: Int,
                                executionRetry: Int, enableSSL: Boolean, sslParam: SSLParam) extends
  MetaManager(address, timeout, connectionRetry, executionRetry, enableSSL, sslParam) {

  private val LOG: Logger = LoggerFactory.getLogger(this.getClass)

  var storageAddress: ListBuffer[HostAddr] = null;

  override def getPartsAlloc(spaceName: String): util.Map[Integer, util.List[HostAddr]] = {
    val partMap: util.Map[Integer, util.List[HostAddr]] = getPartsAlloc(spaceName)
    if (storageAddress != null && !storageAddress.isEmpty) {
      partMap.keySet().forEach(partId => {
        LOG.error(s"Storage partId:${partId} address replace fix value:${storageAddress.asJava}")
        partMap.put(partId, storageAddress.asJava)
      })
    }
    partMap
  }

  override def listHosts(): util.Set[HostAddr] = {
    if (storageAddress != null && !storageAddress.isEmpty) {
      LOG.error(s"[listHosts] Storage address replace fix value:${storageAddress.asJava}")
      return storageAddress.toSet.asJava
    }
    super.listHosts()
  }


  override def getLeader(spaceName: String, part: Int): HostAddr = {
    if (storageAddress != null && !storageAddress.isEmpty) {
      LOG.error(s"[getLeader] Storage address replace fix value:${storageAddress.asJava}")
      return storageAddress.last
    }
    super.getLeader(spaceName, part)
  }

  def setStorageAddress(storageAddress: ListBuffer[HostAddr]): Unit = {
    this.storageAddress = storageAddress
  }
}`
```


### 支持导入打印统计

新增导出导入统计打印，方便知道当前进度。

增加 ReadWriteStats.scala：用于统计，示例代码见下：

```
`object ReadWriteStats {

  private var readCounter = new ConcurrentHashMap[String, Int]();
  private var writeCounter = new ConcurrentHashMap[String, Int]();

  def incrementReadCount(key: String, num: Int): Int = {
    readCounter.compute(key, (_, count) => count + num)
  }

  def getReadCount(key: String): Int = {
    readCounter.getOrDefault(key, 0)
  }

  def incrementWriteCount(key: String, num: Int): Int = {
    writeCounter.compute(key, (_, count) => count + num)
  }

  def getWriteCount(key: String): Int = {
    writeCounter.getOrDefault(key, 0)
  }

}`
```


NebulaReader.scala 改造：增加 scan 读取统计数据输出，示例代码见下：

```
`protected def getRow(): InternalRow = {
    ......
    val totalCount = ReadWriteStats.incrementReadCount(nebulaOptions.label, 1)
    if (totalCount > 10000 && totalCount % 10000 == 0) {
      LOG.info(s"Reader vertex:${nebulaOptions.label} , totalCount:${totalCount}")
    }
    mutableRow
  }

protected def hasNextVertexRow: Boolean = {
    .....
    if (!hashNext) {
      LOG.info(s"Finish read vertex:${nebulaOptions.label} , readTotalCount:${ReadWriteStats.getReadCount(nebulaOptions.label)}")
    }
    hashNext
  }  

protected def hasNextEdgeRow: Boolean = {
    ....
    if (!hashNext) {
      LOG.info(s"Finish read edge:${nebulaOptions.label} , readTotalCount:${ReadWriteStats.getReadCount(nebulaOptions.label)}")
    }
    hashNext
  }`
```

NebulaVertexWriter.scala 改造：增加写入统计数据输出，示例代码见下：

```
`def execute(): Unit = {
    val nebulaVertices = NebulaVertices(propNames, vertices.toList, policy)
    val exec = nebulaOptions.writeMode match {
      case WriteMode.INSERT =>
        val vertexCount = nebulaVertices.values.length
        val totalCount = ReadWriteStats.incrementWriteCount(nebulaOptions.label,vertexCount)
        if (totalCount > nebulaOptions.printRWRowCount && totalCount % nebulaOptions.printRWRowCount == 0) {
          LOG.info(s"Batch insert vertex:${nebulaOptions.label} , count: ${vertexCount} , totalCount:${totalCount}")
        }
        ...
    }
}  

override def commit(): WriterCommitMessage = {
    if (vertices.nonEmpty) {
      execute()
    }
    LOG.error(s"Write vertex:${nebulaOptions.label} task finished. Haven write totalCount:${ReadWriteStats.getWriteCount(nebulaOptions.label)}")
    .....
}`
```


改造完毕之后重新使用 maven 命令打包，再使用 Spark 命令提交任务即可。

这里打包了相关的代码：请点击阅读原文查看，如果你有需要可以拷贝到你的运行环境，自行替换。

以上，感谢你的阅读。

如果本文有任何技术错误，麻烦评论指出，谢谢你的反馈。

## 关于 NebulaGraph  

NebulaGraph 是一款开源的分布式图数据库，自 2019 年开源以来，先后被美团、京东、360 数科、快手、众安金融等多家企业采用，应用在智能推荐、金融风控、数据治理、知识图谱等等应用场景。GitHub 地址：https://github.com/vesoft-inc/nebula

nebula-br 主备集群是通过本地生成 snapshot 备份，然后传输到备集群进行恢复的方式。nebula-spark-connector 主备集群是通过 nebula-client 去 scan nebula 的数据，然后生成 INSERT 语句在备集群进行重放。

使用 nebula-spark-connector 3.6 版本搭建备集群实践

![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-03-28-1.webp.jpg)

在上周，NebulaGraph 的 Star 曲线终于突破 10,000，成为 GitHub 上 3,400 个万星项目之一。在这里感谢社区的所有人，以及所有陪伴 NebulaGraph 一路走来的 Contributor 和技术团队们。是你们，让 NebulaGraph 在今日得以被上万人认可。

“当时市面上已有的图数据库基本上要么是单机版，要么可扩展性不强。在充分了解行业对图数据库的需求，以及认识到现有图数据库产品的不足后，我在 2018 年开始投入研发 NebulaGraph。我们从写下 NebulaGraph 的第一行代码开始就认识到它必须是一款开源的、分布式的、支持线性扩容和高性能的图数据库产品。”

**——来自叶小萌，NebulaGraph 项目发起人在开源三周年的分享**

上述讲话便是 NebulaGraph 在 2019 年 5 月 15 日在 GitHub 同大家首次见面的缘由。开源的当天，上百名开发者们送出了他们的 Star，表达了对 Nebula 的认可和赞许。

![Hello Contributor](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-03-28-2.webp.jpg)

图注：GitHub 的 Star 历史图

## Hello Contributor

众所周知的，对数据库内核做贡献，尤其还是 C++ 开发的数据库，并非一件易事。在开源之初，Nebula 也没想到会有人那么快地开始做贡献。一名来自京东的工程师 ayyt 在同核心开发团队讨论后，确定在绑定套接字时测试使用临时端口而不是硬编码的端口。在随后的 4 个 commit 中，修改了 9 个文件后，他完成了本次的代码贡献，成为第一名非内部的 Contributor。有意思的是，在首次贡献一年多后，ayyt 加入 NebulaGraph 核心开发团队，成为了第 31 号员工。

这里附上第一个外部贡献的 PR 链接：#381（链接：https://github.com/vesoft-inc/nebula/pull/381）

万事开头难，有了第一名外部贡献者，一切就顺利了：

- 2019 年，共计 32 名 Contributor
  - Contributor 新成员：@Amber1990Zhang、@darionyaphet、@0xflotus、@laura-ding、@dutor、@boshengchen、@dangleptr、@ayyt、@zhangguoqing、@sherman-the-tank、@CPWstatic、@critical27、@zlcook、@spacewalkman、@andychow01、@jude-zhu、@wadeliuyi、@whitewum、@boyuanfang、@lilydjwg、@yixinglu、@Shylock-Hg、@moneytoyang、@monadbobo、@BradyBromley、@nianiaJR、@jievince、@liuyu85cn、@wilsonyou、@bright-starry-sky、@jamieliu1023、@doJCHbest

- 2020 年，共计 54 名 Contributor
  - Contributor 新成员：@moeKedama、@Reminiscent、@wfystx、@tong-hao、@Liuxue-Yang、@panda-sheep、@knightXun、@gotoxu、@JaySon-Huang、@xuguruogu、@yetingsky、@nildot、@knightjya、@chenxu14、@GestureWei、@nevermore3、@xs-li、@lorinlee、@liang-Q8797、@charlygao、@Crazyinging、@amosbird

- 2021 年，共计 83 名 Contributor
  - Contributor 新成员：@czpmango、@MMyheart、@LuconYang、@KinhanS、@yihong0618、@sherlockkenan、@Aiee、@wey-gu、@kikimo、@Sophie-Xie、@cangfengzhs、@SuperYoko、@Shinji-IkariG、@HarrisChu、@wenhaocs、@liwenhui-soul、@zhaohaifei、@junaire、@jackwener、@heyanlong、@jsoref、@heroicNeZha、@Nivras、@igrekun、@yyh0808、@jiayuehua、@pengweisong、@luyade、@sworduo

- 2022 年，共计 103 名 Contributor
  - Contributor 新成员：@veezhang、@defp、@a516072575、@wuxiaobai24、@randomJoe211、@dbacyj、@Qiaolin-Yu、@Milittle、@Linary、@xtcyclist、@tian-zhong、@peter-rich、@TommyLemon、@caton-hpg、@180909、@lipzhu、@casualwind、@codesigner、@hezhizhen、@abby-cyber

- 2023 年，共计 111 名 Contributor
  - Contributor 新成员：@tangyuanzhang、@AniketNS、@zhaojunnana、@AntiTopQuark、@songqing、@Koukyosyumei、@flymysqlspace_invader、@Salieri-004

- 至今，共计 114 名 Contributor
  - Contributor 新成员：@Nicole00、@769344359、@visortelle

虽然上面只罗列了 nebula repo 的 114 名贡献者，但随着社区的蓬勃发展，文档、客户端、算法等 repo 的贡献也激增，在 200 多名周边生态 repo 的贡献者的努力下，NebulaGraph 的周边生态变得更丰富、多样。

* 以下 Contributor 排名以字典序进行排序；

![Contributor](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-03-28-3.webp.jpg)

没有我们活力四射的贡献者们的积极贡献，NebulaGraph 不会有今天，拥有 41 个官方发起的项目之余，还有社区用户发起、维护的 30 个实用工具 repo。

## Hello Peer Technical Team

无论是开源还是闭源，寻觅第一个用户（客户）总是困难重重，更别提一个好的、与产品同行的用户。庆幸的是，第一个在线上用 NebulaGraph 的技术团队是 360 数科的大数据团队，至今他们仍然活跃在社区。常在社区活跃的小伙伴，可能看到一个名叫 awang 的 ID，他便是该团队的成员。

独乐乐不如众乐乐，在 360 数科之后，微众也在 NebulaGraph 的深圳 Meetup 同大家分享了他们的数据治理经验 🔗。美团的 NLP 团队的《美团图数据库平台建设及业务实践》 🔗 更是打开了 NebulaGraph 的知名度，一下子社区的用户激增。至今社区用户津津乐道、被上万人阅读过的、图数据库测评之一的《图数据库对比》🔗 则是出自腾讯云安全团队的手笔。

这些都是 NebulaGraph 早期的用户，一直陪伴它走到现在，NebulaGraph 何其有幸。

以下是部分提供 logo 供 NebulaGraph 与大家分享的企业：

![logo](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-03-28-4.webp.jpg)

NebulaGraph 是旨在提供更便捷地探索数据的产品。为此，它致力于降低图数据库的使用门槛，朝着更稳定、高效、易用前行。一路走来，正如大家所见，它在变得越来越好。

如果你想加入 NebulaGraph 核心开发团队，我们在找数据库内核开发（社招、校招、实习生）、数据库产品经理、测试工程师等，发送简历至 hire@vesoft （标注职位+城市）一键投递~

此外，你可以 fork 一份 nebula，开启你的开源之旅；或者是，给一路走路从未停止进步的 NebulaGraph 点个小小的 star：
https://github.com/vesoft-inc/nebula

NebulaGraph 开源五周年预活动——【万星同行】活动正在火热进行中，感谢你的一路同行，记得在这里领取万星同行礼盒和团队技术奖牌哟~ 这边有请：https://discuss.nebula-graph.com.cn/t/topic/15132

NebulaGraph 的 Star 曲线终于突破 10,000，成为 GitHub 上 3,400 个万星项目之一。在这里感谢社区的所有人，以及所有陪伴 NebulaGraph 一路走来的 Contributor 和技术团队们。是你们，让 NebulaGraph 在今日得以被上万人认可。

来自开发者的认可，NebulaGraph Star 突破 10,000 大关

在 LlamaIndex 的 KnowledgeGraph vs VectorStoreIndex vs 混合 Index 结果对比中，提到与 Vector RAG 相比，Graph RAG 更简洁，在 token 开销方面更加便宜。