背景
图数据库是使用图结构进行语义查询的数据库，使用节点、边和属性来表示和存储数据，它能够支持海量复杂数据的关系运算，而传统关系型数据库很难处理复杂的关系运算。关于图数据库和关系型数据库的在查询复杂关系数据方面的对比，Neo4j 公司在社交场景里做了传统关系型数据库 MySQL 和图数据库 Neo4j 的查询性能对比 ，在一个包含 100 万人、每人约有 50 个朋友的社交网络里找最大深度为 5 的朋友的朋友，实验结果如下：
上述结果可以看出，对于图数据库而言，数据量越大，越复杂的关联查询，性能上越有优势，当深度为4/5的查询时，图数据库返回了整个社交网络超过一半的人数。
图数据库使用图的方式对场景建模，便于描述复杂关系，在社交、电商、金融、零售、物联网等行业或领域都有广泛的应用，在推荐的业务场景里，图数据库也有非常大的应用潜力，我们的算法业务团队方最近也有此类的业务需求和场景：
- 关系网络分析，这方面场景主要是查询N度好友。
- 信息传播路径分析，这方面场景主要是查询图的最短路径。
- 相似性推荐，这方面需求主要是挖掘一些相似节点，比如用户A播放了歌曲"冰雨"，从"冰雨"这首歌的属性值拿到歌手"刘德华"，然后检索歌手"刘德华"的其他歌曲，这个是一种最简单的相似节点场景。
- 推荐多样性，这方面场景主要是根据用户网络、内容网络进行多样性推荐，最简单的比如内容找人。
基于该背景，我们调研了业界开源的图数据库，参考的主要指标如分布式扩展能力、数据存储规模、Bulkload能力、查询延迟等，最终选择了nebula图数据库，它的分布式能力、千亿级点边支持、存储计算优化等方面都非常优秀，我们在业务的小规模场景进行了应用，本文主要对nebula本身做一个初步介绍。
架构设计
如上图，完整的 Nebula 集群包含三种服务，即 Query Service、Storage Service、Meta Service，从架构上来讲，Nebula是典型的存储计算分离架构。
Query Service属于计算层，每个查询计算引擎都能接收客户端的请求，解析查询语句，生成抽象语法树（AST）并将 AST 传递给执行计划器和优化器，最后再交由执行器执行。
Storage Service属于存储层，它采用典型的shared-nothing 设计，包含了多个partition，每个partition基于多数派协议 Raft 来保证数据存储的一致性，点和边都是基于vertex_id进行hash路由的。
Meta Service主要负责元数据管理，它主要负责存储和提供图数据的meta信息，如schema、partition信息等，基于Raft实现数据强一致，此外，它还负责管理数据迁移及leader的变更等操作。
集群部署
我们以源码方式编译安装nebula图数据库，nebula版本为v2.6.1，安装环境：CentOS Linux release 7.8.2003 (Core)、gcc version 7.5.0 (GCC)，编译方式其实很简单，如下所示：
[root@localhost nebula]# mkdir build && cd build
[root@localhost build]# cmake ..
[root@localhost build]# make && make install
单机部署
单机部署很简单，在nebula安装目录的etc目录下拷贝其中的default配置，创建graphd、metad、storaged配置文件，然后直接启动即可，如下所示：
集群部署
我们以在三台机器部署集群为例，storaged和metad在三台机器部署，graphd在一台机器部署。
应用样例
我们以nebula手册中提供的数据集basketballplayer为例，创建了如下Tag和Edge类型：
在basketballplayer数据集中，创建了若干球员、球队的实体，建立了球员与球队的serve关系、球员与球员的follow关系，我们以一些实际的操作案例来说明图数据库能解决的一些问题：
- 检索名字为Tim Duncan的球员：
2. player101的球员，follow了哪些球员，对应的球员id、name和degress：
3. 有哪些球员关注了player100球员：
4. player101的球员，关注了哪些球员及这些球员serve的team信息：
5. 返回距离player102两跳的朋友：
6. player101球员follow了几个球员：
上述的几个样例，我们只是简单的介绍了下图数据库的应用，主要是用于展示图数据库的一些基本能力，更复杂的应用大家可以关注和了解下nebula的文档。
性能
关于性能这块，我们只对nebula做了一些初步的和简单的测试，3节点组成的集群轻松支持1万+的QPS，查询延迟基本在毫秒级，性能上完全满足需求，由于在可见的时间里，业务量级会一直是个比较小的规模，业务量级大概2亿顶点1亿边，读的QPS不超过2000，性能方面完全可以满足需求，性能方面的优先级不高，因此我们暂未对nebula做全方面的压测，这部分工作在后续我们会根据实际情况补充。
虽然我们暂未对nebula做完整的性能压测，不过大规模数据场景下的性能，nebula优势明显，这点我们也参考了其他同学的性能测试和对比结果：
可以看到，在数据规模增加的时候，Nebula在数据导入、查询性能方面均有比较明显的优势。
总结
技术的目的是服务于业务，从而产生技术的价值，在我们的场景里，业务规模非常的小，理论上采用neo4j是更好的选择，相比nebula而言，虽然neo4j开源版本不支持分布式，但neo4j各种配套都非常完善，而nebula的周边工具还所有不足，且在2亿点1亿边这种量级的小规模场景，两者性能不会有明显差异，但我们依然选择调研nebula，最主要的原因是在于，从长远考虑，nebula的架构、分布式能力、大规模数据存储能力会给业务带来很大的收益，在业务规模还不大的时候，我们需要为然后大规模量级的业务接入打好基础、做好技术沉淀和准备。
在本文里，我们主要对nebula图数据库做了一个初步介绍，后续我们会对nebula图数据库的源码进行研究，以根据业务需求实现定制版本的图数据库服务，一方面解决业务可能出现的底层瓶颈问题，两一方面达到效率提升和减少资源的目的。