本文整理自同花顺知识图谱团队在 nMeetup·杭州场的演讲

这次分享主要站在（意向）用户角度讲下技术团队选择数据库产品时，会有哪些考量点。在同花顺知识图谱团队开启知识图谱战略之后，一开始使用的是 Neo4j，但在使用过程中发现随着金融业务的增长，Neo4j 并不能很好地应对增长的业务。所以，技术团队出了一个解决方案：数据库和应用层之间增加多级缓存。虽然缓存能一定程度缓解问题提升性能，但是它其实会引发更多的问题。

于是，我们开始思考有没有一款图数据库能满足目前的业务需求之外，还能应对未来的业务增长。至此，知识图谱团队开始了选型之旅。

如何选图数据库

选型这块，主要分为了：How 怎么选、What 选什么、Why 为什么这三部分内容，此外最后讲述下同花顺这块的知识图谱团队和团队业务。

选型依据这块，主要分为：

• 功能强大：具备极佳的性能
• 商用成熟：产品成熟
• 社区活跃
• 数据量大：能应对目前的业务量，以及未来的业务增长
• 开源优先
• 技术支持
• 国产优先

选图数据库和选股票类似，我们会考虑一些消息面、基本面和技术面，当然二者之间还是有区别的。图数据库的三面主要是下面几点：

• 消息面：是否满足选型依据
• 基本面：是否能够稳定持久
• 技术面：是否达到技术要求

消息面

在图数据库消息面这块，一般我们会上一个网站：DB-Engine，可以看到排名第一的是 Neo4j，毕竟是最早的一款图数据库相对成熟。一圈调研下来，发现他们营销做得不错：在百度或者 Google 上面搜索图数据库，就能看到他们的广告。

在这个 DB-Engine 排名上，可以看到其他的像是比较出名的（排名第七）JanusGraph，我们如何在这么多的数据库中确定我们最终使用的数据库呢？

插个题外话，这里说下 DB-Engine 的排名规则，它的排序依据是 Google、Bing 搜索引擎的搜索结果，Google Trends 里的关键词趋势，像 Stack Overflow、DBA Stack Exchange 上的讨论，Indeed 之类的招聘网站的招聘数，Linkedin 里的职位数以及社交网络主要是 Twitter 的讨论量。

我们可以发现一个问题：上面的网站要么是国内无法访问的或者是相对小众的网站。

所以 DB-Engine 上面的排名，对国内的一些产品来说，其实是有失偏颇的，至少它的数据肯定是不能反映它的一些真实情况的。如果考虑到国内的一些使用情况的话，这 DB-Engine 里百度出品的 HugeGraph，以及 Nebula Graph 排名肯定是要上升好多档。

说完 DB-Engine，再说下我们针对 DB-Engine 上的信息做得简单筛选：

上面这些数据库从消息面上是不满足同花顺知识图谱团队的需求。而这份结果也再次证明了 DB-Engine 的排名结果并非精准，比如：排名在 Nebula Graph 之上的一些数据库已经是一些不活跃、不再更新的产品了。以上截图信息都来源于 DB-Engine 公开信息。

基本面

经过消息面之后，我们筛选出了 Neo4j、Orient DB、Dgraph、JanusGraph、HugeGraph、Nebula 等 6 款图数据库产品，这 6 款产品相对活跃，支持多语言。

按照产品的最早发布时间，排在最前面的是 07 年发布的 Neo4j，然后依次是 OrientDB、Dgraph、JanusGraph、HugeGraph，以及 19 年发布的 Nebula Graph。排名越靠前的数据库产品，它的支持语言程度越高，系统功能也会相对更加完善。这块也是“后起之秀”新数据库需要去完善、改进的地方。

而像 HugeGraph、Neo4j 很多产品功能只是在商业版本（企业版）才会支持，我们还需要了解他们的商用版本内容以及报价。

上面这张图比较有意思，它指出了各类图数据库在不同场景下支持的数量级：比如 Neo4j 是支持十亿的点、万亿的边，毫秒级的响应时间。OrientDB 的数据就比较有意思了，支持无限量级的数据，我不知道它是如何做到这个数值。Dgraph 并没有明确数据量情况，只是说提供了一个 Google 生产级别的数据，支持实时查询，以及 TB 级别的结构化数据。

