图形数据库Neo4j

前言

图表数据库是当今巨大的宏观业务趋势之一：在高度连接的数据中利用复杂和动态的关系，产生洞察力和竞争优势。无论我们想要了解客户之间的关系，电话或数据中心网络中的元素，娱乐生产商和消费者，还是基因和蛋白质，都能够了解和分析高度相关数据的庞大图表，这将是确定哪些公司优于其竞争对手的关键在未来十年。对于任何显着大小或值的数据，图形数据库是表示和查询连接数据的最佳方式。连接的数据是其解释和价值要求我们首先了解其组成要素相关方式的数据。通常，为了产生这种理解，我们需要命名和限定事物之间的联系。虽然大公司在很久以前才意识到这一点，并开始创建自己的专有图形处理技术，但我们现在处于这个技术迅速民主化的时代。今天，通用图表数据库是现实，使主流用户能够体验连接数据的优势，而无需投资建立自己的图形基础架构。图形数据的复兴和图形思考令人惊奇的是，图形理论本身并不新鲜。图形理论是欧拉在18世纪开创的，自此以后，数学家，社会学家，人类学家和其他从业者一直在积极研究和完善。然而，只有在过去几年中，图形理论和图形思维才被应用于信息管理。在那时，图形数据库已经帮助解决了社交网络，主数据管理，地理空间，建议等方面的重要问题。图形数据库的更多关注是由两个力量驱动的：通过Facebook，Google和Twitter等公司的巨大商业成功，他们都将自己的商业模式围绕在自己的专有图形技术上; 并将通用图表数据库引入技术领域。

第一章 简介

虽然这本书大部分都是关于图形数据模型的，但它并不是关于图形理论的书。我们不需要太多的理论来利用图形数据库：只要我们了解图形，我们几乎在那里。 考虑到这一点，让我们回忆一下关于图形的一般记忆。

什么是图表？ 

正式地，一个图形只是一个顶点和边的集合，或者在一个不太吓人的语言中，一组节点和连接它们的关系。 图形表示实体作为节点，以及这些实体与世界作为关系的方式。 这种通用的，具有表现力的结构使我们能够从建造太空火箭到道路系统，从供应链或食品来源到人口的医疗史等各种场景进行建模。

例如，Twitter的数据很容易被表示为图表。 在图1-1中，我们看到一个小型的Twitter用户网络。 每个节点都标记为User，表示其在网络中的作用。 这些节点然后与关系相关联，这有助于进一步建立语义环境：即比利跟随哈利，而哈利依次跟随比利。 露丝和哈利也相互对峙，可悲的是，虽然露丝跟着比利，但比利还没有回报。

图1-1。 一个小的社交图

当然，Twitter的真实图形比图1-1中的例子大了数亿倍，但它的工作原理完全相同。 在图1-2中，我们扩展了图形以包含由Ruth发布的消息。

图1-2。 发布消息

虽然简单，图1-2显示了图形模型的表现力。 很容易看到露丝发表了一串消息。 她最近的消息可以通过跟随一个标记为CURRENT的关系找到。 先前的关系创建了露丝的时间表。

图表空间的高级视图
管理，处理和分析图形的众多项目和产品近年来爆炸式发展。绝大多数技术使得难以跟踪这些工具以及它们的区别，即使对于在空间活跃的我们也是如此。本节提供了一个高级框架，用于了解新兴图形的景观。从10,000英尺，我们可以将图形空间分为两部分：主要用于事务在线图形持久性的技术，通常从应用程序实时直接访问这些技术称为图形数据库，是本书的主要重点。它们相当于关系世界中的“正常”在线事务处理（OLTP）数据库。主要用于离线图分析的技术通常作为一系列批处理步骤执行。这些技术可以称为图形计算引擎。它们可以被认为与其他用于分析数据的技术（例如数据挖掘和在线分析处理（OLAP））处于同一类别。

图形数据库
图形数据库管理系统（以下为图形数据库）是一种具有创建，读取，更新和删除（CRUD）方法的在线数据库管理系统，用于公开图形数据模型。图形数据库通常构建为与事务（OLTP）系统一起使用。因此，它们通常针对事务性能进行优化，并考虑到事务完整性和操作可用性。
 在调查图形数据库技术时，我们应该考虑图形数据库的两个属性：
底层存储
一些图形数据库使用优化和设计用于存储和管理图形的本机图形存储。然而，并非所有图形数据库技术都使用本机图形存储。一些将图形数据序列化为关系数据库，面向对象数据库或其他通用数据存储。
处理引擎
一些定义要求图形数据库使用无索引的邻接，这意味着连接的节点在数据库中物理上“指向”彼此之间.2这里我们看到一个更宽泛的视图：从用户的角度看，任何数据库都像图形数据库即通过CRUD操作公开图形数据模型）符合图形数据库的要求。然而，我们确实承认无索引邻接的显着性能优势，因此使用术语本地图处理来描述利用无索引邻接的图形数据库。

关系是图形数据模型的一流公民。 在其他数据库管理系统中并不是这样，我们必须推断实体之间的连接，例如外键或带外处理（如map-reduce）。 通过将节点和关系的简单抽象组合到连接结构中，图形数据库使我们能够构建任意复杂的模型，将其映射到我们的问题领域。 所产生的模型比使用传统关系数据库和其他NOSQL（不仅仅是SQL）存储产生的模型更简单，同时更具表现力。

