同花顺知识图谱数据库选型 — 金融海量数据毫秒级响应查询

1,560 阅读8分钟

本文整理自同花顺知识图谱团队在 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 国际》许可协议