后面两款一个是百度开源的 HugeGraph，一个 Nebula Graph，Nebula 这边还是比较占优势的——它提供千亿级别、万亿边关系的数据量支持情况。

技术面

经过消息面、基本面，其实没有一个非常明确的胜出者。我们看下技术面这块，由于 HugeGraph 和 JanusGraph 架构类似，OrientDB 技术支持一般，所以在技术面这块我们着重考察：Neo4j、HugeGraph、Nebula Graph 这 3 款图数据库。

Neo4j 只支持同构部署，不支持异构部署，所以不能发挥每台机器的特异性，比如：有的机器它可能是计算型的，有的机器 IO 强，如果按照 Neo4j 的部署设定，这就要求每台机器情况等同。Neo4j 的分析能力和性能提升，主要依靠两个 Fabric 组成的虚拟机提供区域分区能力（上图绿色部分）。

在架构层面，Nebula Graph 和 HugeGraph 的存储计算分离的架构更有优势，至少使用者可以针对业务部门的实际情况搭配机器配置。

HugeGraph 在存储这块支持多种存储引擎，可对接多种第三方引擎，然后在此基础之上加上了一个计算框架，在计算框架之上是接口层，例如：Huge Console、Huge Loader 等等。

在计算这块，主要基于底部的存储引擎提供了 OLTP 和 OLAP 能力。这里 HugeGraph 的存储引擎不是用自己的存储引擎，主要还是依赖于其他的存储引擎，这里可能不如 Nebula 用自己的存储引擎。举个例子，我们用的第三方存储引擎是 HBase，HBase 的实时性是非常差的，这时候用它做存储引擎就会影响到上一层的性能。

Nebula Graph 这里也是一个存储和计算分离的一个架构，每一层都可无限扩展，你的存储不够就加存储，计算不够就加计算，相对而言还是一个比较先进的架构。

讲完架构之后，同花顺这边参考了其他技术团队的测试结果：

这是腾讯云安全团队在 v1.x 版本的性能测试。

这是美团 NLP 团队做的 Nebula、Dgraph、HugeGraph 的性能对比：在这里，HugeGraph 的存储引擎用的是 HBase，而 Dgraph 和 Nebula Graph 用的是 RocksDB，就像之前说的那样 HBase 在实时性这块是一个短板。如果数据库存储引擎层面，3 个数据库都是用的 KV 存储引擎的话，结果不会产生如此大的一个量级差距；

下面是同花顺的一个性能测试结果：我们不仅对比不同图数据库，还对比了 Nebula Graph 两种查询语言（原生 nGQL 和兼容 openCypher 的 nGQL）。

从数据上可以看到原生的查询语言 nGQL 会表现更好点（上图的 nebula-ngql 和 nebula-cypher）。而在多跳查询中，可以看到基本上在 5 跳以上的查询，Neo4j 都是处于一个超时的状态。

在性能上，Nebula 相对 Neo4j 还是有比较大性能优势的。

综合考虑架构、性能、社区支持情况等等因素，我们还是会选择更适合我们的图数据库——Nebula Graph。虽然在使用的过程中发现了一些小问题：

• 不支持中文标识符
• 语法错误提示不友好
• Java 不支持参数化查询
• GO 查询必须指定起点 ID

但，总的来说还是满足我们的业务要求的。

同花顺·知识图谱团队介绍

最后来介绍下我们的团队——同花顺知识图谱团队，主要面向的业务是：智能对话、推荐系统、搜索引擎、投资策略以及多模融合、股票亮点、投顾投教这样的一些业务，后面可能接入更多的业务场景。

当前我们维护了这么几个图谱，一个是产业链的图谱，就是数据来源于一些公开的数据。通过语义抽取，构建出来的产业链图谱；

还有供应链图谱。

人物关系图谱

以及企业图谱

从而满足同花顺这边金融投资的需求。

声明：本作品系原创，采用《署名-非商业使用-禁止演绎4.0国际》许可协议