贝壳找房—【图数据库系列】之 JanusGraph VS Dgraph:贝壳分布式图数据库技术选型之路

一、背景

贝壳找房的核心业务场景主要是围绕人、房、客三者的属性与关系展开,是一个典型的图数据库应用场景。而基于此挖掘出的房产领域行业图谱已达到 500 亿三元组的量级。面对如此海量的数据,应该如何存储才能支持业务的高效查询?我们迫切需要一个高性能、高可用、可扩展的分布式图数据库平台。

二、图数据库简介

什么是图数据库

图数据库并非存储图片的数据库,而是应用图形理论存储实体之间关系信息的一种 NoSQL 数据库,以图的结果存储和查询。比如社会网络中人与人之间的关系,房产领域中客户、经纪人和房子之间的关系等。

应用场景

图数据库的应用场景非常广阔,除了我们熟知的社交网络、计算机网络外,还有比如以下各种场景:

  • 道路网络、电信网络
  • 关联查询、搜索推荐
  • 风险预测、风控管理
  • 业务流程、生物流程
  • 公司或市场结构
  • 事件及其之间的因果关系或其他联系

三、图数据库技术选型

图数据库的产品其实有很多,那么我们应该选择哪一款呢?

要回答上面的问题,首先我们需要知道当我们做技术选型时,我们主要关注哪些因素:

基于以上几个标准,我们对上面的图数据库进行了粗略的筛选并对主流的 5 款进行了简要对比:

通过简单调研发现,JanusGraph 和 Dgraph 是对分布式支持比较好的,因为它们从设计之初就是按分布式架构设计的,并且是完全开源免费的,所以我们主要对这两款图数据库进行了详细的评测对比。

四、JanusGraph VS Dgraph

先看一下 JanusGraph 的架构图:



可以看出 JanusGraph 的存储依赖于第三方的分布式存储系统,比如 Cassandra 或 Hbase,索引也依赖于 ES 或 Solr,运维成本较高,不可控性也更大,但其和大数据生态结合的较好,可以方便的使用 Spark 进行复杂的图计算。

Dgraph 架构图:

而 Dgraph 不依赖与任何第三方系统,只有一个 Dgraph 可执行文件,只需在启动时通过参数指定是 Zero(管理节点)还是 Alpha(数据节点)即可,Dgraph 会自动组成集群,运维部署非常简单。

单从架构上看,Dgraph 比 JanusGraph 的运维成本低很多,但是也不能只因为这一点就直接选择 Dgraph,因为如果 JanusGraph 的各方面性能都比 Dgraph 高很多,那额外的运维成本也是可以接受的,所以二者的性能对比数据又是怎样的呢?

如上,我们使用同一份数据,相同的机器,对二者在各种场景下的读写性能进行了详细的评测,最后发现对于简单查询,Dgraph 和 JanusGraph 性能差不多,但复杂查询下,Dgraph 性能远高于 JanusGraph。同时,Dgraph 的写入性能也整体高于 janusGraph。

五、 结论

总结对比一下:

通过各方面的评测,Dgraph 除了运维成本低之外,整体读写性能也优于 JanusGraph,所以最终我们选择了 Dgraph 作为贝壳图数据库平台的基础引擎。

当然也不是说 Dgraph 是一个完美无缺的图数据库,它也有不足之处,比如还不支持多重边、一个集群只支持一个图、与大数据生态兼容不足等,这些都需要靠后期不断完善。我们选择 Dgraph 更多是因为在我们的当前的业务场景下,它是最适合的。所有其实大部分时候都没有最完美的方案,只有最适合的方案,大家进行技术选型的时候需要更多的考虑当前的业务场景。

六、 后记

技术选型只是第一步,确定选型之后,我们需要在 Dgraph 的基础上搭建完整的图数据库平台,以便给所有有图数据库需求的同学提供高效、稳定、易用的统一平台,降低大家的技术成本,让上层做图谱的同学可以更专注于策略或算法,而不需要再花精力去关注底层的存储技术和性能优化等。

所以本篇文章是图数据库平台的第一篇文章,后续我们还会持续发布关于 Dgraph 原理、优化以及平台搭建的相关文章,欢迎大家关注,同时也欢迎感兴趣的同学加入我们团队。


本文地址:https://www.6aiq.com/article/1586913224622
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出