书摘和采访：图数据库

《图数据库》的作者是Ian Robinson、Jim Webber 和Emil Eifrém，讲述了基于图的NoSQL 数据库技术，以及在现实世界的应用程序中可以用来存储“相关联的数据”的不同方法。作者们讨论了很多主题，像使用基于图的领域模型来进行数据建模，以及使用图理论的技术来进行预测性分析等。

InfoQ 采访了书的合作者 Ian Robinson 和 Jim Webber，谈到了这本书、图数据库在 NoSQL 数据库领域的角色，以及图数据库的将来等问题。

InfoQ：恭喜你们写出了新书。这本书当前进展如何？

Ian and Jim：多谢 Srini！ 这本书是在去年撰写的，从粗剪版到最后花费了大概八个月时间。我们现在和 O’Reilly 正在进行最后的编辑阶段，所有工作会在六月十日完成。我们会向今年 GraphConnect 会议以及很多 Neo4j 社区活动的参与者发放。

InfoQ：和关系型数据库以及其他 NoSQL 数据库相比，图数据库表现如何？

Ian and Jim：Alistair Jones 创造了一个术语“关系型十字路口（relational crossroads）”来描述它们之间的区别。据 Alistair 所说，我们正处在分岔路口。一条路通往大多数 NoSQL 数据库所采用的方法，其中数据被严重非范式化，然后我们依赖于应用程序来把它们组合在一起，以得到进一步的见解，那通常需要很高的延迟。另一条路通往图数据库所采用的方法，其中我们使用图的强大表现能力来为手头的问题构建灵活的、相互连接的模型，然后可以用低延迟的方式查询以获得更深理解。

关系型数据库处于二者之间。和图数据库更相似的是，关系型数据库拥有以查询为中心的模型。但这个模型并没有图数据库那样强大。特别是，它缺乏在运行时创建任意广泛、语义上丰富并且连接可变的结构的能力。为了在关系型数据库中创建任何一种可扩展的结构，我们都需要预先对我们的连接做出计划。为了使其可变，我们最终会创建大量可空的列。结果是：稀疏的表，昂贵的连接，以及对象 - 关系阻抗（object-relational impedance）问题，即便是在非常简单的应用中使用也是一样。

InfoQ：图数据库最适用于什么样的用例？

Ian and Jim：和关系型数据库一样，图数据库主要针对于 OLTP 数据库，并可以应用在很广泛的解决方案中。也就是说，当问题的解决方案依赖于我们首先理解事物是如何连接的时候，它们会非常有效。这要比你所想象的更加常见。在很多情况下，不仅关系本身很重要，同时关系的名称、紧密程度以及关系权重也非常重要。

简言之，连接是关键所在。对于为连接建模和对其进行查询来说，图是最佳的抽象形式；因此，图数据库让应用程序开发者和数据专家可以把这种抽象应用到他们自己的特定问题中。直到最后，我们看到它们用于社交网络、推荐引擎、授权和访问控制、寻径和后勤、产品分类、数据中心管理、职业管理、诈骗检测、制定政策、地理空间甚至是移民的应用程序。把所有这些解决方案绑定在一起的关键点在于，它们依赖于能够对相关联的数据建模和查询。仅仅拥有键和值是不够的；拥有通过在语义上改善后的连接关联在一起的数据也不够。我们既需要连接，也需要丰富的上下文，才能够让这些解决方案生效。

InfoQ：你可否告诉大家，当使用图数据库的时候，开发者需要记在头脑中的关于设计的考虑有哪些？

Ian and Jim：对于任意的特定应用来说，最重要的设计决定都会关注数据模型和查询。正如我们在书中所描述的，此处的关键是让数据提出的、你需要回答的问题来驱动你的模型。你可以发现应用程序目的的核心或者最终用户的需求，从而确定你感兴趣的内容，以及它们是如何连接的。接下来是一个简短的步骤，我们要把这些问题转换成可表达的图模型，然后转换到你要对模型执行的查询之中。

