标签：02 name 数据库 查询 Intensive 文档 顶点 数据模型
《Designing Data-Intensive Application》
数据模型可能是软件开发中最重要的部分了，因为它们的影响如此深远︰不仅仅影响着软件的编写方式，而且影响着我们的解题思路。
多数应用使用层层叠加的数据模型构建。一个复杂的应用程序可能会有更多的中间层次，比如基于API的API，不过基本思想仍然是一样的:每个层都通过提供一个明确的数据模型来隐藏更低层次中的复杂性。这些抽象允许不同的人群有效地协作(例如数据库厂商的工程师和使用数据库的应用程序开发人员)。
数据模型种类繁多，每个数据模型都带有如何使用的设想。有些用法很容易，有些则不支持如此;有些操作运行很快，有些则表现很差﹔有些数据转换非常自然，有些则很麻烦。
在本章中，我们将研究一系列用于数据存储和查询的通用数据模型。特别地，我们将比较关系模型，文档模型和少量基于图形的数据模型。我们还将查看各种查询语言并比较它们的用例。在第3章中，我们将讨论存储引擎是如何工作的。也就是说，这些数据模型实际上是如何实现的。
关系模型与文件模型
现在最著名的数据模型可能是SQL。它基于EdgarCodd在1970年提出的关系模型【1】∶数据被组织成关系(SQL中称作表），其中每个关系是元组(SQL中称作行)的无序集合。
关系模型曾是一个理论性的提议，当时很多人都怀疑是否能够有效实现它。然而到了20世纪80年代中期，关系数据库管理系统(RDBMSes)和SQL已成为大多数人们存储和查询某些常规结构的数据的首选工具。关系数据库已经持续称霸了大约25~30年――这对计算机史来说是极其漫长的时间。
关系数据库起源于商业数据处理，在20世纪60年代和70年代用大型计算机来执行。从今天的角度来看，那些用例显得很平常︰典型的事务处理（将销售或银行交易，航空公司预订，库存管理信息记录在库）和批处理(客户发票，工资单，报告)。
多年来，在数据存储和查询方面存在着许多相互竞争的方法。在20世纪70年代和80年代初，网络模型和分层模型曾是主要的选择，但关系模型随后占据了主导地位。对象数据库在20世纪80年代末和90年代初来了又去。XML数据库在二十一世纪初出现，但只有小众采用过。关系模型的每个竞争者都在其时代产生了大量的炒作，但从来没有持续【2】。
NoSQL的诞生
NoSQL试图推翻关系模型的统治地位。"NoSQL"这个名字让人遗憾，因为实际上它并没有涉及到任何特定的技术。最初它只是作为一个醒目的Twitter标签，用在2009年一个关于分布式，非关系数据库上的开源聚会上。无论如何，这个术语触动了某些神经，并迅速在网络创业社区内外传播开来。好些有趣的数据库系统现在都与#NoSQL#标签相关联，并且NoSQL被追溯性地重新解释为不仅是SQL (Not Only sQL) 【4】。
采用NoSQL数据库的背后有几个驱动因素，其中包括:
- 需要比关系数据库更好的可扩展性，包括非常大的数据集或非常高的写入吞吐量
- 相比商业数据库产品，免费和开源软件更受偏爱。
- 关系模型不能很好地支持一些特殊的查询操作
- 受挫于关系模型的限制性，渴望―种更具多动态性与表现力的数据模型【5】
不同的应用程序有不同的需求，一个用例的最佳技术选择可能不同于另一个用例的最佳技术选择。因此，在可预见的未来，关系数据库似乎可能会继续与各种非关系数据库一起使用-这种想法有时也被称为混合持久化 (polyglot persistence)
对象关系不匹配
目前大多数应用程序开发都使用面向对象的编程语言来开发，这导致了对SQL数据模型的普遍批评:如果数据存储在关系表中，那么需要一个笨拙的转换层，处于应用程序代码中的对象和表，行，列的数据库模型之间。模型之间的不连贯有时被称为阻抗不匹配（impedance mismatch) 。
像ActiveRecord和Hibernate这样的 对象关系映射（(object-relational mapping,ORM) 框架可以减少这个转换层所需的样板代码的数量，但是它们不能完全隐藏这两个模型之间的差异。
例如，图2-1展示了如何在关系模式中表示简历（一个Linkedln简介)。整个简介可以通过一个唯一的标识符user_id来标识。像first_name和last_name这样的字段每个用户只出现一次，所以可以在User表上将其建模为列。但是，大多数人在职业生涯中拥有多于一份的工作或者教育经历，人们可能有不同样的教育阶段和任意数量的联系信息。从用户到这些项目之间存在一对多的关系，可以用多种方式来表示:
- 传统SQL模型（SQL: 1999之前)中，最常见的规范化表示形式是将职位，教育和联系信息放在单独的表中，对User表提供外键引用，如图2-1所示。
- 后续的SQL标准增加了对结构化数据类型和XML数据的支持;这允许将多值数据存储在单行内，并支持在这些文档内查询和索引。这些功能在Oracle，IBM DB2，MS SQL Server和PostgreSQL中都有不同程度的支持【6,7】。JSON数据类型也得到多个数据库的支持，包括IBM DB2，MySQL和PostgresQL 【8】。
- 第三种选择是将职业，教育和联系信息编码为JSON或XML文档，将其存储在数据库的文本列中，并让应用程序解析其结构和内容。这种配置下，通常不能使用数据库来查询该编码列中的值。
对于一个像简历这样自包含文档的数据结构而言，JSON表示是非常合适的︰参见例2-1。JSON比XML更简单。面向文档的数据库（如MongoDB 【9】 ，RethinkDB 【10】 , CouchDB 【11】和 Espresso 【12】 ）支持这种数据模型。例2-1.用JSON文档表示一个LinkedIln简介
{
"user_id": 251,
"first_name": "Bill",
"last_name": "Gates",
"summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",
"region_id": "us:91",
"industry_id": 131,
"photo_url": "/p/7/000/253/05b/308dd6e.jpg",
"positions": [
{
"job_title": "Co-chair",
"organization": "Bill & Melinda Gates Foundation"
},
{
"job_title": "Co-founder, Chairman",
"organization": "Microsoft"
}
],
"education": [
{
"school_name": "Harvard University",
"start": 1973,
"end": 1975
},
{
"school_name": "Lakeside School, Seattle",
"start": null,
"end": null
}
],
"contact_info": {
"blog": "http://thegatesnotes.com",
"twitter": "http://twitter.com/BillGates"
}
}
有一些开发人员认为JSON模型减少了应用程序代码和存储层之间的阻抗不匹配。不过，正如我们将在第4章中看到的那样，JSON作为数据编码格式也存在问题。缺乏一个模式往往被认为是一个优势;我们将在“文档模型中的模式灵活性"中讨论这个问题。
JSON表示比图2-1中的多表模式具有更好的局部性(locality)。如果在前面的关系型示例中获取简介，那需要执行多个查询(通过user_id查询每个表)，或者在User表与其下属表之间混乱地执行多路连接。而在JSON表示中，所有相关信息都在同一个地方，一个查询就足够了。
从用户简介文件到用户职位，教育历史和联系信息，这种一对多关系隐含了数据中的一个树状结构，而JSON表示使得这个树状结构变得明确(见图2-2)。
多对一和多对多的关系
在关系数据库中，通过ID来引⽤其他表中的行是正常的，因为连接很容易。在⽂档数据库中，⼀对多树结构没有必要⽤连接，对连接的⽀持通常很弱 。
如果数据库本身不支持连接，则必须在应用程序代码中通过对数据库进行多个查询来模拟连接。(在这种情况中，地区和行业的列表可能很小，改动很少，应用程序可以简单地将其保存在内存中。不过，执行连接的工作从数据库被转移到应用程序代码上。
此外，即便应用程序的最初版本适合无连接的文档模型，随着功能添加到应用程序中，数据会变得更加互联。例如，考虑一下对简历例子进行的一些修改:
组织和学校作为实体
在前面的描述中，organization(用户工作的公司)和school_name(他们学习的地方）只是字符串。也许他们应该是对实体的引用呢?然后，每个组织，学校或大学都可以拥有自己的网页(标识，新闻提要等)。每个简历可以链接到它所提到的组织和学校，并且包括他们的图标和其他信息（参见图2-3，来自LinkedIln的一个例子)。
推荐
假设你想添加一个新的功能:一个用户可以为另一个用户写一个推荐。在用户的简历上显示推荐，并附上推荐用户的姓名和照片。如果推荐人更新他们的照片，那他们写的任何建议都需要显示新的照片。因此，推荐应该拥有作者个人简介的引用。
图2-4阐明了这些新功能需要如何使用多对多关系。每个虚线矩形内的数据可以分组成一个文档，但是对单位，学校和其他用户的引用需要表示成引用，并且在查询时需要连接。
文档数据库是否在重蹈覆辙
在多对多的关系和连接已常规用在关系数据库时，文档数据库和NoSQL重启了辩论:如何最好地在数据库中表示多对多关系。那场辩论可比NoSQL古老得多，事实上，最早可以追溯到计算机化数据库系统。
20世纪70年代最受欢迎的业务数据处理数据库是IBM的信息管理系统（IMS)，最初是为了阿波罗太空计划的库存管理而开发的，并于1968年有了首次商业发布【13】。目前它仍在使用和维护，运行在IBM大型机的OS/390上 【14】。
IMS的设计中使用了一个相当简单的数据模型，称为层次模型(hierarchical model)，它与文档数据库使用的JSON模型有一些惊人的相似之处【2】。它将所有数据表示为嵌套在记录中的记录树，这很像图2-2的JSON结构。
同文档数据库一样，IMS能良好处理一对多的关系，但是很难应对多对多的关系，并且不支持连接。开发人员必须决定是否复制(非规范化）数据或手动解决从一个记录到另一个记录的引用。这些二十世纪六七十年代的问题与现在开发人员遇到的文档数据库问题非常相似【15】。
那时人们提出了各种不同的解决方案来解决层次模型的局限性。其中最突出的两个是关系模型(relational model)(它变成了SQL，统治了世界)和网络模型(network model)(最初很受关注，但最终变得冷门）。这两个阵营之间的“大辩论"在70年代持续了很久时间【2】。
那两个模式解决的问题与当前的问题相关，因此值得简要回顾一下那场辩论。
网络模型
网络模型由一个称为数据系统语言会议(CODASYL)的委员会进行了标准化，并被数个不同的数据库商实现;它也被称为CODASYL模型【16】。
CODASYL模型是层次模型的推广。在层次模型的树结构中，每条记录只有一个父节点;在网络模式中，每条记录可能有多个父节点。 例如，“Greater Seattle Area"地区可能是一条记录，每个居住在该地区的用户都可以与之相关联。这允许对多对—和多对多的关系进行建模。
网络模型中记录之间的链接不是外键，而更像编程语言中的指针（同时仍然存储在磁盘上)。访问记录的唯一方法是跟随从根记录起沿这些链路所形成的路径。这被称为访问路径(access path)。
最简单的情况下，访问路径类似遍历链表︰从列表头开始，每次查看一条记录，直到找到所需的记录。但在多对多关系的情况中，数条不同的路径可以到达相同的记录，网络模型的程序员必须跟踪这些不同的访问路径。
CODASYL中的查询是通过利用遍历记录列和跟随访问路径表在数据库中移动游标来执行的。如果记录有多个父结点(即多个来自其他记录的传入指针)，则应用程序代码必须跟踪所有的各种关系。甚至CODASYL委员会成员也承认，这就像在n维数据空间中进行导航【17】。
尽管手动选择访问路径够能最有效地利用20世纪70年代非常有限的硬件功能（如磁带驱动器，其搜索速度非常慢），但这使得查询和更新数据库的代码变得复杂不灵活。无论是分层还是网络模型，如果你没有所需数据的路径，就会陷入困境。你可以改变访问路径，但是必须浏览大量手写数据厍查询代码，并重写来处理新的访问路径。更改应用程序的数据模型是很难的。
关系模型
相比之下，关系模型做的就是将所有的数据放在光天化日之下:一个关系(表）只是一个元组(行)的集合，仅此而已。如果你想读取数据，它没有迷宫似的嵌套结构，也没有复杂的访问路径。你可以选中符合任意条件的行，读取表中的任何或所有行。你可以通过指定某些列作为匹配关键字来读取特定行。你可以在任何表中插入一个新的行，而不必担心与其他表的外键关系。
在关系数据库中，查询优化器自动决定查询的哪些部分以哪个顺序执行，以及使用哪些索引。这些选择实际上是“访问路径"，但最大的区别在于它们是由查询优化器自动生成的，而不是由程序员生成，所以我们很少需要考虑它们。
如果想按新的方式查询数据，你可以声明一个新的索引，查询会自动使用最合适的那些索引。无需更改查询来利用新的索引。关系模型因此使添加应用程序新功能变得更加容易。
关系数据库的查询优化器是复杂的，已耗费了多年的研究和开发精力【18】。关系模型的一个关键洞察是∶只需构建一次查询优化器，随后使用该数据库的所有应用程序都可以从中受益。如果你没有查询优化器的话，那么为特定查询手动编写访问路径比编写通用优化器更容易——不过从长期看通用解决方案更好。
与文档数据库相比
在一个方面，文档数据库还原为层次模型︰在其父记录中存储嵌套记录(图2-1中的一对多关系，如positions ,education和contact_info)，而不是在单独的表中。
但是，在表示多对一和多对多的关系时，关系数据库和文档数据库并没有根本的不同:在这两种情况下，相关项目都被一个唯一的标识符引用，这个标识符在关系模型中被称为外键，在文档模型中称为文档引用【9】。该标识符在读取时通过连接或后续查询来解析。迄今为止，文档数据库没有走CODASYL的老路。
关系型数据库与文档数据库在今日的对比
将关系数据库与文档数据库进行比较时，可以考虑许多方面的差异，包括它们的容错属性（参阅第5章）和处理并发性（参阅第7章)。本章将只关注数据模型中的差异。
支持文档数据模型的主要论据是架构灵活性，因局部性而拥有更好的性能，以及对于某些应用程序而言更接近于应用程序使用的数据结构。关系模型通过为连接提供更好的支持以及支持多对一和多对多的关系来反击。
哪个数据模型更方便写代码？
如果应用程序中的数据具有类似文档的结构(即，一对多关系树，通常一次性加载整个树)，那么使用文档模型可能是一个好主意。将类似文档的结构分解成多个表(如图2-1）的关系技术可能导致繁琐的模式和不必要的复杂的应用程序代码。
文档模型有一定的局限性:例如，不能直接引用文档中的嵌套的项目，而是需要说"用户251的位置列表中的第二项”(很像分层模型中的访问路径)。但是，只要文件嵌套不太深，这通常不是问题。
文档数据库对连接的糟糕支持也许或也许不是一个问题，这取决于应用程序。例如，分析应用程可能永远不需要多对多的关系，如果它使用文档数据库来记录何事发生于何时【19】。
但是，如果你的应用程序确实使用多对多关系，那么文档模型就没有那么吸引人了。通过反规范化可以减少对连接的需求，但是应用程序代码需要做额外的工作来保持数据的一致性。通过向数据库发出多个请求，可以在应用程序代码中模拟连接，但是这也将复杂性转移到应用程序中，并且通常比由数据库内的专用代码执行的连接慢。在这种情况下，使用文档模型会导致更复杂的应用程序代码和更差的性能【15】。
很难说在一般情况下哪个数据模型让应用程序代码更简单;它取决于数据项之间存在的关系种类。对于高度相联的数据，选用文档模型是糟糕的，选用关系模型是可接受的，而选用图形模型(参见"“图数据模型”)是最自然的。
文档模型中的架构灵活性
大多数文档数据库以及关系数据库中的SON支持都不会强制文档中的数据采用何种模式。关系数据库的XML支持通常带有可选的模式验证。没有模式意味着可以将任意的键和值添加到文档中，并且当读取时，客户端对无法保证文档可能包含的字段。
文档数据库有时称为无模式(schemaless)，但这具有误导性，因为读取数据的代码通常假定某种结构――即存在隐式模式，但不由数据库强制执行【20】。一个更精确的术语是读时模式(schema-on-read)(数据的结构是隐含的，只有在数据被读取时才被解释)，相应的是写时模式(schema-on-write)(传统的关系数据库方法中，模式明确，且数据库确保所有的数据都符合其模式)【21】。
读时模式类似于编程语言中的动态（运行时）类型检查，而写时模式类似于静态（编译时）类型检查。就像静态和动态类型检查的相对优点具有很大的争议性一样【22】，数据库中模式的强制性是一个具有争议的话题，一般来说没有正确或错误的答案。
在应用程序想要改变其数据格式的情况下，这些方法之间的区别尤其明显。例如，假设你把每个用户的全名存储在一个字段中，而现在想分别存储名字和姓氏【23】。在文档数据库中，只需开始写入具有新字段的新文档，并在应用程序中使用代码来处理读取旧文档的情况。例如:
if (user && user.name && !user.first_name) {
// Documents written before Dec 8, 2013 don't have first_name
user.first_name = user.name.split(" ")[0];
}
另一方面，在"静态类型"数据库模式中，通常会执行以下**迁移(migration)**操作:
ALTER TABLE users ADD COLUMN first_name text;
UPDATE users SET first_name = split_part(name, ' ', 1); -- PostgreSQL
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL
模式变更的速度很慢，而且要求停运。它的这种坏名誉并不是完全应得的︰大多数关系数据库系统可在几毫秒内执行’ALTER TABLE语句。MySQL是一个值得注意的例外，它执行ALTER TABLE时会复制整个表，这可能意味着在更改一个大型表时会花费几分钟甚至几个小时的停机时间，尽管存在各种工具来解决这个限制【24,25,26】。
大型表上运行UPDATE语句在任何数据库上都可能会很慢，因为每一行都需要重写。要是不可接受的话，应用程序可以将first_name设置为默认值NULL，并在读取时再填充，就像使用文档数据库一样。
当由于某种原因（例如，数据是异构的)集合中的项目并不都具有相同的结构时,读时模式更具优势。例如，如果:
- 存在许多不同类型的对象，将每种类型的对象放在自己的表中是不现实的。
- 数据的结构由外部系统决定。你无法控制外部系统且它随时可能变化。
在上述情况下，模式的坏处远大于它的帮助，无模式文档可能是一个更加自然的数据模型。但是，要是所有记录都具有相同的结构，那么模式是记录并强制这种结构的有效机制。第四章将更详细地讨论模式和模式演化。
查询的数据局部性
文档通常以单个连续字符串形式进行存储，编码为JSON，XML或其二进制变体〈(如MongoDB的BSON)。如果应用程序经常需要访问整个文档（例如，将其渲染至网页)，那么存储局部性会带来性能优势。如果将数据分割到多个表中(如图2-1所示)，则需要进行多次索引查找才能将其全部检索出来，这可能需要更多的磁盘查找并花费更多的时间。
局部性仅仅适用于同时需要文档绝大部分内容的情况。数据库通常需要加载整个文档，即使只访问其中的一小部分，这对于大型文档来说是很浪费的。更新文档时，通常需要整个重写。只有不改变文档大小的修改才可以容易地原地执行。因此，通常建议保持相对小的文档，并避免增加文档大小的写入【9】。这些性能限制大大减少了文档数据库的实用场景。
值得指出的是，为了局部性而分组集合相关数据的想法并不局限于文档模型。例如，Google的Spanner数据库在关系数据模型中提供了同样的局部性属性，允许模式声明一个表的行应该交错（嵌套）在父表内【27】。Oracle类似地允许使用一个称为**多表索引集群表（multi-table index cluster tables)**的类似特性【28】。Bigtable数据模型（用于Cassandra和HBase)中的列族(column-family)概念与管理局部性的目的类似【29】。
在第3章将还会看到更多关于局部性的内容。
数据查询语言
当引入关系模型时，关系模型包含了一种查询数据的新方法:SQL是一种声明式查询语言，而lMS和CODASYL使用命令式代码来查询数据库。那是什么意思?
许多常用的编程语言是命令式的。例如，给定一个动物物种的列表，返回列表中的鲨鱼可以这样写:
function getSharks() {
var sharks = [];
for (var i = 0; i < animals.length; i++) {
if (animals[i].family === "Sharks") {
sharks.push(animals[i]);
}
}
return sharks;
}
在关系代数中：
σ（希腊字⺟⻄格玛）是选择操作符，只返回符合条件的动物， family=“shark” 。定义SQL时，它紧密地遵循关系代数的结构：
SELECT * FROM animals WHERE family ='Sharks';
命令式语言告诉计算机以特定顺序执行某些操作。可以想象一下，逐行地遍历代码，评估条件，更新变量，并决定是否再循环一遍。
在声明式查询语言〈如SQL或关系代数)）中，你只需指定所需数据的模式-结果必须符合哪些条件，以及如何将数据转换〈（例如，排序，分组和集合)-但不是如何实现这一目标。数据库系统的查询优化器决定使用哪些索引和哪些连接方法，以及以何种顺序执行查询的各个部分。
声明式查询语言是迷人的，因为它通常比命令式API更加简洁和容易。但更重要的是，它还隐藏了数据库引擎的实现细节，这使得数据库系统可以在无需对查询做任何更改的情况下进行性能提升。
SQL示例不确保任何特定的顺序，因此不在意顺序是否改变。但是如果查询用命令式的代码来写的话，那么数据库就永远不可能确定代码是否依赖于排序。SQL相当有限的功能性为数据库提供了更多自动优化的空间。
最后，声明式语言往往适合并行执行。现在，CPU的速度通过内核的增加变得更快，而不是以比以前更高的时钟速度运行【31】。命令代码很难在多个内核和多个机器之间并行化，因为它指定了指令必须以特定顺序执行。声明式语言更具有并行执行的潜力，因为它们仅指定结果的模式，而不指定用于确定结果的算法。在适当情况下，数据库可以自由使用查询语言的并行实现【32】。
Web上的声明式查询
在Web浏览器中，使⽤声明式CSS样式⽐使⽤JavaScript命令式地操作样式要好得多。类似地，在数据库中，使⽤像SQL这样的声明式查询语⾔⽐使⽤命令式查询API要好得多。
MapReduce查询
MapReduce是一个由Google推广的编程模型，用于在多台机器上批量处理大规模的数据【33】。一些NoSQL数据存储（包括MongoDB和CouchDB)支持有限形式的MapReduce，作为在多个文档中执行只读查询的机制。
MapReduce将第10章中有更详细的描述。现在我们将简要讨论一下MongoDB使用的模型。
MapReduce既不是一个声明式的查询语言，也不是一个完全命令式的查询APlI，而是处于两者之间:查询的逻辑用代码片断来表示，这些代码片段会被处理框架重复性调用。它基于map(也称为collect）和reduce(也称为fold或inject〉函数，两个函数存在于许多函数式编程语言中。
最好举例来解释MapReduce模型。假设你是一名海洋生物学家，每当你看到海洋中的动物时，你都会在数据库中添加一条观察记录。现在你想生成一个报告，说明你每月看到多少鲨鱼。
在PostgreSQL中，你可以像这样表述这个查询：
SELECT
date_trunc('month', observation_timestamp) AS observation_month,
sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks'
GROUP BY observation_month;
date_trunc(‘month’，timestamp) 函数⽤于确定包含 timestamp 的日历月份，并返回代表该月份开始的另⼀个时间戳。换句话说，它将时间戳舍⼊成最近的月份。
这个查询首先过滤观察记录，以只显示鲨鱼家族的物种，然后根据它们发生的日历月份对观察记录果进行分组，最后将在该月的所有观察记录中看到的动物数目加起来。
同样的查询用MongoDB的MapReduce功能可以按如下来表述:
db.observations.mapReduce(function map() {
var year = this.observationTimestamp.getFullYear();
var month = this.observationTimestamp.getMonth() + 1;
emit(year + "-" + month, this.numAnimals);
},
function reduce(key, values) {
return Array.sum(values);
},
{
query: {
family: "Sharks"
},
out: "monthlySharkReport"
});
- 可以声明式地指定只考虑鲨鱼种类的过滤器（这是一个针对MapReduce的特定于MongoDB的扩展)。
- 每个匹配查询的文档都会调用一次JavaScript函数map，将this设置为文档对象。
- map函数发出一个键（包括年份和月份的字符串，如"2013-12"或"2014-1")和一个值（该观察记录中的动物数量)。
- map 发出的键值对按键来分组。对于具有相同键(即，相同的月份和年份)的所有键值对，调用一次reduce函数。
- reduce函数将特定月份内所有观测记录中的动物数量相加。
- 将最终的输出写入到monthlysharkReport集合中。
例如，假设 observations 集合包含这两个⽂档：
{
observationTimestamp: Date.parse( "Mon, 25 Dec 1995 12:34:56 GMT"),
family: "Sharks",
species: "Carcharodon carcharias",
numAnimals: 3
{
}
observationTimestamp: Date.parse("Tue, 12 Dec 1995 16:17:18 GMT"),
family: "Sharks",
species: "Carcharias taurus",
numAnimals: 4
}
对每个文档都会调用一次map函数，结果将是emit(“1995-12”,3)和emit( “1995-12”,4)。随后，以reduce( “1995-12”,[ 3,4])调用reduce函数，将返回7。
map和reduce函数在功能上有所限制︰它们必须是纯函数，这意味着它们只使用传递给它们的数据作为输入，它们不能执行额外的数据库查询，也不能有任何副作用。这些限制允许数据库以任何顺序运行任何功能，并在失败时重新运行它们。然而，map和reduce函数仍然是强大的︰它们可以解析字符串，调用库函数，执行计算等等。
MapReduce是一个相当底层的编程模型，用于计算机集群上的分布式执行。像SQL这样的更高级的查询语言可以用一系列的MapReduce操作来实现(见第10章)，但是也有很多不使用MapReduce的分布式SQL实现。请注意，SQL中没有任何内容限制它在单个机器上运行，而MapReduce在分布式查询执行上没有垄断权。
能够在查询中使用JavaScript代码是高级查询的一个重要特性，但这不限于MapReduce，一些SQL数据库也可以用JavaScript函数进行扩展【34】。
MapReduce的一个可用性问题是，必须编写两个密切合作的JavaScript函数，这通常比编写单个查询更困难。此外，声明式查询语言为查询优化器提供了更多机会来提高查询的性能。基于这些原因，MongoDB 2.2添加了一种叫做聚合管道的声明式查询语言的支持【9】。用这种语言表述鲨鱼计数查询如下所示:
db.observations.aggregate([
{ $match: { family: "Sharks" } },
{ $group: {
_id: {
year: { $year: "$observationTimestamp" },
month: { $month: "$observationTimestamp" }
},
totalAnimals: { $sum: "$numAnimals" } }}
]);
聚合管道语言与SQL的子集具有类似表现力，但是它使用基于JSON的语法而不是SQL的英语句子式语法;这种差异也许是口味问题。这个故事的寓意是NoSQL系统可能会发现自己意外地重新发明了SQL，尽管带着伪装。
图数据模型
如我们之前所见，多对多关系是不同数据模型之间具有区别性的重要特征。如果你的应用程序大多数的关系是一对多关系（树状结构化数据)，或者大多数记录之间不存在关系，那么使用文档模型是合适的。
但是，要是多对多关系在你的数据中很常见呢?关系模型可以处理多对多关系的简单情况，但是随着数据之间的连接变得更加复杂，将数据建模为图形显得更加自然。
一个图由两种对象组成︰顶点(vertices)(也称为节点(nodes)或实体（entities))，和边(edges)(也称为关系(relationships)或弧(arcs))。多种数据可以被建模为一个图形。典型的例子包括:
社交图谱
顶点是人，边指示哪些人彼此认识。
网络图谱
顶点是网页，边缘表示指向其他页面的HTML链接。
公路或铁路网络
顶点是交叉路口，边线代表它们之间的道路或铁路线。
可以将那些众所周知的算法运用到这些图上︰例如，汽车导航系统搜索道路网络中两点之间的最短路径，PageRank可以用在网络图上来确定网页的流行程度，从而确定该网页在搜索结果中的排名。
在刚刚给出的例子中，图中的所有顶点代表了相同类型的事物（人，网页或交叉路口)。不过，图并不局限于这样的同类数据:同样强大地是，图提供了一种一致的方式，用来在单个数据存储中存储完全不同类型的对象。例如，Facebook维护一个包含许多不同类型的顶点和边的单个图︰顶点表示人，地点，事件，签到和用户的评论;边缘表示哪些人是彼此的朋友，哪个签到发生在何处，谁评论了哪条消息，谁参与了哪个事件，等等【35】。
在本节中，我们将使用图2-5所示的示例。它可以从社交网络或系谱数据库中获得:它显示了两个人，来自爱达荷州的Lucy和来自法国Beaune的Alain。他们已婚，住在伦敦。
有几种不同但相关的方法用来构建和查询图表中的数据。在本节中，我们将讨论属性图模型（由Neo4j，Titan和InfiniteGraph实现)和三元组存储(triple-store)模型（由Datomic, AllegroGraph等实现)。我们将查看图的三种声明式查询语言:Cypher，SPARQL和Datalog。除此之外，还有像Gremlin【36】这样的图形查询语言和像Pregel这样的图形处理框架（见第10章)。
属性图
在属性图模型中，每个**顶点(vertex)**包括:
- 唯一的标识符
- 一组出边(outgoing edges)
- 一组入边(ingoing edges)
- 一组属性（键值对)
每条 边(edge) 包括:
- 唯—标识符
- 边的起点/尾部顶点(tail vertex)
- 边的终点/头部顶点(head vertex)
- 描述两个顶点之间关系类型的标签
- 一组属性(键值对)
可以将图存储看作由两个关系表组成:一个存储顶点，另一个存储边，如例2-2所示(该模式使用PostgreSQL json数据类型来存储每个顶点或每条边的属性)。头部和尾部顶点用来存储每条边﹔如果你想要一组顶点的输入或输出边，你可以分别通过head_vertex或tail_vertex来查询edges表。
例2-2 使⽤关系模式来表示属性图
#表示顶点
CREATE TABLE vertices (
vertex_id INTEGER PRIMARY KEY,
properties JSON
);
#表示边
CREATE TABLE edges (
edge_id INTEGER PRIMARY KEY,
tail_vertex INTEGER REFERENCES vertices (vertex_id),
head_vertex INTEGER REFERENCES vertices (vertex_id),
label TEXT,
properties JSON
);
CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);
关于这个模型的一些重要方面是︰
- 任何顶点都可以有一条边连接到任何其他顶点。没有模式限制哪种事物可不可以关联。
- 给定任何顶点，可以高效地找到它的入边和出边，从而遍历图，即沿着一系列顶点的路径前后移
动。(这就是为什么例2-2在tail_vertex和head_vertex列上都有索引的原因。) - 通过对不同类型的关系使用不同的标签，可以在一个图中存储几种不同的信息，同时仍然保持一个清晰的数据模型。
这些特性为数据建模提供了很大的灵活性，如图2-5所示。图中显示了一些传统关系模式难以表达的事情，例如不同国家的不同地区结构（法国有省和州，美国有不同的州和州)，国中国的怪事（先忽略主权国家和国家错综复杂的烂摊子），不同的数据粒度（Lucy现在的住所被指定为一个城市，而她的出生地点只是在一个州的级别)。
你可以想象延伸图还能包括许多关于Lucy和Alain，或其他人的其他更多的事实。例如，你可以用它来表示食物过敏（为每个过敏源增加一个顶点，并增加人与过敏源之间的一条边来指示一种过敏情况),并链接到过敏源，每个过敏源具有一组顶点用来显示哪些食物含有哪些物质。然后，你可以写一个查询，找出每个人吃什么是安全的。图表在可演化性是富有优势的:当向应用程序添加功能时，可以轻松扩展图以适应应用程序数据结构的变化。
Cypher查询语言
Cypher是属性图的声明式查询语言，为Neo4j图形数据库而发明【37】。(它是以电影"黑客帝国"中的一个角色来命名的，而与密码术中的密码无关【38】)
例2-3显示了将图2-5的左边部分插入图形数据库的Cypher查询。可以类似地添加图的其余部分，为了便于阅读而省略。每个顶点都有一个像 USA 或 Idaho 这样的符号名称，查询的其他部分可以使用这些名称在顶点之间创建边，使用箭头符号: (Idaho) - [∶ WITHIN] ->(USA) 创建一条标记为wITHIN的边，Idaho为尾节点，USA为头节点。
例2-3 将图2-5中的数据子集表示为Cypher查询
CREATE
(NAmerica:Location {name:'North America', type:'continent'}),
(USA:Location {name:'United States', type:'country' }),
(Idaho:Location {name:'Idaho', type:'state' }),
(Lucy:Person {name:'Lucy' }),
(Idaho) -[:WITHIN]-> (USA) -[:WITHIN]-> (NAmerica),
(Lucy) -[:BORN_IN]-> (Idaho)
当图2-5的所有顶点和边被添加到数据库后，让我们提些有趣的问题︰例如，找到所有从美国移民到欧洲的人的名字。更确切地说，这里我们想要找到符合下面条件的所有顶点，并且返回这些顶点的name属性︰该顶点拥有一条连到美国任一位置的BORN_IN边，和一条连到欧洲的任一位置的LIVING_IN边。
例2-4展示了如何在Cypher中表达这个查询。在MATCH子句中使用相同的箭头符号来查找图中的模式: (person)-[ : BORN_IN]->() 可以匹配 BORN_IN边的任意两个顶点。该边的尾节点被绑定了变量person ，头节点则未被绑定。
例2-4 查找所有从美国移民到欧洲的人的Cypher查询：
MATCH
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United
States'}),
(person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name
查询按如下来解读：
找到满⾜以下两个条件的所有顶点（称之为person顶点）：
- person 顶点拥有⼀条到某个顶点的 BORN_IN 出边。从那个顶点开始，沿着⼀系列 WITHIN出边最终到达⼀个类型为 Location ， name 属性为 United States 的顶点。
- person 顶点还拥有⼀条 LIVES_IN 出边。沿着这条边，可以通过⼀系列 WITHIN 出边最终到达⼀个类型为 Location ， name 属性为 Europe 的顶点。
对于这样的 Person 顶点，返回其 name 属性。
执行这条查询可能会有几种可行的查询路径。这里给出的描述建议首先扫描数据库中的所有人，检查每个人的出生地和居住地，然后只返回符合条件的那些人。
等价地，也可以从两个Location顶点开始反向地查找。假如name属性上有索引，则可以高效地找到代表美国和欧洲的两个顶点。然后，沿着所有wITHIN入边，可以继续查找出所有在美国和欧洲的位置(州，地区，城市等）。最后，查找出那些可以由BORN_IN或LIVES_IN入边到那些位置顶点的人。
通常对于声明式查询语言来说，在编写查询语句时，不需要指定执行细节︰查询优化程序会自动选择预测效率最高的策略，因此你可以继续编写应用程序的其他部分。
SQL中的图查询
例2-2建议在关系数据库中表示图数据。但是，如果把图数据放入关系结构中，我们是否也可以使用SQL查询它?
答案是肯定的，但有些困难。在关系数据库中，你通常会事先知道在查询中需要哪些连接。在图查询中，你可能需要在找到待查找的顶点之前，遍历可变数量的边。也就是说，连接的数量事先并不确定。
在我们的例子中，这发生在Cypher查询中的 () -[ :WITHIN*0…]->() 规则中。一个人的 LIVBS_IN 边可以指向任何类型的位置:街道，城市，地区，地区，国家等。城市可以在一个地区，在一个州内的一个地区，在一个国家内的一个州等等。LIVES_IN 边可以直接指向正在查找的位置，或者一个在位置层次结构中隔了数层的位置。
在Cypher中，用 WITHIN * 0 非常简洁地表述了上述事实:“沿着 WITHIN 边，零次或多次"。它很像正则表达式中的 * 运算符。
自SQL:1999，查询可变长度遍历路径的思想可以使用称为递归公用表表达式（ WITH RECURSIVE 语法)的东西来表示。例2-5显示了同样的查询-查找从美国移民到欧洲的人的姓名-在SQL使用这种技术(PostgreSQL，IBM DB2，Oracle和SQLServer均支持）来表述。但是，与Cypher相比，其语法非常笨拙。
例2-5 与示例2-4同样的查询，在SQL中使⽤递归公⽤表表达式表示
WITH RECURSIVE
-- in_usa 包含所有的美国境内的位置ID
in_usa(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'United States'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'within'
),
-- in_europe 包含所有的欧洲境内的位置ID
in_europe(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'Europe'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'within' ),
-- born_in_usa 包含了所有类型为Person，且出⽣在美国的顶点
born_in_usa(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'born_in' ),
-- lives_in_europe 包含了所有类型为Person，且居住在欧洲的顶点。
lives_in_europe(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'lives_in')
SELECT vertices.properties ->> 'name'
FROM vertices
JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id
JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;
- 首先，查找name 属性为united states的顶点，将其作为in_use顶点的集合的第一个元素。
- 从in_use集合的顶点出发，沿着所有的with_in入边，将其尾顶点加入同一集合，不断递归直到所有with_in入边都被访问完毕。
- 同理，从name属性为Europe的顶点出发，建立in_europe 顶点的集合。
- 对于in_usa集合中的每个顶点，根据born_in入边来查找出生在美国某个地方的人。
- 同样，对于in_europe集合中的每个顶点，根据lives_in入边来查找居住在欧洲的人。
- 最后，把在美国出生的人的集合与在欧洲居住的人的集合相交。
同一个查询，用某一个查询语言可以写成4行，而用另一个查询语言需要29行，这恰恰说明了不同的数据模型是为不同的应用场景而设计的。选择适合应用程序的数据模型非常重要。
三元组存储和SPARQL
三元组存储模式大体上与属性图模型相同，用不同的词来描述相同的想法。不过仍然值得讨论，因为三元组存储有很多现成的工具和语言，这些工具和语言对于构建应用程序的工具箱可能是宝贵的补充。
在三元组存储中，所有信息都以非常简单的三部分表示形式存储 （主语，谓语，宾语) 。例如，三元组(吉姆,喜欢,香蕉)中，吉姆是主语，喜欢是谓语(动词)，香蕉是对象。
三元组的主语相当于图中的一个顶点。而宾语是下面两者之一:
- 原始数据类型中的值，例如字符串或数字。在这种情况下，三元组的谓语和宾语相当于主语顶点上的属性的键和值。例如，(lucy,age，33)就像属性{ " age": 33}的顶点lucy。
- 图中的另一个顶点。在这种情况下，谓语是图中的一条边，主语是其尾部顶点，而宾语是其头部顶点。例如，在 (lucy,marriedTo，alain)中主语和宾语1ucy和alain都是顶点，并且谓语marriedTo是连接他们的边的标签。
例2-6显示了与例2-3相同的数据，以称为Turtle的格式(Notation3(N3)【39】 )的一个子集形式写成三元组。
例2-6 图2-5中的数据子集，表示为Turtle三元组
@prefix : <urn:example:>.
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location
_:usa :name "United States"
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location
_:namerica :name "North America"
_:namerica :type :"continent"
在这个例子中，图的顶点被写为:_ : someName 。这个名字并不意味着这个文件以外的任何东西。它的存在只是帮助我们明确哪些三元组引用了同一顶点。当谓语表示边时，该宾语是一个顶点，如 _:idaho:within _:usa. 。当谓语是一个属性时，该宾语是一个字符串，如 _:usa :name “United states”
一遍又一遍地重复相同的主语看起来相当重复，但幸运的是，可以使用分号来说明关于同一主语的多个事情。这使得Turtle格式相当不错，可读性强:参见例2-7。
例2-7一种相对例2-6写入数据的更为简洁的方法。
@prefix : <urn:example:>.
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa
_:usa a :Loaction; :name "United States"; :type "country"; :within_:namerica.
_:namerica a :Location; :name "North America"; :type "continent".
语义网络
如果你阅读更多关于三元组存储的信息，你可能会被卷入关于语义网络的文章漩涡中。三元组存储数据模型完全独立于语义网络，例如，Datomic 【40】是三元组存储，并没有声称与它有任何关系。但是，由于在很多人眼中这两者紧密相连，我们应该简要地讨论一下。
从本质上讲语义网是一个简单且合理的想法:网站已经将信息发布为文字和图片供人类阅读，为什么不将信息作为机器可读的数据也发布给计算机呢?资源描述框架（RDF)【41】的目的是作为不同网站以一致的格式发布数据的一种机制，允许来自不同网站的数据自动合并成一个数据网络-一种互联网范围内的“关于一切的数据库”。
不幸的是，这个语义网在二十一世纪初被过度使用，但到目前为止没有任何迹象表明已在实践中实现，这使得许多人咄之以鼻。它还遭受了过多的令人眼花缭乱的缩略词，过于复杂的标准提议和狂妄自大的苦果。
然而，如果仔细观察这些失败，语义Web项目还是拥有很多优秀的工作成果。即使你没有兴趣在语义网上发布RDF数据，三元组也可以成为应用程序的良好内部数据模型。
RDF数据模型
例2-7中使用的Turtle语言是一种用于RDF数据的人可读格式。有时候，RDF也可以以XML格式编写，不过完成同样的事情会相对啰嗦，参见例2-8。Turtle/N3是更可取的，因为它更容易阅读，像ApacheJena 【42】这样的工具可以根据需要在不同的RDF格式之间进行自动转换。
例2-8用RDF/XML语法表示例2-7的数据
<rdf:RDF xmlns="urn:example:"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Location rdf:nodeID="idaho">
<name>Idaho</name>
<type>state</type>
<within>
<Location rdf:nodeID="usa">
<name>United States</name>
<type>country</type>
<within>
<Location rdf:nodeID="namerica">
<name>North America</name>
<type>continent</type>
</Location>
</within>
</Location>
</within>
</Location>
<Person rdf:nodeID="lucy">
<name>Lucy</name>
<bornIn rdf:nodeID="idaho"/>
</Person>
</rdf:RDF>
RDF有一些奇怪之处，因为它是为了在互联网上交换数据而设计的。三元组的主语，谓语和宾语通常是URI。例如，谓语可能是一个URl，如 <http: / /my-company.com/namespace#within> 或 <http: //my-company.com/namespace#lives_in>，而不仅仅是wITHIN或LIVES_IN。这个设计背后的原因为了让你能够把你的数据和其他人的数据结合起来，如果他们赋予单词within或者lives_in不同的含义，两者也不会冲突，因为它们的谓语实际上是 < http://other.org/foo#within > 和 < http://other.org/foo#lives_in >。
从RDF的角度来看，URL <http:/ /my-company.com/namespace>不一定需要能解析成什么东西，它只是一个命名空间。为避免与http:/ /URL混淆，本节中的示例使用不可解析的URl，如 urn:example: within。幸运的是，你只需在文件顶部指定一个前缀，然后就不用再管了。
SPARQL查询语言
SPARQL是一种用于三元组存储的面向RDF数据模型的查询语言，【43】。(它是SPARQL协议和RDF查询语言的缩写，发音为"sparkle"。) SPARQL早于Cypher，并且由于Cypher的模式匹配借鉴于SPARQL，这使得它们看起来非常相似【37】。
与之前相同的查询-查找从美国转移到欧洲的人-使用SPARQL比使用Cypher甚至更为简洁（参见例2-9)。
例2-9与示例2-4相同的查询，用SPARQL表示
PREFIX : <urn:example:>
SELECT ?personName WHERE {
?person :name ?personName.
?person :bornIn / :within* / :name "United States".
?person :livesIn / :within* / :name "Europe".
}
结构非常相似。以下两个表达式是等价的(SPARQL中的变量以问号开头):
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location) # Cypher
?person :bornIn / :within* ?location. # SPARQL
因为RDF不区分属性和边，而只是将它们作为谓语，所以可以使用相同的语法来匹配属性。在下面的表达式中，变量usa被绑定到任意具有值为字符串"United states"的name属性的顶点:
(usa {name:'United States'}) # Cypher
?usa :name "United States". # SPARQL
SPARQL是一种很好的查询语言――哪怕语义网从未实现，它仍然可以成为一种应用程序内部使用的强大工具。
图形数据库与⽹络模型相⽐较
在“⽂档数据库是否在重蹈覆辙？”中，我们讨论了CODASYL和关系模型如何竞相解决IMS中的多对多关系问题。乍⼀看，CODASYL的⽹络模型看起来与图模型相似。CODASYL是否是图形数据库的第⼆个变种？
不，他们在⼏个重要⽅⾯有所不同：
- 在CODASYL中，数据库有⼀个模式，⽤于指定哪种记录类型可以嵌套在其他记录类型中。在图形数据库中，不存在这样的限制：任何顶点都可以具有到其他任何顶点的边。这为应⽤程序适应不断变化的需求提供了更⼤的灵活性。
- 在CODASYL中，达到特定记录的唯⼀⽅法是遍历其中的⼀个访问路径。在图形数据库中，可以通过其唯⼀ID直接引⽤任何顶点，也可以使⽤索引来查找具有特定值的顶点。
- 在CODASYL，记录的后续是⼀个有序集合，所以数据库的⼈不得不维持排序（这会影响存储布局），并且插⼊新记录到数据库的应⽤程序不得不担⼼的新记录在这些集合中的位置。在图形数据库中，顶点和边不是有序的（只能在查询时对结果进⾏排序）。
- 在CODASYL中，所有查询都是命令式的，难以编写，并且很容易因架构中的变化⽽受到破坏。在图形数据库中，如果需要，可以在命令式代码中编写遍历，但⼤多数图形数据库也⽀持⾼级声明式查询语⾔，如Cypher或SPARQL。
基础：Datalog
Datalog是比SPARQL或Cypher更古老的语言，在20世纪80年代被学者广泛研究【44,45,46】。它在软件工程师中不太知名，但是它是重要的，因为它为以后的查询语言提供了基础。
在实践中，Datalog被用于少数的数据系统中:例如，它是Datomic 【40】的查询语言，Cascalog【47】是一种用于查询Hadoop大数据集的Datalog实现。
Datalog的数据模型类似于三元组模式，但进行了一点泛化。把三元组写成谓语（主语，宾语)，而不是写三元语（主语，宾语，宾语)。例2-10显示了如何用Datalog写入我们的例子中的数据。
例2-10 用Datalog来表示图2-5中的数据子集
name(namerica, 'North America').
type(namerica, continent).
name(usa, 'United States').
type(usa, country).
within(usa, namerica).
name(idaho, 'Idaho').
type(idaho, state).
within(idaho, usa).
name(lucy, 'Lucy').
born_in(lucy, idaho).
既然已经定义了数据，我们可以像之前一样编写相同的查询，如例2-11所示。它看起来有点不同于Cypher或SPARQL的等价物，但是请不要放弃它。Datalog是Prolog的一个子集，如果你学过计算机科学，你可能已经见过。
例2-11与示例2-4相同的查询，用Datalog表示
within_recursive(Location, Name) :- name(Location, Name). /* Rule 1 */
within_recursive(Location, Name) :- within(Location, Via), /* Rule 2 */
within_recursive(Via, Name).
migrated(Name, BornIn, LivingIn) :- name(Person, Name), /* Rule 3 */
born_in(Person, BornLoc),
within_recursive(BornLoc, BornIn),
lives_in(Person, LivingLoc),
within_recursive(LivingLoc, LivingIn).
?- migrated(Who, 'United States', 'Europe'). /* Who = 'Lucy'. */
Cypher和SPARQL使用SELECT立即跳转，但是Datalog一次只进行一小步。我们定义规则，以将新谓语告诉数据库︰在这里，我们定义了两个新的谓语，_recursive 和 migrated。这些谓语不是存储在数据库中的三元组中，而是它们是从数据或其他规则派生而来的。规则可以引用其他规则，就像函数可以调用其他函数或者递归地调用自己一样。像这样，复杂的查询可以一次构建其中的一小块。
在规则中，以大写字母开头的单词是变量，谓语则用Cypher和SPARQL的方式一样来匹配。例如， name(Location，Name) 通过变量绑定 Location = namerica 和 Name =‘North America’ 可以匹配三元组 name ( namerica，'North America ’ ) 。
要是系统可以在 :- 操作符的右侧找到与所有谓语的一个匹配，就运用该规则。当规则运用时，就好像通过 :- 的左侧将其添加到数据库（将变量替换成它们匹配的值)。
因此，一种可能的应用规则的方式是:
- 数据库存在 name(namerica, ‘North America’) ，故运⽤规则1。它⽣成 within_recursive(namerica, ‘North America’) 。
- 数据库存在 within(usa, namerica) ，在上⼀步骤中⽣成 within_recursive(namerica,
‘North America’) ，故运⽤规则2。它会产⽣ within_recursive(usa, ‘NorthAmerica’) 。 - 数据库存在 within(idaho, usa) ，在上⼀步⽣成 within_recursive(usa, ‘North
America’) ，故运⽤规则2。它产⽣ within_recursive(idaho, ‘North America’) 。
通过重复应用规则1和2，within_recursive谓语可以告诉我们在数据库中包含北美(或任何其他位置名称)的所有位置。这个过程如图2-6所示。
现在规则3可以找到出生在某个地方BornIn的人，并住在某个地方 LivingIn 。通过查询 BornIn = ‘United states’ 和 LivingIn =‘Europe’ ，并将此人作为变量who，让Datalog系统找出变量who会出现哪些值。因此，最后得到了与早先的Cypher和SPARQL查询相同的答案。
相对于本章讨论的其他查询语言，我们需要采取不同的思维方式来思考Datalog方法，但这是一种非常强大的方法，因为规则可以在不同的查询中进行组合和重用。虽然对于简单的一次性查询，显得不太方便，但是它可以更好地处理数据很复杂的情况。
本章小结
数据模型是一个巨大的课题，在本章中，我们快速浏览了各种不同的模型。我们没有足够的空间来详细介绍每个模型的细节，但是希望这个概述足以激起你的兴趣，以更多地了解最适合你的应用需求的模型。
在历史上，数据最开始被表示为一棵大树（层次数据模型)，但是这不利于表示多对多的关系，所以发明了关系模型来解决这个问题。最近，开发人员发现一些应用程序也不适合采用关系模型。新的非关系型“NoSQL"数据存储在两个主要方向上存在分歧:
- 文档数据库的应用场景是:数据通常是自我包含的，而且文档之间的关系非常稀少。
- 图形数据库用于相反的场景:任意事物都可能与任何事物相关联。
这三种模型（文档，关系和图形）在今天都被广泛使用，并且在各自的领域都发挥很好。一个模型可以用另一个模型来模拟。例如，图数据可以在关系数据库中表示―但结果往往是糟糕的。这就是为什么我们有着针对不同目的的不同系统，而不是一个单一的万能解决方案。
文档数据库和图数据库有一个共同点，那就是它们通常不会为存储的数据强制一个模式，这可以使应用程序更容易适应不断变化的需求。但是应用程序很可能仍会假定数据具有一定的结构;这只是模式是明确的（写入时强制)还是隐含的（读取时处理)的问题。
每个数据模型都具有各自的查询语言或框架，我们讨论了几个例子:SQL，MapReduce，MongoDB的聚合管道，Cypher，SPARQL和Datalog。我们也谈到了CSS和XSL/XPath，它们不是数据库查询语言，而包含有趣的相似之处。
虽然我们已经覆盖了很多层面，但仍然有许多数据模型没有提到。举几个简单的例子:
- 使用基因组数据的研究人员通常需要执行序列相似性搜索，这意味着需要一个很长的字符串(代表一个DNA分子)，并在一个拥有类似但不完全相同的字符串的大型数据库中寻找匹配。这里所描述的数据库都不能处理这种用法，这就是为什么研究人员编写了像GenBank这样的专门的基因组数据库软件的原因【48】。
- 粒子物理学家数十年来一直在进行大数据类型的大规模数据分析，像大型强子对撞机(LHC)这样的项目现在可以工作在数百亿兆字节的范围内!在这样的规模下，需要定制解决方案来阻住硬件成本的失控【49】。
- 全文搜索可以说是一种经常与数据库一起使用的数据模型。信息检索是一个很大的专业课题，我们不会在本书中详细介绍，但是我们将在第三章和第三章中介绍搜索索引。
让我们暂时将其放在一边。在下一章中，我们将讨论在实现本章描述的数据模型时会遇到的一些权衡。
参考文献
- Edgar F. Codd: “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM, volume 13, number 6, pages 377–387, June 1970. doi:10.1145/362384.362685
- Michael Stonebraker and Joseph M. Hellerstein: “What Goes Around Comes Around,” in Readings in Database Systems, 4th edition, MIT Press, pages 2–41, 2005. ISBN: 978-0-262-69314-1
- Pramod J. Sadalage and Martin Fowler: NoSQL Distilled. Addison-Wesley, August 2012. ISBN: 978-0-321-82662-6
- Eric Evans: “NoSQL: What’s in a Name?,” blog.sym-link.com, October 30, 2009.
- James Phillips: “Surprises in Our NoSQL Adoption Survey,” blog.couchbase.com, February 8,2012.
- Michael Wagner: SQL/XML:2006 – Evaluierung der Standardkonformität ausgewählter Datenbanksysteme. Diplomica Verlag, Hamburg, 2010. ISBN: 978-3-836-64609-3
- “XML Data in SQL Server,” SQL Server 2012 documentation, technet.microsoft.com, 2013.
- “PostgreSQL 9.3.1 Documentation,” The PostgreSQL Global Development Group, 2013.
- “The MongoDB 2.4 Manual,” MongoDB, Inc., 2013.
- “RethinkDB 1.11 Documentation,” rethinkdb.com, 2013.
- “Apache CouchDB 1.6 Documentation,” docs.couchdb.org, 2014.
- Lin Qiao, Kapil Surlaker, Shirshanka Das, et al.: “On Brewing Fresh Espresso: LinkedIn’s Distributed Data Serving Platform,” at ACM International Conference on Management of Data(SIGMOD), June 2013.
- Rick Long, Mark Harrington, Robert Hain, and Geoff Nicholls: IMS Primer. IBM Redbook SG24-5352-00, IBM International Technical Support Organization, January 2000.
- Stephen D. Bartlett: “IBM’s IMS—Myths, Realities, and Opportunities,” The Clipper Group Navigator, TCG2013015LI, July 2013.
- Sarah Mei: “Why You Should Never Use MongoDB,” sarahmei.com, November 11, 2013.
- J. S. Knowles and D. M. R. Bell: “The CODASYL Model,” in Databases—Role and Structure: An Advanced Course, edited by P. M. Stocker, P. M. D. Gray, and M. P. Atkinson, pages 19–56, Cambridge University Press, 1984. ISBN: 978-0-521-25430-4
- Charles W. Bachman: “The Programmer as Navigator,” Communications of the ACM, volume 16, number 11, pages 653–658, November 1973.doi:10.1145/355611.362534
- Joseph M. Hellerstein, Michael Stonebraker, and James Hamilton: “Architecture of a Database System,” Foundations and Trends in Databases, volume 1, number 2, pages 141–259, November 2007. doi:10.1561/1900000002
- Sandeep Parikh and Kelly Stirman: “Schema Design for Time Series Data in MongoDB,” blog.mongodb.org, October 30, 2013.
- Martin Fowler: “Schemaless Data Structures,” martinfowler.com, January 7, 2013.
- Amr Awadallah: “Schema-on-Read vs. Schema-on-Write,” at Berkeley EECS RAD Lab Retreat, Santa Cruz, CA, May 2009.
- Martin Odersky: “The Trouble with Types,” at Strange Loop, September 2013.
- Conrad Irwin: “MongoDB—Confessions of a PostgreSQL Lover,” at HTML5DevConf, October 2013.
- “Percona Toolkit Documentation: pt-online-schema-change,” Percona Ireland Ltd., 2013.
- Rany Keddo, Tobias Bielohlawek, and Tobias Schmidt: “Large Hadron Migrator,” SoundCloud, 2013. Shlomi Noach: “gh-ost: GitHub’s Online Schema Migration Tool for MySQL,” githubengineering.com, August 1, 2016.
- James C. Corbett, Jeffrey Dean, Michael Epstein, et al.: “Spanner: Google’s GloballyDistributed Database,” at 10th USENIX Symposium on Operating System Design and Implementation (OSDI), October 2012.
- Donald K. Burleson: “Reduce I/O with Oracle Cluster Tables,” dba-oracle.com.
- Fay Chang, Jeffrey Dean, Sanjay Ghemawat, et al.: “Bigtable: A Distributed Storage System for Structured Data,” at 7th USENIX Symposium on Operating System Design and Implementation (OSDI), November 2006.
- Bobbie J. Cochrane and Kathy A. McKnight: “DB2 JSON Capabilities, Part 1: Introduction to DB2 JSON,” IBM developerWorks, June 20, 2013.
- Herb Sutter: “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software,” Dr. Dobb’s Journal, volume 30, number 3, pages 202-210, March 2005.
- Joseph M. Hellerstein: “The Declarative Imperative: Experiences and Conjectures in Distributed Logic,” Electrical Engineering and Computer Sciences, University of California at Berkeley, Tech report UCB/EECS-2010-90, June 2010.
- Jeffrey Dean and Sanjay Ghemawat: “MapReduce: Simplified Data Processing on Large Clusters,” at 6th USENIX Symposium on Operating System Design and Implementation (OSDI), December 2004.
- Craig Kerstiens: “JavaScript in Your Postgres,” blog.heroku.com, June 5, 2013.
- Nathan Bronson, Zach Amsden, George Cabrera, et al.: “TAO: Facebook’s Distributed Data Store for the Social Graph,” at USENIX Annual Technical Conference (USENIX ATC), June 2013.
- “Apache TinkerPop3.2.3 Documentation,” tinkerpop.apache.org, October 2016.
- “The Neo4j Manual v2.0.0,” Neo Technology, 2013. Emil Eifrem: Twitter correspondence, January 3, 2014.
- David Beckett and Tim Berners-Lee: “Turtle – Terse RDF Triple Language,” W3C Team Submission, March 28, 2011.
- “Datomic Development Resources,” Metadata Partners, LLC, 2013. W3C RDF Working Group: “Resource Description Framework (RDF),” w3.org, 10 February 2004.
- “Apache Jena,” Apache Software Foundation.
- Steve Harris, Andy Seaborne, and Eric Prud’hommeaux: “SPARQL 1.1 Query Language,” W3C Recommendation, March 2013.
- Todd J. Green, Shan Shan Huang, Boon Thau Loo, and Wenchao Zhou: “Datalog and Recursive Query Processing,” Foundations and Trends in Databases, volume 5, number 2, pages 105–195, November 2013. doi:10.1561/1900000017
- Stefano Ceri, Georg Gottlob, and Letizia Tanca: “What You Always Wanted to Know About Datalog (And Never Dared to Ask),” IEEE Transactions on Knowledge and Data Engineering, volume 1, number 1, pages 146–166, March 1989. doi:10.1109/69.43410
- Serge Abiteboul, Richard Hull, and Victor Vianu: Foundations of Databases. Addison-Wesley, 1995. ISBN: 978-0-201-53771-0, available online at webdam.inria.fr/Alice
- Nathan Marz: “Cascalog," cascalog.org. Dennis A. Benson, Ilene Karsch-Mizrachi, David J. Lipman, et al.: “GenBank,” Nucleic Acids Research, volume 36, Database issue, pages D25–D30, December 2007. doi:10.1093/nar/gkm929
- Fons Rademakers: “ROOT for Big Data Analysis,” at Workshop on the Future of Big Data Management, London, UK, June 2013.
标签：02,name,数据库,查询,Intensive,文档,顶点,数据模型 来源： https://blog.csdn.net/u011552171/article/details/113702320
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。