在数据库深度挖掘的第三部分中，我们与JanusGraph PMC成员Florian Hockmann和Jason Plurad进行了交流，以获得关于广泛的Graph世界的一些指导。

JanusGraph是一个可扩展的图形数据库，用于存储和查询分布在多机集群中的包含数千亿顶点和边的图形。该项目由Titan出资，并于2017年由Linux基金会(Linux Foundation)开放管理。

阅读下面的文章，从G Data的Florian Hockmann和IBM的Jason Plurad那里了解JanusGraph是如何与Neo4j进行比较的，为什么应该关注TinkerPop 4，并获得关于图形数据建模的专家提示。

跟我们谈谈你自己和你今天在做什么?

弗洛里安·霍克曼(FH):我的名字是弗洛里安·霍克曼，我是德国杀毒软件供应商G DATA的一名研发工程师。我所在的团队负责分析我们每天收到的成千上万的恶意软件样本。我们使用一个图形数据库来存储关于这些恶意软件样本的信息，以便能够在相似的恶意软件样本之间找到连接。

Jason Plurad (JP):我是Jason Plurad，一名开放源码开发人员，也是IBM认知应用程序的倡导者。我一直活跃在像JanusGraph和Apache TinkerPop这样的图形社区中，帮助发展这些开源社区，并使我们的产品团队和客户能够使用图形和其他开源数据技术。我也和我的团队一起探索其他新兴的开源数据和人工智能项目。

你是怎么和JanusGraph合作的?

JP: IBM是JanusGraph的创始成员之一，我是这个团队的一员。我们一直在用它的前身Titan生产几种不同的产品。我们喜欢Titan是因为它的开源许可，以及它在构建整体图形平台方面给予我们的灵活性。

当创建泰坦的Aurelius公司被DataStax收购时，开源社区都在猜测泰坦的未来会是什么样子。最终，DataStax发布了作为DataStax企业一部分的图，但是没有开源选项。我们知道我们并不是唯一想要开源图形数据库的人，所以我们在社区中找到了其他人，一起创建了Titan，并将JanusGraph带到了Linux基金会。

我们最初使用的是泰坦，它是JanusGraph的前身。Titan很适合我们，因为我们正在寻找一个可以水平伸缩的数据库，使我们能够找到恶意软件样本之间的连接，这是一个典型的图形数据库用例。在开发Titan的公司被收购后不久，它就停止了在Titan上的所有工作，我们剩下的数据库系统不再需要维护了。所以，当IBM和其他公司在Titan上创建JanusGraph时，我们当然非常高兴，我们想为这个新项目贡献自己的力量，以确保JanusGraph成功地成为一个可扩展的开源图形数据库。

我已经参与了Apache tinkerpop的开发——主要开发Gremlin. net变体Gremlin。因此，为JanusGraph贡献一个扩展库是很自然的。但我也为项目的其他部分做出了小小的贡献，帮助了邮件列表或*上的新用户。这是一个很好的方式，让我了解这个项目的各个部分，让我更多地参与其中。

在选择Neo4j和JanusGraph时，人们应该知道什么?

JP:人们还应该知道JanusGraph和Neo4j支持Apache TinkerPop图形框架。TinkerPop使您能够使用相同的图结构和Gremlin图遍历语言，使用相同的代码来生成多个图数据库。TinkerPop与许多其他供应商兼容，包括Amazon Neptune、Microsoft Azure Cosmos DB和DataStax Enterprise Graph，不过请记住，许多TinkerPop实现都不是免费的开源的。

这可能不是人们所期望的答案，但是团队应该与他们的律师一起评估许可证，以确定哪种许可证适合他们的需要。JanusGraph使用Apache许可证，这是一个*的开放源码许可证，允许您使用它几乎没有限制。Neo4j Community Edition使用GNU通用公共许可证，该许可证对发布软件有更严格的要求。许多开发人员最终需要Neo4j企业版提供的可伸缩性和可用性特性，而Neo4j企业版需要商业订阅许可证。

FH:我认为这两种图形数据库之间主要存在两个区别因素。首先，Neo4j基本上是一个自包含的项目。我这么说的意思是，它实现了自己的存储引擎、索引、服务器组件、网络协议和查询语言。

另一方面，JanusGraph在这些方面的大部分都依赖于第三方项目。这背后的原因是，对于这些问题，已经有了适合其具体工作的解决方案。通过使用它们，JanusGraph可以真正专注于图形方面，而不必再去解决这些问题。

例如，JanusGraph可以使用Elasticsearch或Apache Solr实现高级索引功能(如全文搜索)，并使用可伸缩数据库(如Apache Cassandra或HBase)存储数据。正因为如此，使用Neo4j可能更容易上手，因为涉及的移动部件更少，但是JanusGraph提供了更大的灵活性，用户可以根据自己的特定需求在不同的存储和索引后端之间进行选择。用户可以自己决定他们喜欢哪种方法。