得到的模型和相关联的查询都是你想要对数据要提出的问题的投影。使用 Neo4j 的 Cypher 查询语言，这些投影的互补特性会变得非常明显：你用来创建图结构的路径和你用来查询的路径是相同的。

作为对你设计的很好的第一次测试，你应该可以读懂自己编写的内容。最重要的是，你应该能够读懂你写入的问题，而不需要做出任何额外的假设和推断。像“(Emil)-[:WROTE]->(Graph Databases)<-[:PUBLISHED]-(O’Reilly)”这样的结构很易读，并清晰地帮助我们回答了以下问题：“Emil 写了那些书？”，“谁出版了《图数据库》？”以及“Emil 为哪家出版社写了书？”。

InfoQ：图数据库支持哪些架构和设计模式？

Ian and Jim：这个问题和图数据库并没有太大关系，它们只是数据库，只是对于连接的数据，它的执行速度更快一些。所以任意你想要采用的应用程序模式都会有效。你喜欢 MVC？ 当然，那很适合。你想要完全工作在带有回调的 JavaScript 中？ 没问题，对 Neo4j 有很棒的 Node.js 连接程序。

InfoQ：图数据库本身在可伸缩性方面有什么限制吗？

Ian and Jim：当我们谈到伸缩的时候，实际上是在谈三种不同的东西：为大型数据集伸缩、为读取性能伸缩以及为写入性能伸缩。

关于为大型数据集伸缩 ，没有任何固有的限制。Neo4j 当前对图的大小方面有个固定上限（大概是 10 的 10 次方，这对于支持我们在现实世界中能够看到的大多数图都足够，包括一个 Neo4j 部署，它在一个 Neo4j 簇集中拥有超过一半的 Facebook 社交图），但这项限制会在本年稍后取消。这会解除人们的顾虑，可以放心地为“大”数据对图进行缩放。

为读取伸缩同样没有表现出任何问题。当前，在 Neo4j 中，这是通过主从复制完成的。读取请求会在簇集间做负载平衡，其中它们会针对本地数据执行，它的结构已经针对连接查询做过优化。除了事务透明性之外，Neo4j 在历史上一直关注读取的性能。为了支持快速读取，我们拥有本地图的栈，一直到磁盘中。某些其他图存储通过非本地的图存储——像列存储——提供了图接口。这可能对其他缩放特征有所帮助，但它很可能会提高查询的延迟，因为连接是在库代码中执行的，而不是在数据模型的层次执行的。

为写入伸缩可以通过垂直缩放达到，但在有些时候，对于非常严重的写入负载，就需要跨多台计算机分发数据的能力。这真的是一种挑战。尽管分发数据会有助于提高写入性能，但也会对读取性能造成不利的影响。迄今为止，还没有人实现出一种图数据库，可以优化，并解决本地遍历速度快，而分布式遍历（通过网络）速度慢的问题。

通过跨多台计算机分发图数据来对其进行伸缩，要比伸缩一些简单的数据模型困难得多，但还是可以实现的。伸缩键 - 值、列族或者文档存储相对容易，因为在那些情况下，你处理的是离散的聚合，可以完全放在某个位置。缩放一个图要更困难，因为它的数据天生就是相互连接的。当分发一个图的时候，我们想要尽可能避免出现跨计算机的关系；这叫做最小点切问题（minimum point-cut problem）。在平衡图从而有尽可能少的跨计算机的关系的问题之上，情况会变得更复杂，因为图总是在变化。一个时间点看起来像是很好的分发的情况，可能几秒钟之后就不再是优化的方案了。这一般叫做 NP 困难问题。

尽管我们无法声称已经解决了 NP 困难的一般图分区问题，但我们已经找到一些不错的方法来回避它。事实上，我们现在已经让 R&D 团队忙于试验这些想法，在将来的某个时刻，他们会加入到未来的产品版本中。另外，我们还有一些现成的技巧，可以使用现有的技术来提高写入伸缩限制。

