目录
尽管本书中有很多是关于图形数据模型的，但它不是一本关于图形理论的书。我们不需要太多理论来利用图形数据库：只要我们了解图形是什么，我们就可以在那里使用。 考虑到这一点，让我们回顾一下一般的图表。
1.什么是图？
从形式上讲，图只是顶点(vertices)和边(edges)的集合，或者在不那么吓人的局域网中语言，一组节点(nodes)和连接它们的关系图形表示实体作为节点的联系以及这些实体作为关系与世界联系的方式。这种通用的表达结构允许我们模拟各种场景，从太空火箭的建造，到道路系统，再到补给系统-食物的链或来源，到人口的医学史，甚至更远。
形式上，图只是顶点(vertices)和边(edges)的集合，或者用较少威胁性的语言表示的是一组节点(nodes)和连接它们的关系(relationships)。 图将实体表示为节点，并将这些实体与世界的关系表示为关系。这种通用的表达结构使我们能够对各种情况进行建模，从建造太空火箭到道路系统，从食品的供应链或食品来源到人口的医疗史等等。
图无处不在
图对于理解字段中的各种数据集非常有用，例如科学，政府和商业。 真实世界-与基于表单的世界不同，关系数据库背后的模型是丰富且相互关联的：部分统一且受规则约束，其他部分则异常且不规则。 一旦了解了图，我们开始在各种各样的地方见到他们。 例如，Gartner会识别出五个图形商业世界-社会，意图，消费，兴趣和移动性，利用这些图表的能力提供了“可持续的竞争优势”。
例如，Twitter的数据很容易表示为图形。 在图1-1中，我们看到了一个由Twitter用户组成的小型网络。 每个节点都标记为User，指示其在网络中的角色。 然后将这些节点与关系联系起来，这有助于进一步建立语义上下文：即，比利（Billy）跟随哈利( Harry )，而( Harry )哈利转跟着比利（Billy）。 露丝（Ruth）和哈利（Harry）也互相追随，但可悲的是，尽管露丝（Ruth）跟着比利（Billy），但比利（Billy）没有做出回报。
当然，Twitter的真实图形比图1-1中的示例大数亿倍，但是它的工作原理完全相同。 在图1-2中，我们将图形扩展为包括Ruth发布的消息。
尽管简单，但图1-2显示了图模型的表达能力。 很容易看出露丝（Ruth）已发布了一连串消息。 通过遵循标记为CURRENT的关系可以找到她的最新消息。 然后，上一个关系创建了露丝的时间表。
标记的属性图模型
在讨论图1-2时，我们还非正式地介绍了图模型的最流行形式，即标记的属性图（在附录A中，我们更详细地讨论了替代图数据模型）。 带标签的属性图具有以下特征：
- 它包含节点和关系。
- 节点包含属性（键值对）。
- 节点可以用一个或多个标签标记。
- 关系是命名和定向的，并且始终具有起点和终点。
- 关系也可以包含属性。
多数人认为属性图模型直观易懂，尽管它很简单，但它可以用来描述绝大多数图用例，从而对我们的数据产生有用的见解。
2.图空间的高级视图
近年来，用于管理，处理和分析图形的许多项目和产品迅速出现。 庞大的技术使跟踪这些工具及其不同之处变得困难，即使对于我们这个领域活跃的人来说也是如此。 本节提供了一个高级框架，使您可以了解新兴的图形环境。 从10,000英尺开始，我们可以将图形空间分为两部分： .
-
主要用于交易在线图持久性的技术，通常直接从应用程序实时访问
- 这些技术称为图形数据库，是本书的重点。 它们相当于关系世界中的“常规”在线事务处理（OLTP）数据库。
-
主要用于离线图形分析的技术，通常作为一系列批处理步骤执行
- 这些技术可以称为图形计算引擎。 可以认为它们与其他用于批量数据分析的技术属于同一类别，例如数据挖掘和在线分析处理（OLAP）。
划分图空间的另一种方法是查看各种技术采用的图模型。 有三种主要的图数据模型：属性图（property graph），资源描述框架（RDF）三元组和超图（hypergraphs）。 我们在附录A中对此进行了详细描述。市场上大多数流行的图形数据库都使用属性图模型的变体，因此，在本书的其余部分中将使用该模型。
2.1.图数据库
图形数据库管理系统（以下称为图形数据库）是一种在线数据库管理系统，具有创建，读取，更新和删除（CRUD）方法，这些方法公开图形数据模型。 图形数据库通常是为与事务（OLTP）系统一起使用而构建的。 因此，它们通常针对事务性能进行优化，并且在设计时要考虑事务的完整性和操作可用性。
研究图数据库技术时，应考虑图数据库的两个属性：
- 基础存储
- 一些图形数据库使用本机图形存储，该存储已针对存储和管理图形进行了优化和设计。 但是并非所有的图形数据库技术都使用本机图形存储。 有些将图形数据序列化为关系数据库，面向对象的数据库或某些其他通用数据存储。
- 处理引擎
- 一些定义要求图形数据库使用无索引（index-free）的邻接关系，这意味着连接的节点在数据库中在物理上彼此“指向”。 在这里，我们从一个更宽泛的角度来看：从用户的角度来看，任何行为类似于图形数据库（即通过CRUD操作公开图形数据模型）的数据库都可以视为图形数据库。 但是我们确实承认无索（index-free）引邻接的显着性能优势，因此使用术语本机图形处理来描述利用无索引邻接的图数据库。
请务必注意，本机图形存储和本机图形处理既不是好事也不是坏事，它们只是经典的工程折衷。 本机图存储的好处是其专门构建的堆栈旨在提高性能和可伸缩性。相比之下，非本机图存储的好处是它通常依赖于成熟的非图后端（例如MySQL），该后端的生产被运营团队理解特性很好。本机图形处理（无索引邻接）可提高遍历性能，但以使一些不使用遍历的查询困难或占用大量内存为代价。
关系是图数据模型的一等公民。 在其他数据库管理系统中则不是这种情况，在其他数据库管理系统中，我们必须使用诸如外键之类的东西或诸如map-reduce之类的带外处理来推断实体之间的连接。通过将节点和关系的简单抽象组装到连接的结构中，图形数据库使我们能够构建任意复杂的模型，这些模型紧密地映射到我们的问题域。与使用传统关系数据库和其他NOSQL（不仅是SQL）存储库生成的模型相比，生成的模型更简单，同时更具表现力。
图1-3显示了基于存储和处理模型的当今市场上某些图形数据库的图形概述。
2.2.图计算引擎
图形计算引擎是一项使全局图形计算算法能够针对大型数据集运行的技术。 图形计算引擎旨在执行诸如识别数据中的群集或回答“社交网络中的每个人平均多少关系”之类的问题。
由于它们强调全局查询，因此通常对图计算引擎进行了优化，以批量扫描和处理大量信息，并且在这方面，它们类似于关系分析中使用的其他批处理分析技术，例如在关系世界中使用数据挖掘和OLAP。 一些图形计算引擎包括图形存储层，而其他（可能是大多数）图形引擎则严格地处理自己从外部源输入的数据，然后将结果返回以存储在其他地方。
存在多种不同类型的图计算引擎。 最值得注意的是，内存/单机图形计算引擎（如Cassovary）和分布式图形计算引擎（如Pegasus或Giraph）。 大多数分布式图形计算引擎都基于Google撰写的Pregel白皮书，该白皮书描述了Google用于对页面进行排名的图形计算引擎。
本书着重于图数据库
上一节提供了整个图空间的粗粒度概述。本书的其余部分着重于图数据库。 我们的目标始终是描述图形数据库的概念。 在适当的情况下，我们将举例说明这些概念，这些示例来自我们使用标记的属性图模型和Neo4j数据库开发解决方案的经验。 但是无论示例中使用的是图形模型还是数据库，重要的概念都会转移到其他图形数据库中。
3.图数据库的力量
尽管几乎所有事物都可以建模为图表，但我们生活在务实的预算，项目时间表，企业标准和商品化技能世界中。 图数据库提供了强大而新颖的数据建模技术，但它本身并不能提供足够的理由来取代公认的，易于理解的数据平台； 还必须立即产生非常重大的实际收益。 在图数据库的情况下，这种动机以一组用例和数据模式的形式存在，当在图中实现时，它们的性能提高一个或多个数量级，并且其效率远低于批处理聚集体 。 除了这种性能优势之外，图形数据库还提供了非常灵活的数据模型，并且提供了与当今敏捷软件交付实践一致的交付模式。
3.1.性能
因此选择图形数据库的一个令人信服的原因是，与关系数据库和NOSQL存储相比，在处理连接数据时性能得到了极大提高。 与关系数据库相反，关系数据库的联接密集型查询性能随着数据集的变大而降低，而图数据库的性能往往保持相对恒定，即使数据集增长也是如此。 这是因为查询被本地化到图的一部分。 结果，每个查询的执行时间仅与满足该查询所遍历的图的一部分的大小成正比，而不与整个图的大小成正比。
3.2.灵活性
当我们最不了解数据的真实形状和复杂性时，作为开发人员和数据架构师，我们希望根据领域的要求连接数据，从而使结构和架构随着对问题空间的日益了解而串联出现，而不是先行提出。 图形数据库直接解决了这个需求。 正如我们在第3章中所展示的，图形数据模型以使IT能够以业务速度移动的方式来表达和适应业务需求。
图自然是可加的，这意味着我们可以在现有结构中添加新类型的关系，新节点，新标签和新子图，而不会干扰现有查询和应用程序功能。 这些因素通常对开发人员的生产力和项目风险产生积极影响。 由于图形模型具有灵活性，因此我们不必提前详尽地为我们的域建模-面对不断变化的业务需求，这种做法几乎是非常困难的。 图的可加性也意味着我们倾向于执行较少的迁移，从而减少了维护开销和风险。
3.3.敏捷
我们希望能够使用与当今的增量和迭代软件交付惯例保持一致的技术来与我们的其他应用程序同步地发展数据模型。 现代图形数据库使我们能够执行无摩擦开发和正常系统维护。 尤其是，图形数据模型的无模式性质，再加上图形数据库的应用程序编程接口（API）和查询语言的可测试性质，使我们能够以受控方式开发应用程序。
同时，正因为它们没有架构，图数据库缺乏我们在关系世界中熟悉的那种面向架构的数据治理机制。 但这不是风险。 相反，它提出了一种更为可见和可操作的治理方式。 正如我们在第4章中所展示的那样，治理通常以编程方式应用，使用测试驱逐数据模型和查询，以及断言依赖于图形的业务规则。 这不再是一个有争议的做法：图形数据库开发比关系开发更重要，它与当今的敏捷和测试驱动的软件开发实践完全吻合，允许图形数据库支持的应用程序随着不断变化的业务环境而不断发展。
4.摘要
在本章中，我们回顾了图属性模型，它是一种简单但可表示表情的表示连接数据的工具。 属性图以富有表现力和灵活性的方式捕获复杂的域，而图数据库使开发可操纵图模型的应用程序变得容易。
在下一章中，我们将更详细地介绍几种不同的技术如何解决连接数据的难题，从关系数据库开始，转移到聚集的NOSQL存储，再到图数据库结束。 在讨论过程中，我们将了解为什么图形和图形数据库为建模，存储和查询关联数据提供了最佳方法。 随后的各章继续说明如何设计和实现基于图形数据库的解决方案。