我看到的其他关键区别因素是这两个图形数据库面向用户的界面，查询语言是其中的中心方面。JanusGraph为此实现了TinkerPop(它可以被认为是图形数据库事实上的标准，因为目前大多数图形数据库都实现了它)，它为用户提供了跨越不同图形数据库的基本相同的体验，类似于SQL在关系数据库中扮演的角色。

虽然也可以将TinkerPop及其查询语言Gremlin和Neo4j一起使用，但Neo4j主要是促进它们自己的查询语言——cipher。因此，大多数Neo4j用户最终可能会使用这种语言。

当然，用户必须再次自己决定他们更喜欢哪种查询语言，Gremlin还是Cipher，以及能够在将来的某个时候轻松切换到另一个图形数据库对他们来说有多重要。

当然，除了这些技术方面，我还想指出JanusGraph是一个完全由社区驱动的开源项目。因此，希望看到某个特性实现的用户可以自己实现它。

对于想要在生产环境中部署JanusGraph的人，您有什么建议?

FH:我已经提到JanusGraph使用几个不同的组件来创建图形数据库，它提供了丰富的功能，比如索引和存储引擎。虽然这种方法为用户提供了极大的灵活性和丰富的特性集，但它也可能让新用户感到有些难以承受。

但是，我想指出，开始使用JanusGraph并不需要对所有组件都有深入的了解。当我开始使用泰坦的时候——基本上和janusgraph一样——我对Cassandra和Elasticsearch一无所知，但我仍然能够通过这些后端快速地安装和部署泰坦。

多年来，我们从Cassandra切换到Scylla，添加了用于机器学习的Apache Spark，并通过将JanusGraph移动到Docker容器中，使我们的部署更易于扩展。

因此，我的建议是先进行小型而简单的部署，然后根据需要增加部署的规模和复杂性。JanusGraph的文档还包含“部署场景”一章，描述了一个相对简单的开始场景，以及如何将其发展成更高级的场景。

另一个对JanusGraph非常重要的项目是TinkerPop，我已经提到过几次了。因此，我建议新用户熟悉TinkerPop，最重要的是，熟悉它的图形查询语言Gremlin。有很多很好的资源可以帮助你入门，比如TinkerPop的教程或者免费的电子书Practical Gremlin。

JP:首先，也是最重要的，准备好完全接受开源并为之做出贡献。JanusGraph是一个社区项目，它不是由单个供应商拥有或驱动的。您的团队应该与JanusGraph社区合作，识别并解决您遇到的bug，因为您最有动力去修复它们。随着时间的推移，通过持续的贡献，您的团队可以成为JanusGraph的领导者，帮助推动项目向前发展。在团队进入生产阶段时，操作可能是一个大障碍。当您在处理团队可能尚未熟悉的大量技术时，您应该花足够的精力来理解如何保持数据基础设施正常运行。由于JanusGraph依赖于外部存储后端(如Apache Cassandra或Apache HBase)，最终，您的团队将需要部署和操作那些水平可扩展数据库及其依赖关系的技能。当然，您也应该参与这些开源社区。

在接下来的几年里，你对JanusGraph和TinkerPop有什么期待?

帕森斯:我从事图形数据领域已经好几年了，但它仍处于新兴阶段。在接下来的几年里，我很乐意看到图形生态系统中工具的改进。这将包括用于图形建模、图形可视化和图形数据库操作的工具。

在总体数据体系结构中，图通常不是唯一的，因此能够在图数据和其他数据模型之间架起桥梁的工具将有助于推动图数据进入主流。

今年，W3C对图形数据(包括属性图、RDF和SQL)的标准化越来越感兴趣。有了图形数据的开放标准规范，图形数据库供应商就可以更好地提高它们在数据库市场上的份额。

FH:特别是对于JanusGraph来说，很难预测未来的发展，因为这个项目完全是由社区驱动的，而且很多贡献都来自于那些对JanusGraph感兴趣的用户，他们希望根据自己的经验和需求来改进JanusGraph。

除了许多小的性能改进之外，JanusGraph很可能很快就会有一个性能得到显著改善的内存后端，也可以用于生产使用，而不是目前的内存后端，后者仅用于测试目的。这个改进后的后端是JanusGraph用户做出贡献的一个很好的例子，在这个例子中是高盛的开发人员。

总的来说，我希望JanusGraph在接下来的几年里在后端有实质性的改进。当然，我们只是从新发布的后端本身的改进中获益，但是全新的后端也可以为JanusGraph提供巨大的改进或全新的功能。