所以，为了回答这个问题，我们会说图中数据相互连接的本质为通过分发图来伸缩写入带来了理论上的挑战。但对于分布式图问题还有一些实践性的解决方案，那也正是我们所研究的。

InfoQ：图数据库是要存储和管理相互连接的数据。这项特征限制了这些数据库在支持方面——像 Sharding 和事务——的能力吗？

Ian and Jim：正如我们在上一个回答中所提到的，sharding（或者图分区）是让图可伸缩的关键，特别是对于写入操作。但那很困难，至少在一般的情况下很难。另外，我们还需要使用事务来保护数据的完整性，你会看到我们还有一项有趣的可伸缩性设计挑战。

也就是说，当处理很多并发事务的时候，图的数据结构的特性有助于跨多个图分布事务负载。当图增长的时候，事务争用通常会减少。换句话说，图越大，就越通畅，那非常不错！

InfoQ：图数据库如何支持数据复制和灾难恢复特性？

Ian and Jim：现在 Neo4j 使用主从簇集的方案来支持复制和灾难恢复。在 Neo4j 簇集中，一台计算机会被指定为主，另一台被指定为从。指向到任意服务器的写入操作最终都会传递给主计算机，然后把更新的结果传递给从计算机。

如果主计算机出现了故障，那么簇集会自动通过我们的 Paxos 实现选取出新的主计算机。再提一下，我们的 R&D 团队已经做了一些有意义的工作，让 Neo4j 成为没有主计算机的数据库簇集，那会在将来的版本中发布。

InfoQ：可否请你说一下图数据库的一些限制？

Ian and Jim：和 Apache Cassandra 之类产品相比，今天的图数据库还没有同等程度的写入吞吐量——这是由于主从簇集以及合适的 ACID 事务所决定的。把图数据库用于购物车或者投票系统不是太合理，还有更多合适的数据库可以使用。但是当你为购物车使用了列数据库或者键值（Key-value）数据库，在图数据库中分析客户的购买历史会非常好。这是我们已经见过几次的模式：使用简单的数据库来吸收负载，然后把数据输入到图数据库，作为记录系统来进行提炼和分析。

InfoQ：在图数据库领域有什么样的趋势？ 你认为图数据库的将来会怎样？

Ian and Jim：从高层次上看，我认为图数据库正在成为主流。五年前，图数据库还在学院中，也无人关注，但现在它们已经无处不在。不久，图数据库会是我们考虑的另一种一般工具。基于如何看待它们今天的应用，我们相信它们会继续取代关系型数据库。随着数据之间的连接变得更杂乱，随着这个领域的成熟，它们的流行度也会猛增。

他们还提到，这是图和图数据库的激动时刻。它们看到更多图工具——既有专门目的，也有一般目的的——进入到市场中。Neo4j 正在大幅改进它的数据模型、它的查询语言、对非常大型的数据集的支持以及整体性能。文化也在不断增长，已经有了在线的教程和用例。已经有了一个健康、活跃的用户社区，在世界各地的城市中集会。并且，还有 GraphConnect 会议，今年会在旧金山、芝加哥、波士顿、纽约和伦敦举办，每个城市都会有技术、理论和实践的话题，会有各个业界和社区的专家参加。

关于受访者

Ian Robinson是 Neo 科技的一位工程师，目前正在从事 Neo4j 图数据库未来版本的研究和开发工作。他是《REST in Practice (O’Reilly)》的合著者，并且是《REST: From Research to Practice”(Springer)》和《Service Design Patterns (Addison-Wesley)》的贡献者。

Dr. Jim Webber是 Neo 科技的首席科学家，该公司支持了流行的开源图数据库 Neo4j，他在其中研究和开发分布式图数据库，并编写开源的软件。他是《REST in Practice》一书的合著者。Jim 的博客位于 http://jimwebber.org，他的推特是 @jimwebber。

查看英文原文： Graph Databases - Book Review and Interview