写给关系型数据库开发人员的图数据库权威指南

图数据库权威指南 写写给给关关系系型型数数据据库库开开发发人人员员的的图图数数据据库库权权威威指指南南 写写给给关关系系型型数数据据库库开开发发人人员员的的 图图数数据据库库权权威威指指南南 第第一一章章、、 为为什什么么关关系系型型数数据据库库不不是是万万能能的的？？ 关系型数据库(RDBMS)是非常强大的技术工具。 自从上世纪八十年代起，关系型数据库就是大多数软件和应用系统的发电站，而且这一状况今天仍然在继续。最初设计时，关系型数据库针对的是规范的、类似纸张表格的表状数据结构，而且它的确非常出色地满足了这种需求。对于适合的应用案例和架构，关系型数据库是存储和组织数据的最佳工具。 关系型数据库在表中存储高度结构化的数据。表通常具有事先定义好的列和包含相同类型信息的行，它们要求开发人员和应用对使用到的数据都必须严格地进行定义。 然而，在大数据时代，数据的格式和类型更加多样、数据量更大、变化更加频繁、更新更加快速，而更重要的是数据之间的关系和联结越来越得到重视。今天对数据处理的需求和应用已经不再满足于简单的表状结构。 其实并不像其名称听上去的那样，关系型数据库并不擅长处理今天高度关联的数据。其根本原因是关系型数据库并不具备足够强大的存储和管理数据项之间关系的能力。 关系型数据库并不擅长存储关系 其实并不像其名称听上去的那样，关系型数据库并不非常擅长处理今天高度关联的数据。其根本原因是关系型数据库并不具备足够强大的存储和管理数据项之间关关系系的能力。 如果我们回顾一下历史，关系型数据库的名称来自于E.F. Codd的关系代数中“关系”的数学概念，它具有非常特定的含义。这个名称其实和存在于现实世界中事物之间的关系没什么太大联系。 一直以来，开发人员在做的都是怎样将数据存储到关系模型的列和行中。 而这并不是现实生活中数据存在的实际形式。实事求是地说，数据更应被看作是对象， 以及存在于无数对象间的连接。 这种复杂的、存在于现实生活的数据在规模、产生速度和多样性上飞速增长 。与此同时，数据之间的关联也在以更加快速的节奏增长，这些联结往往包含着比数据本身更有价值的知识。 这就是新问题产生的根本原因：关系型数据库并非为保存和处理这种丰富的、存在于数据间的联系而设计。 写给关系型数据库开发人员的图数据库权威指南 其带来的主要问题就是，今天的企业和机构由于没有适用于处理高度关联的数据的技术手段，而错失低风险、高利润、数据驱动的决策机会。 现今的软件应用都需要适应敏捷开发的要求 今天，所有的开发团队都不得不面对变化频繁的业务和用户需求，而这些变化往往要求对已有的数据架构和视图进行修改。 数据库管理员(DBAs)和开发人员时常要应对来自业务部门改变和增加数据库元素及属性的要求，以满足经常变化的业务，例如存储最新社交平台的数据。 然而这种经常性的数据库模式的改变对关系型数据库是存在问题的，而且改变的代价昂贵。 其主要原因是关系型数据库面对变化并不能很好地适应。固定的数据库模式只适用于能够事先明确的业务问题，在不需要经常改动的情况下才能运行稳定。 缓慢和昂贵的数据库模式重设计同样对敏捷软件开发带来负面影响，它使得团队无法进行快速的创新，错失巨大的市场机会。 今天的企业和机构由于没有适用于处理高度关联的数据的技术手段，而错失低风险、高利润、数据驱动的决策机会。 结论就是，关系型数据库不是为适应灵活快速的业务发展而设计的。 对数据关联的查询是怎样拖垮关系型数据库性能的？ 尽管有了更加先进的计算技术、更快的处理器和高速的网络，某些类型的关系型数据库应用却越来越慢。这种性能的下滑有一些众所周知的症状(参见下文关于“SQL查询的限制”部分)，但究其根源总无外乎一个共同因素：对数据关系的查询。 虽然关系型数据库并非为处理连接的数据而开发和优化，但是任何试图从数据间关联中寻找答案的查询，例如推荐引擎、欺诈检测或者社交网络图，都必须使用大量的数据库表间的连接(JOIN)操作。 在关系型数据库中，对其他表中记录的引用是通过定义指向另一表中的主键属性的外键字段来表示的。参见下面图1中的一个例子。 写给关系型数据库开发人员的图数据库权威指南 表间的引用由限制来得到强制执行，但是这仅仅在引用不是可选的情况下。在执行查询时，JOIN操作比较主表和被连接表中每条记录的主键和外键的值。多数情况下，键字段建有索引以提高这种的比较操作的性能，但是即便如此，这样的操作还是会消耗大量的计算能力和内存，并且随着查询复杂度的增长而呈指数级增长。 于是，在关系型数据库中对联结的数据进行建模和存储几乎不可避免地带来极端的复杂性。这种复杂性包括长达成百上千行的SQL查询语句，有时仅仅实现了简单的功能。查询性能因着查询的复杂性、数据间关系的数量和层次，以及数据库的规模的增长而越来越糟糕。 今天的软件应用都需要满足实时处理、始终可用的要求。传统的关系型数据库在要求处理大量数据间关联的应用中已经不能胜任。 关系型数据库应用受限于SQL的五大征兆 多数关系型数据库应用在其能力范围之内都可以运行地很好。但是，有些则因着数据库本身的限制而运行缓慢，特别是当关系型数据库被用来处理高度联结的数据时。 以下是试图用关系型数据库解决数据联结型问题时会遇到的五大典型征兆： 1.有大量的连接JOIN操作 当查询中包含了过多的表连接的时候，复杂性和计算资源消呈爆炸性地增长。这相应地增加了查询的执行时间。 2.有大量的自连接Self-JOIN操作(也称作递归连接) 自连接查询在层次和树状的数据库结构中非常常见，然而，重复连接表自身以达到遍历关系的目的是非常低效的。事实是，我们见过的这世界上最长的SQL查询就包含递归的自连接。 3.频繁变更的数据库模式 现今的时代，业务的灵活可变性是在激烈竞争中制胜的关键。而实际情况是，业务部门要求做出变化的意愿经常被DBA们泼上冷水，因为关系型数据库并非为适应频繁变化的数据模式和视图而设计的。对数据库模式变化的要求变得平常，说明数据和需求在快速的变化，这就要求一个更加灵活可变的数据模式。 4.运行缓慢的查询(尽管进行了大量的性能调试) 数据库管理员们尝试使用教科书上提到的所有秘诀来加速查询的运行，但是许多SQL的执行速度仍然无法 达 到 期 待、以满 足应 用的需 求 。 另 外 ， 为 提高查 询 性 能 而 采 用的 “去 范 式 化”， 或 称 “ 扁 平 化 ”(denormalizing)的数据模型会对数据质量和更新方式带来负面的影响。 5.预先计算查询结果 因为查询的速度太慢，许多应用不得不用历史数据事先计算好结果，这实际上是用昨天的数据来获得原本需要用实时数据才能获得的查询结果。更糟糕的是，系统往往不得不计算100%的数据，即便只有1-2%的数据是真正需要的。 关系数据库的替代方案 前面提到过，关系型数据库有适合它的应用类型。对于结构规范、事先可以定义的模式，关系型数据库是完美的技术工具。 但是就像我们已经看到的，关系数据库并不总是最好的。那些需要从联结的数据中挖掘出内在洞察的应用就无法依靠关系数据库来高效解决。 今天的大数据呈现的规模、速度和多样性，以及数据间的关联，需要一种从根根本本上上能能够够存存储储和和管管理理联联结结数数据据的的解解决决方方案案。而图数据库正是为这一目的而设计的。下面就让我们来看看图数据库。 写给关系型数据库开发人员的图数据库权威指南 第第二二章章、、 什什么么是是图图数数据据库库? 我们已经知道关系数据库不再胜任大数据时代的在规模、速度和多样性等方面的变化，那么什么才是适用的替代方案呢？ 目前已经有其他的数据库选项，包括一系列的NoSQL数据存储(不仅仅是SQL，NotOnlySQL)，但其中没有哪个是专门为处理和存储数据间关联而设计的，除了一种， 那就是图数据库。 图数据库能给现有技术架构带来的最大价值，是图数据库对数据之间的关系提供与单个数据同样的存储支持(First-Class Citizen)。 例如，图数据库的早期采纳者能够在数据之间的关联之上重新定义业务架构。这些公司今天已经成为业界的领袖，诸如：LinkedIn ,Google,Facebook和PayPal。 作为图数据库的先行者们，这些公司都从无到有创建了他们自己的图数据处 理 技 术。 幸 运的是 ， 对 于今 天 的开 发 人 员 ， 从 头 创 建 图 数 据 库 已经不再必要，已有一个现成的图数据库产品可以采用，那就是Neo4j。 如果曾经使用过关系数据库，那么理解图数据库只是小菜一碟。 让我们再看看为什么应该采用图数据库来构建下一代基于联结数据的应用。先熟悉一下图和图数据库的基本定义。 图是什么? 图数据库基于图计算理论。不过，为了理解图数据库，我们不必非得理解神秘的、数学理论中的图。相反，如果曾经使用过关系数据库，理解图数据库只是小菜一碟。 第一件要知道的事：图(Graph)，在数学理论中，和图表(Chart)是不一样的，所以不要把图想象成一个条形图或线形图。 图应当被想象成一个由节点和边连接起来的网络，例如一个思维导图(Mind Map)，像右图所示。 图 2、一个简单的欺诈团伙图，其中的节点共享联系信息。 写给关系型数据库开发人员的图数据库权威指南 图有两个基本元素：节点和连接节点的关系。 每一个节点代表一个实体，例如某人、某地、某事；每一个关系代表两个节点是如何相互关联的。举一个例子，有两个节点“蛋糕”和“甜食”， 它们之间的关系可以是“是一种。。。”(isatypeof)，方 向是从蛋糕到甜食。 这种通用性的结构允许对所有的情况进行建模，从一个道路系统，到连接到网络的设备，或者一群人的医疗记录，以及任何可以用关系连接的事物。 什么是图数据库? 图数据库是一个在线数据库管理系统，用来执行创建、读取、更新和删除( CRUD)图数据模型中的数据。图数据库通常也是交易型系统(OLTP)。因此，图数据库针对交易处理性能进行了优化，而且优先确保交易的完整性和系统的可用性。 与其他数据库所不同的是，图数据库最优先处理数据间的关系。这意味着应用无须依靠外键来推导数据间的关联，或是依靠外部的系统来处理数据，例如MapReduce。 与其他数据库不同的是，图数据库最优先处理数据间的关系。这意味着应用无须依靠外键来推导数据间的关联，或是依靠外部的系统来处理数据，例如MapReduce。 通过将节点和关系简单抽象成连接的结构，图数据库使得建立与现实问题领域更加接近的复杂的模型成为可能。 对图数据库技术而言，有两个重要的特性： 本地(Native)图存储 有些图数据库使用本地图存储，就是针对图的特性而专门设计的存储模式， 而其它数据库则使用关系型或面向对象型数据库来存储图数据。非本地的图存储有很大的潜在性能瓶颈，尤其是在数据规模和查询复杂度显著增加的时候。 图处理引擎 本 地 图 处 理 ， 我 们 称 之 为“无 需 索 引的邻 接 关 系”(index -freeadjacency )，是处理图数据最有效率的手段，因为数据的连接在图数据库中物理地被保存下来。其他非图的数据库以其他方法处理，无法针对图数据结构而优化CRUD操作。 使用图数据库有哪些优势? 图数据库是专门为处理高度联结的数据而设计建造的。当今是大数据的时代，数据拥具有极大的规模和高度的内在联系，而图数据库为实现“可持续的竞争优势”(sustainablecompetitiveadvantage)提供了巨大的机会。 在将图应用到现实世界中的问题上,并兼顾实际的技术和业务限制，许多企业出于一种或多种不同原因最终选择了图数据库： 写给关系型数据库开发人员的图数据库权威指南 从分钟到毫秒的性能提升 查询性能和响应速度是许多组织在建立其数据平台时首要关注的问题。在线交易系统，尤其是大型Web应用程序，必须在毫秒内对用户请求作出响应，才能确保客户不会因为