例如，FoundationDB看起来非常有前途，因为它完全专注于实现一个可伸缩的存储引擎，提供具有ACID属性的事务，而其他层可以添加丰富的数据模型或高级索引功能等特性。这种方法似乎很适合JanusGraph的模块化架构，并且有可能解决JanusGraph的一些常见问题，比如存储超级节点或执行升级。

但是，很高兴你还提到了TinkerPop，因为JanusGraph的许多改进实际上来自TinkerPop，尤其是下一个主要版本TinkerPop 4的发布。

TinkerPop 4的开发仍处于非常早期的状态，但是一些主要的改进已经可以确定了。我个人尤其期待的是为Gremlin遍历提供更广泛的执行引擎。现在，人们可以选择使用单个线程执行遍历(这非常适合实时使用情况)，或者在使用Spark的计算集群上执行遍历(例如，用于机器学习或图形分析)。

在G数据,我们往往用例在中间的这两个选项,因为他们应该回答的几秒也不太可能引发,因为它有一些空中他们涉及穿越大量的边缘,也不是一个适合单线程执行。一个额外的执行引擎能够使用更多的计算资源，但不需要首先加载整个图，它可能非常适合这些用例。

目前，人们还花费了大量精力为TinkerPop创建一个更抽象的数据模型，该模型并不特定于图形。这有可能使TinkerPop也可以用于非图形数据库和计算引擎。所以，它真的可以增加支持tinkerpop的数据库的生态系统。

你有什么提示或技巧的性能图形建模?

FH:这可能听起来很明显，但我认为许多用户仍然没有这样做——即在将模式投入生产之前评估新的模式或对其进行重大更改。

如果可能的话，应该使用真实的数据来完成，并且评估应该包括建模实际用例的查询。确实没有其他方法可以确保您的模式实际上很好地适合您的用例，并且在生产后期更改模式要比进行初始评估花费更多的时间。

对于所有的图形数据库来说，超级节点是一个非常重要的主题，因为超级节点非常麻烦，并且会导致非常高的查询执行时间。因此，最好尽早检查数据模型中是否会出现超级节点，然后绕过它们，例如，通过相应地更改模式。

对于图模型，另一个需要考虑的问题是，某个东西是否应该是一个顶点上的属性，还是它自己连接到另一个带边的顶点上的另一个顶点。我通常的方法是决定我是否希望能够搜索具有相同属性值的其他顶点，在这种情况下，我将它建模为自己的顶点，用边将它连接到所有具有该值的顶点。否则，它通常只能是一个顶点属性。

JP:图形建模需要时间。从一个幼稚的图形模型开始是很容易的，但是，您很可能不会在第一次尝试时就得到最好的模型。通常需要几次迭代才能得到适合您的用例的模型。

准备好使用您的域的一个小的代表性数据集和您想要运行的查询列表，这样您就可以看到模型对您的用例的执行情况。当您从一个顶点跳到另一个顶点时，请密切关注分支因子。即使给定顶点上有合理数量的边，查询将触及的图元素的数量也会随着几次跳跃呈指数增长。考虑将图结构反规范化，这样就可以更好地利用过滤(在标签或属性上匹配)来减少查询早期的元素数量。

怎样才能和JanusGraph联系起来呢?

FH:这取决于您是想贡献代码、改进文档，还是想以其他方式提供帮助，比如帮助邮件中遇到问题并知道如何解决的其他用户。

对于代码或文档更改，您可以在GitHub上查看我们的开放问题，找到您感兴趣的，或者创建一个新问题来描述建议的改进，然后提交一个pull request。

这与其他开源项目没有什么不同。可能JanusGraph新的贡献者的一个优点是,它由很多不同的模块,还有一个广泛的话题作出贡献,卡桑德拉等一些特定于某个后端或Elasticsearch核心领域像如何执行一个查询工具方面JanusGraph像模式管理或客户端库在一定的编程语言。所以，你可以选择一个你已经了解或感兴趣的领域来做贡献。

如果有人有兴趣为JanusGraph做贡献，但需要一些指导才能开始，那么当然总是可以问我或其他积极贡献者，我们非常乐意帮助。

JP: JanusGraph是一个开放的社区，我们社区的多样性帮助推动了这个项目向许多新的方向发展。我们的社区为扩展JanusGraph做出了坚实的贡献，为不同的编程语言提供了驱动程序，为不同的数据库后端提供了存储适配器。

我们IBM的开发人员将贡献的特性返回到开源服务器，用于服务器上的动态图形管理。我们已经收到了对构建和测试基础设施的改进，以及与Docker和Apache Ambari的集成。

我们希望看到更多的人参与进来，除了编写源代码之外，还有很多方法可以提供帮助。我认为作为一个协作社区，人们分享他们的知识和经验是最重要的——通过在论坛上回答问题，通过更新JanusGraph文档，通过以创新的方式构建使用JanusGraph的示例项目，通过在JanusGraph的本地会议或会议上展示。