一、背景

贝壳找房的核心业务场景主要是围绕人、房、客三者的属性与关系展开，是一个典型的图数据库应用场景。而基于此挖掘出的房产领域行业图谱已达到 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 原理、优化以及平台搭建的相关文章，欢迎大家关注，同时也欢迎感兴趣的同学加入我们团队。