图1-3显示了当前市场上一些图形数据库的图形概述，基于其存储和处理模型。

图1-3。 图形数据库空间的概述

图形计算引擎

图形计算引擎是一种能够对大型数据集运行全局图形计算算法的技术。图形计算引擎设计用于执行数据中识别集群等问题，或回答诸如“社交网络中的每个人平均有多少关系？”等问题。
由于它们强调全局查询，所以图形计算引擎通常被优化用于批量扫描和处理大量信息，并且在这方面它们类似于在关系中使用的其他批次分析技术，如数据挖掘和OLAP世界。而一些图形计算引擎包括图形存储层，其他（可以说是大多数）图形计算引擎严格关注从外部源提供的处理数据，然后将其结果存储在别处。
图1-4显示了用于部署图形计算引擎的常见架构。该体系结构包括具有OLTP属性（例如MySQL，Oracle或Neo4j）的记录系统（SOR）数据库，其服务请求并在运行时响应来自应用程序（以及最终用户）的查询。定期地，提取，转换和加载（ETL）作业将数据从记录数据库系统移动到图形计算引擎中进行离线查询和分析。

图1-4。 典型图形计算引擎部署的高级视图

存在各种不同类型的图形计算引擎。 最值得注意的是存储器/单机图计算引擎如Cassovary和分布式图计算引擎如Pegasus或Giraph。 大多数分布式图形计算引擎都是基于Google撰写的Pregel白皮书，它描述了Google用来对页面进行排序的图形计算引擎。

图形数据库的力量

尽管事实上，任何东西都可以被绘制成图表，但我们生活在一个务实的预算，项目时间线，企业标准和商品化技能的世界。 图形数据库提供了一种功能强大而又新颖的数据建模技术本身并没有为替代已经完善的，易于理解的数据平台提供充分的理由; 还必须立即和非常重要的实际利益。 在图形数据库的情况下，这种动机以一组使用案例和数据模式的形式存在，其在图中实现时性能提高了一个或多个数量级，并且与集合的批处理相比，其潜伏期要低得多。 除了这种性能优势之外，图形数据库还提供了非常灵活的数据模型，并提供了与当今敏捷软件交付实践相一致的交付方式。

性能

因此，选择图形数据库的一个令人信服的原因是处理连接的数据与关系数据库和NOSQL存储时的性能提升。 与关系数据库相反，随着数据集越来越多，连接密集型查询性能恶化，图形数据库性能趋于保持相对恒定，即使数据集增长。 这是因为查询被本地化到图形的一部分。 因此，每个查询的执行时间仅与遍历的图形部分的大小成比例，以满足该查询，而不是总体图形的大小。

灵活性

作为开发人员和数据架构师，我们希望按照领域的要求连接数据，从而允许结构和架构随着我们对问题空间的日益增长的理解而出现，而不是在我们最初知道真实的形状和复杂性的数据。图形数据库直接解决这个需求。如第3章所示，图形数据模型表达和适应业务需求，使IT能够以业务速度移动。
图形自然是加法的，这意味着我们可以在现有的结构中添加新的关系，新节点，新标签和新的子图，而不会影响现有的查询和应用程序功能。这些事情对开发人员的生产力和项目风险都有正面的影响。由于图形模型的灵活性，我们无需提前对详细的细节进行建模，而是面对不断变化的业务需求，这一切都是愚蠢的。图形的附加属性也意味着我们倾向于执行更少的迁移，从而减少维护开销和风险。

敏捷

我们希望能够与我们的其余应用程序一起演进我们的数据模型，使用与当今增量和迭代软件交付实践相一致的技术。现代图形数据库使我们能够进行无摩擦开发和优雅的系统维护。特别地，图形数据模型的无模式特性以及图形数据库的应用程序编程接口（API）和查询语言的可测试性质，使我们能够以受控的方式演进应用程序。
同时，正是因为它们是免费的，图形数据库缺乏我们在关系世界中熟悉的面向模式的数据治理机制。但这不是风险;相反，它提出了一种更加明显和可操作的治理方式。正如我们在第4章中所示，治理通常以编程方式应用，使用测试来驱除数据模型和查询，以及断言依赖于图的业务规则。这不再是一个有争议的做法：比关系开发更重要，图形数据库开发与当今敏捷和测试驱动的软件开发实践保持一致，允许图形数据库支持的应用程序随着不断变化的业务环境而发展。

总结

在本章中，我们已经查看了图形属性模型，这是一个用于表示连接数据的简单而富有表现力的工具。 属性图以表现力和灵活的方式捕获复杂的域，而图形数据库可以轻松开发操纵图形模型的应用程序。
在下一章中，我们将详细介绍几种不同的技术如何解决连接数据的挑战，从关系数据库开始，转移到聚合NOSQL存储上，并以图形数据库结束。 在讨论过程中，我们将了解为什么图形和图表数据库为建模，存储和查询连接的数据提供了最佳方法。 接下来的章节将介绍如何设计和实现基于图形数据库的解决方案。