The Birth of NoSQL

Now, in the 2010s, NoSQL is the latest attempt to overthrow the relational model’s dominance. The name “NoSQL” is unfortunate, since it doesn’t actually refer to any particular technology—it was originally intended simply as a catchy Twitter hashtag for a meetup on open source, distributed, nonrelational databases in 2009 [ 3 ]. Nevertheless, the term struck a nerve and quickly spread through the web startup community and beyond. A number of interesting database systems are now associated with the #NoSQL hashtag, and it has been retroactively reinterpreted as Not Only SQL [ 4 ].

现在，在2010年代， NoSQL是最新的尝试，试图推翻关系模型的统治地位。由于最初它只是一个流行的 Twitter 标签，用于描述开放源代码、分布式和非关系型数据库的会议，因此“NoSQL”这个名称有些不幸。然而，这个术语引起了人们的注意，并很快在网络创业社区和其他领域传播开来。现在，一些有趣的数据库系统与 #NoSQL 标签相关联，并被重新解释为“Not Only SQL”。

There are several driving forces behind the adoption of NoSQL databases, including:

NoSQL数据库被采用的原因有几个驱动力，包括：

• A need for greater scalability than relational databases can easily achieve, including very large datasets or very high write throughput

  需要更大规模的可扩展性，超过关系数据库可以轻松实现的范围，包括非常大的数据集或非常高的写入吞吐量。

• A widespread preference for free and open source software over commercial database products

  使用免费和开放源码软件的普遍选择，胜过于商业数据库产品。

• Specialized query operations that are not well supported by the relational model

  不受关系模型很好支持的专业查询操作。

• Frustration with the restrictiveness of relational schemas, and a desire for a more dynamic and expressive data model [ 5 ]

  对关系模式限制性的挫败感，以及对更动态和富有表现力的数据模型的渴望。

Different applications have different requirements, and the best choice of technology for one use case may well be different from the best choice for another use case. It therefore seems likely that in the foreseeable future, relational databases will continue to be used alongside a broad variety of nonrelational datastores—an idea that is sometimes called polyglot persistence [ 3 ].

不同的应用有不同的需求，而一个用例的最佳技术选择可能与另一个用例的最佳选择不同。因此，有可能在可预见的未来，关系型数据库将继续与各种非关系型数据存储一起使用，这个想法有时被称为多语言持久性。

The Object-Relational Mismatch

Most application development today is done in object-oriented programming languages, which leads to a common criticism of the SQL data model: if data is stored in relational tables, an awkward translation layer is required between the objects in the application code and the database model of tables, rows, and columns. The disconnect between the models is sometimes called an impedance mismatch . ⁱ

如今，大多数应用程序开发都是使用面向对象的编程语言完成的，这导致了对 SQL 数据模型的普遍批评：如果数据存储在关系表中，则应用程序代码中的对象和基于表、行和列的数据库模型之间需要使用一种笨拙的翻译层来建立联系。这种模型之间的不连贯有时被称为阻抗不匹配。

Object-relational mapping (ORM) frameworks like ActiveRecord and Hibernate reduce the amount of boilerplate code required for this translation layer, but they can’t completely hide the differences between the two models.

对象关系映射（ORM）框架如ActiveRecord和Hibernate可减少翻译层所需的样板代码量，但它们无法完全隐藏两个模型之间的差异。

For example, Figure 2-1 illustrates how a résumé (a LinkedIn profile) could be expressed in a relational schema. The profile as a whole can be identified by a unique identifier, user_id . Fields like first_name and last_name appear exactly once per user, so they can be modeled as columns on the users table. However, most people have had more than one job in their career (positions), and people may have varying numbers of periods of education and any number of pieces of contact information. There is a one-to-many relationship from the user to these items, which can be represented in various ways:

例如，图2-1说明了如何将简历（LinkedIn个人资料）表达为关系模式。整个个人资料可以通过唯一标识符user_id进行识别。像first_name和last_name这样的字段每个用户只出现一次，因此它们可以被建模为用户表中的列。然而，大多数人在他们的职业生涯中都有过多个工作（职位），人们可能会有不同数量的教育期间和任何数量的联系方式。从用户到这些项目的关系是一对多的，可以用不同的方法来表示。

• In the traditional SQL model (prior to SQL:1999), the most common normalized representation is to put positions, education, and contact information in separate tables, with a foreign key reference to the users table, as in Figure 2-1 .

  在传统的SQL模型（SQL:1999之前），最常见的标准化表示法是将职位，教育和联系信息放置在单独的表中，并参照用户表进行外键引用，如图2-1。

• Later versions of the SQL standard added support for structured datatypes and XML data; this allowed multi-valued data to be stored within a single row, with support for querying and indexing inside those documents. These features are supported to varying degrees by Oracle, IBM DB2, MS SQL Server, and PostgreSQL [ 6 , 7 ]. A JSON datatype is also supported by several databases, including IBM DB2, MySQL, and PostgreSQL [ 8 ].

  SQL标准的更新版本支持结构化数据类型和XML数据；这使得可以将多值数据存储在单个行中，并支持在这些文档内进行查询和索引。这些功能在Oracle、IBM DB2、MS SQL Server和PostgreSQL [6、7]中的支持程度有所不同。JSON数据类型也被多个数据库支持，包括IBM DB2、MySQL和PostgreSQL [8]。

• A third option is to encode jobs, education, and contact info as a JSON or XML document, store it on a text column in the database, and let the application interpret its structure and content. In this setup, you typically cannot use the database to query for values inside that encoded column.

  第三个选项是将工作、教育和联系信息编码为JSON或XML文档，将其存储在数据库的文本列中，并让应用程序解释其结构和内容。在这种设置中，您通常无法使用数据库查询该编码列内部的值。

Figure 2-1. Representing a LinkedIn profile using a relational schema. Photo of Bill Gates courtesy of Wikimedia Commons, Ricardo Stuckert, Agência Brasil.

For a data structure like a résumé, which is mostly a self-contained document , a JSON representation can be quite appropriate: see Example 2-1 . JSON has the appeal of being much simpler than XML. Document-oriented databases like MongoDB [ 9 ], RethinkDB [ 10 ], CouchDB [ 11 ], and Espresso [ 12 ] support this data model.

对于像简历这样的数据结构，它主要是一个自包含的文档，JSON表示可以非常适合：参见例子2-1。JSON比XML简单得多，具有吸引力。文档导向型数据库，如MongoDB、RethinkDB、CouchDB和Espresso都支持这种数据模型。

{
  "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"
  }
}

Some developers feel that the JSON model reduces the impedance mismatch between the application code and the storage layer. However, as we shall see in Chapter 4 , there are also problems with JSON as a data encoding format. The lack of a schema is often cited as an advantage; we will discuss this in “Schema flexibility in the document model” .

一些开发人员认为，JSON模型减少了应用程序代码和存储层之间的阻抗失配。然而，正如我们将在第4章中看到的那样，JSON作为数据编码格式也存在问题。缺乏模式通常被引用作为优点;我们将在“文档模型中的模式灵活性”中讨论这个问题。

The JSON representation has better locality than the multi-table schema in Figure 2-1 . If you want to fetch a profile in the relational example, you need to either perform multiple queries (query each table by user_id ) or perform a messy multi-way join between the users table and its subordinate tables. In the JSON representation, all the relevant information is in one place, and one query is sufficient.

JSON表示法比2-1图中的多表模式具有更好的局部性。如果您想在关系示例中获取配置文件，您需要执行多个查询（通过user_id查询每个表）或在用户表及其从属表之间执行混乱的多向连接。在JSON表示法中，所有相关信息都在一个地方，只需要一次查询即可。

The one-to-many relationships from the user profile to the user’s positions, educational history, and contact information imply a tree structure in the data, and the JSON representation makes this tree structure explicit (see Figure 2-2 ).

用户档案与用户职位，教育历史和联系方式之间的一对多关系意味着数据中的树形结构，JSON表示明确了这种树形结构（请参见图2-2）。

Figure 2-2. One-to-many relationships forming a tree structure.

Many-to-One and Many-to-Many Relationships

In Example 2-1 in the preceding section, region_id and industry_id are given as IDs, not as plain-text strings "Greater Seattle Area" and "Philanthropy" . Why?

为什么在前面的章节中的示例2-1中，region_id和industry_id是作为ID给出的，而不是作为纯文本字符串"Greater Seattle Area"和"Philanthropy"呢？

If the user interface has free-text fields for entering the region and the industry, it makes sense to store them as plain-text strings. But there are advantages to having standardized lists of geographic regions and industries, and letting users choose from a drop-down list or autocompleter:

如果用户界面有用于输入地区和行业的自由文本字段，则将它们存储为纯文本字符串是有意义的。但是，具有标准化的地理区域和行业列表，并让用户从下拉列表或自动完成器中选择是有优势的：

• Consistent style and spelling across profiles

  个人资料中风格和拼写要保持一致。

• Avoiding ambiguity (e.g., if there are several cities with the same name)

  避免歧义（例如，如果有几个同名城市）

• Ease of updating—the name is stored in only one place, so it is easy to update across the board if it ever needs to be changed (e.g., change of a city name due to political events)

  易于更新——名称只存储在一个地方，如果需要更改（例如，由于政治事件更改城市名称），则可以轻松在整个平台上进行更新。

• Localization support—when the site is translated into other languages, the standardized lists can be localized, so the region and industry can be displayed in the viewer’s language

  本地化支持-当网站翻译为其他语言时，标准化列表可以本地化，以便在观看者的语言中显示地区和行业。

• Better search—e.g., a search for philanthropists in the state of Washington can match this profile, because the list of regions can encode the fact that Seattle is in Washington (which is not apparent from the string "Greater Seattle Area" )

  更好的搜索-例如，在华盛顿州搜寻慈善家可以匹配此档案，因为地区列表可以编码西雅图是华盛顿州的事实（这一点在“大西雅图地区”这个字符串中不明显）。

Whether you store an ID or a text string is a question of duplication. When you use an ID, the information that is meaningful to humans (such as the word Philanthropy ) is stored in only one place, and everything that refers to it uses an ID (which only has meaning within the database). When you store the text directly, you are duplicating the human-meaningful information in every record that uses it.

无论你存储一个ID还是文本字符串，都是一个重复的问题。当你使用ID时，对于人类有意义的信息（例如“慈善”这个词）只存储在一个位置，而所有引用它的内容都使用ID（它只有在数据库中有意义）。当你直接存储文本时，你将在每个使用它的记录中复制人类有意义的信息。

The advantage of using an ID is that because it has no meaning to humans, it never needs to change: the ID can remain the same, even if the information it identifies changes. Anything that is meaningful to humans may need to change sometime in the future—and if that information is duplicated, all the redundant copies need to be updated. That incurs write overheads, and risks inconsistencies (where some copies of the information are updated but others aren’t). Removing such duplication is the key idea behind normalization in databases. ⁱⁱ

使用ID的优点在于，由于它对人类没有意义，所以它永远不需要更改：即使所识别的信息发生更改，ID仍然可以保持不变。对人类有意义的任何内容都可能在将来需要更改 - 如果该信息被复制，所有冗余副本都需要更新。这会增加写入开销，并存在不一致性的风险（其中一些信息的副本得到更新，但其他副本没有）。消除这种重复是数据库规范化的关键思想。

Unfortunately, normalizing this data requires many-to-one relationships (many people live in one particular region, many people work in one particular industry), which don’t fit nicely into the document model. In relational databases, it’s normal to refer to rows in other tables by ID, because joins are easy. In document databases, joins are not needed for one-to-many tree structures, and support for joins is often weak. ⁱⁱⁱ

不幸的是，将这些数据进行规范化需要多对一的关系（许多人居住在一个特定地区，许多人在一个特定行业工作），这些关系不适合文档模型。在关系数据库中，通常通过ID引用其他表中的行，因为连接很容易。在文档数据库中，连接不需要用于一对多树结构，并且对连接的支持通常较弱。

If the database itself does not support joins, you have to emulate a join in application code by making multiple queries to the database. (In this case, the lists of regions and industries are probably small and slow-changing enough that the application can simply keep them in memory. But nevertheless, the work of making the join is shifted from the database to the application code.)

如果数据库本身不支持连接，你需要在应用程序代码中通过对数据库进行多次查询来模拟连接。(在这种情况下，地区和行业列表可能很小且变化缓慢，应用程序可以将它们保留在内存中处理。但是，将连接的工作从数据库转移到应用程序代码。)

Moreover, even if the initial version of an application fits well in a join-free document model, data has a tendency of becoming more interconnected as features are added to applications. For example, consider some changes we could make to the résumé example:

此外，即使应用程序的初始版本适合无连接文档模型，随着功能的增加，数据往往会变得更加相互关联。例如，考虑以下我们可以对在线简历进行的更改：

Organizations and schools as entities

In the previous description, organization (the company where the user worked) and school_name (where they studied) are just strings. Perhaps they should be references to entities instead? Then each organization, school, or university could have its own web page (with logo, news feed, etc.); each résumé could link to the organizations and schools that it mentions, and include their logos and other information (see Figure 2-3 for an example from LinkedIn).

在先前的描述中，组织（用户所在的公司）和学校名称仅仅是字符串。也许它们应该是实体的引用？这样每个组织、学校或大学都可以有自己的网页（包含标志、新闻源等）。每份简历都可以链接到所提及的组织和学校，并包含它们的标志和其他信息（参见LinkedIn上的示例，如图2-3）。

Recommendations

Say you want to add a new feature: one user can write a recommendation for another user. The recommendation is shown on the résumé of the user who was recommended, together with the name and photo of the user making the recommendation. If the recommender updates their photo, any recommendations they have written need to reflect the new photo. Therefore, the recommendation should have a reference to the author’s profile.

假设你想添加一个新的功能：一位用户可以给另一位用户写一份推荐。这份推荐会显示在被推荐用户的个人简历上，同时还会附带推荐人的姓名和照片。如果推荐人更新了自己的照片，那么他所写的所有推荐都应该显示最新的照片。因此，推荐应该引用作者的个人资料。

Figure 2-3. The company name is not just a string, but a link to a company entity. Screenshot of linkedin.com.

Figure 2-4 illustrates how these new features require many-to-many relationships. The data within each dotted rectangle can be grouped into one document, but the references to organizations, schools, and other users need to be represented as references, and require joins when queried.

图2-4说明了这些新功能需要多对多的关系。每个虚线矩形中的数据可以分组成一个文档，但对组织、学校和其他用户的引用必须表示为引用，并在查询时需要连接。

Figure 2-4. Extending résumés with many-to-many relationships.

Are Document Databases Repeating History?

While many-to-many relationships and joins are routinely used in relational databases, document databases and NoSQL reopened the debate on how best to represent such relationships in a database. This debate is much older than NoSQL—in fact, it goes back to the very earliest computerized database systems.

尽管在关系型数据库中经常使用多对多关系和连接，但文档数据库和NoSQL重新打开了在数据库中表示这种关系的最佳方式的辩论。这个辩论比NoSQL要古老得多，实际上可以追溯到最早的计算机化数据库系统。

The most popular database for business data processing in the 1970s was IBM’s Information Management System (IMS), originally developed for stock-keeping in the Apollo space program and first commercially released in 1968 [ 13 ]. It is still in use and maintained today, running on OS/390 on IBM mainframes [ 14 ].

20世纪70年代，商业数据处理的最流行数据库是IBM的信息管理系统（IMS），最初为阿波罗航天计划的存货管理开发，于1968年首次商业发布[13]。它仍在使用和维护，运行在IBM主机的OS/390上[14]。

The design of IMS used a fairly simple data model called the hierarchical model , which has some remarkable similarities to the JSON model used by document databases [ 2 ]. It represented all data as a tree of records nested within records, much like the JSON structure of Figure 2-2 .

IMS的设计使用了一个相当简单的数据模型，称为分层模型，这与文档数据库使用的JSON模型有一些相似之处。它将所有数据表示为嵌套在记录中的记录树，就像图2-2中的JSON结构一样。

Like document databases, IMS worked well for one-to-many relationships, but it made many-to-many relationships difficult, and it didn’t support joins. Developers had to decide whether to duplicate (denormalize) data or to manually resolve references from one record to another. These problems of the 1960s and ’70s were very much like the problems that developers are running into with document databases today [ 15 ].

像文档数据库一样，IMS适用于一对多关系，但却使得多对多关系更加困难，并且不支持连接查询。开发者们不得不决定是复制（去规范化）数据还是手动解决从一个记录到另一个记录的引用。这些上世纪60年代和70年代的问题与今天开发者们在文档数据库中遇到的问题非常相似[15]。

Various solutions were proposed to solve the limitations of the hierarchical model. The two most prominent were the relational model (which became SQL, and took over the world) and the network model (which initially had a large following but eventually faded into obscurity). The “great debate” between these two camps lasted for much of the 1970s [ 2 ].

有许多解决分层模型限制的解决方案被提出。其中最著名的两个是关系模型（成为SQL并统治了世界）和网络模型（最初有很大的追随者，但最终逐渐被遗忘）。这两个阵营之间的“大辩论”持续了很长一段时间，一直到1970年代晚期。

Since the problem that the two models were solving is still so relevant today, it’s worth briefly revisiting this debate in today’s light.

由于两个模型所解决的问题仍然如此相关，因此在今天的光环下简要回顾这场争论是值得的。

Relational Versus Document Databases Today

There are many differences to consider when comparing relational databases to document databases, including their fault-tolerance properties (see Chapter 5 ) and handling of concurrency (see Chapter 7 ). In this chapter, we will concentrate only on the differences in the data model.

当比较关系型数据库和文档数据库时，需要考虑许多差异，包括它们的容错性质（见第五章）和并发处理（见第七章）。在本章中，我们将仅集中讨论数据模型的差异。

The main arguments in favor of the document data model are schema flexibility, better performance due to locality, and that for some applications it is closer to the data structures used by the application. The relational model counters by providing better support for joins, and many-to-one and many-to-many relationships.

文档数据模型的主要优点是模式灵活性、由于局部性能更好，某些应用程序更接近于数据结构。关系模型则通过提供更好的联接支持以及一对多和多对多关系来反驳这些优点。

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];
}

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

Declarative Queries on the Web

The advantages of declarative query languages are not limited to just databases. To illustrate the point, let’s compare declarative and imperative approaches in a completely different environment: a web browser.

声明式查询语言的优点不仅限于数据库。为了说明这一点，让我们比较声明式和命令式方法在一个完全不同的环境下：Web浏览器。

Say you have a website about animals in the ocean. The user is currently viewing the page on sharks, so you mark the navigation item “Sharks” as currently selected, like this:

假设你有一个关于海洋动物的网站。用户目前正在查看关于鲨鱼的页面，那么你可以将导航条目“鲨鱼”标记为当前选中状态，就像这样：

<ul>
    <li class="selected"> 
        <p>Sharks</p> 
        <ul>
            <li>Great White Shark</li>
            <li>Tiger Shark</li>
            <li>Hammerhead Shark</li>
        </ul>
    </li>
    <li>
        <p>Whales</p>
        <ul>
            <li>Blue Whale</li>
            <li>Humpback Whale</li>
            <li>Fin Whale</li>
        </ul>
    </li>
</ul>

The selected item is marked with the CSS class "selected" .

所选择的项目带有CSS类“selected”。

<p>Sharks</p> is the title of the currently selected page.

当前选定页面的标题是“鲨鱼”。

Now say you want the title of the currently selected page to have a blue background, so that it is visually highlighted. This is easy, using CSS:

现在假设您想要当前选定页面的标题具有蓝色背景，以便在视觉上突出显示。使用 CSS 很容易实现：

li.selected > p {
    background-color: blue;
}

Here the CSS selector li.selected > p declares the pattern of elements to which we want to apply the blue style: namely, all <p> elements whose direct parent is an <li> element with a CSS class of selected . The element <p>Sharks</p> in the example matches this pattern, but <p>Whales</p> does not match because its <li> parent lacks class="selected" .

此处 CSS 选择器 li.selected > p 声明我们要应用蓝色样式的元素模式：即所有直接父元素为 class="selected" 的 <li> 元素的 <p> 元素。在示例中，元素 <p>Sharks</p> 符合此模式，但 <p>Whales</p> 不符合，因为其 <li> 父元素缺少 class="selected"。

If you were using XSL instead of CSS, you could do something similar:

如果你使用XSL而不是CSS，你可以做类似的事情：

<xsl:template match="li[@class='selected']/p">
    <fo:block background-color="blue">
        <xsl:apply-templates/>
    </fo:block>
</xsl:template>

Here, the XPath expression li[@class='selected']/p is equivalent to the CSS selector li.selected > p in the previous example. What CSS and XSL have in common is that they are both declarative languages for specifying the styling of a document.

这里，XPath表达式li[@class='selected']/p相当于前面例子中的CSS选择器li.selected > p。CSS和XSL的共同点在于它们都是用于指定文档样式的声明性语言。

Imagine what life would be like if you had to use an imperative approach. In JavaScript, using the core Document Object Model (DOM) API, the result might look something like this:

想象一下，如果你必须使用命令式方法来生活会是什么样子。在 JavaScript 中，使用核心文档对象模型 (DOM) API，结果可能看起来像这样:

var liElements = document.getElementsByTagName("li");
for (var i = 0; i < liElements.length; i++) {
    if (liElements[i].className === "selected") {
        var children = liElements[i].childNodes;
        for (var j = 0; j < children.length; j++) {
            var child = children[j];
            if (child.nodeType === Node.ELEMENT_NODE && child.tagName === "P") {
                child.setAttribute("style", "background-color: blue");
            }
        }
    }
}

This JavaScript imperatively sets the element <p>Sharks</p> to have a blue background, but the code is awful. Not only is it much longer and harder to understand than the CSS and XSL equivalents, but it also has some serious problems:

这个JavaScript命令式地将元素<p>鲨鱼</p>的背景设为蓝色，但代码十分糟糕。它不仅比CSS和XSL等价物更长，更难理解，而且还有一些严重的问题：

• If the selected class is removed (e.g., because the user clicks a different page), the blue color won’t be removed, even if the code is rerun—and so the item will remain highlighted until the entire page is reloaded. With CSS, the browser automatically detects when the li.selected > p rule no longer applies and removes the blue background as soon as the selected class is removed.

  如果所选的类别被删除（例如，因为用户点击了不同的页面），即使重新运行代码，蓝色也不会删除，因此该项将保持突出显示，直到整个页面重新加载。使用CSS，浏览器会自动检测li.selected > p规则不再适用并在移除所选类别时立即删除蓝色背景。

• If you want to take advantage of a new API, such as document.getElementsByClassName("selected") or even document.evaluate() —which may improve performance—you have to rewrite the code. On the other hand, browser vendors can improve the performance of CSS and XPath without breaking compatibility.

  如果您想利用新API，例如document.getElementsByClassName（“selected”）或document.evaluate（），可能会提高性能，那么您必须重新编写代码。另一方面，浏览器厂商可以提高CSS和XPath的性能，而不会破坏兼容性。 如果想利用新的 API，比如document.getElementsByClassName("selected")，甚至是document.evaluate()——这些可能会提升性能——那么就必须重新编写代码。另一方面，浏览器厂商可以提升CSS和XPath的性能，而不毁于兼容性。

In a web browser, using declarative CSS styling is much better than manipulating styles imperatively in JavaScript. Similarly, in databases, declarative query languages like SQL turned out to be much better than imperative query APIs. ^vi

在Web浏览器中，使用声明性CSS样式比在JavaScript中使用命令式样式要好得多。同样，在数据库中，声明性查询语言例如SQL被证明比命令式查询API更好用。

MapReduce Querying

MapReduce is a programming model for processing large amounts of data in bulk across many machines, popularized by Google [ 33 ]. A limited form of MapReduce is supported by some NoSQL datastores, including MongoDB and CouchDB, as a mechanism for performing read-only queries across many documents.

MapReduce是一种编程模型，用于在许多计算机上批量处理大量数据，由Google流行化[33]。一些NoSQL数据存储支持MapReduce的有限形式，包括MongoDB和CouchDB，作为在许多文档上执行只读查询的机制。

MapReduce in general is described in more detail in Chapter 10 . For now, we’ll just briefly discuss MongoDB’s use of the model.

总体上说，MapReduce在第10章中有更详细的描述。现在，我们只是简要讨论MongoDB使用该模型的情况。

MapReduce is neither a declarative query language nor a fully imperative query API, but somewhere in between: the logic of the query is expressed with snippets of code, which are called repeatedly by the processing framework. It is based on the map (also known as collect ) and reduce (also known as fold or inject ) functions that exist in many functional programming languages.

MapReduce不是声明性查询语言也不是完全的命令式查询API，而是介于两者之间：查询逻辑用代码片段表达，这些代码片段在处理框架中被重复调用。它基于在许多功能编程语言中存在的map（也称为collect）和reduce（也称为fold或inject）函数。

To give an example, imagine you are a marine biologist, and you add an observation record to your database every time you see animals in the ocean. Now you want to generate a report saying how many sharks you have sighted per month.

举个例子，比如你是一位海洋生物学家，每当你在海洋中看到动物时，你都会添加一条观察记录到你的数据库中。现在你想生成一份报告，说明每个月你观察到了多少只鲨鱼。

In PostgreSQL you might express that query like this:

在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;

The date_trunc('month', timestamp) function determines the calendar month containing timestamp , and returns another timestamp representing the beginning of that month. In other words, it rounds a timestamp down to the nearest month.

"date_trunc('month', timestamp)"函数确定包含时间戳的日历月份，并返回表示该月份开头的另一个时间戳。换句话说，它将时间戳向下舍入到最近的月份。

This query first filters the observations to only show species in the Sharks family, then groups the observations by the calendar month in which they occurred, and finally adds up the number of animals seen in all observations in that month.

该查询首先按照“鲨鱼”物种筛选观察记录，然后按照所发生的日历月份对观测进行分组，最后计算该月份所有观测中看到的动物数量。

The same can be expressed with MongoDB’s MapReduce feature as follows:

可以使用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" 
    }
);

The filter to consider only shark species can be specified declaratively (this is a MongoDB-specific extension to MapReduce).

可以通过声明性的方式指定只考虑鲨鱼物种的过滤器（这是MongoDB特有的MapReduce扩展功能）。

The JavaScript function map is called once for every document that matches query , with this set to the document object.

JavaScript 函数map会针对每个与查询匹配的文档调用一次，将this设置为文档对象。

The map function emits a key (a string consisting of year and month, such as "2013-12" or "2014-1" ) and a value (the number of animals in that observation).

“map”函数发射一个键（由年份和月份组成的字符串，如“2013-12”或“2014-1”）和一个值（观察中动物的数量）。

The key-value pairs emitted by map are grouped by key. For all key-value pairs with the same key (i.e., the same month and year), the reduce function is called once.

map 发出的键值对根据键分组。对于所有具有相同键（即相同的月份和年份）的键值对，会调用一次 reduce 函数。

The reduce function adds up the number of animals from all observations in a particular month.

"reduce函数将特定月份内所有观察结果的动物数量相加。"

The final output is written to the collection monthlySharkReport .

最终输出将被写入集合monthlySharkReport。

For example, say the observations collection contains these two documents:

例如，假设观察集合包含以下两个文档：

{
    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
}

The map function would be called once for each document, resulting in emit("1995-12", 3) and emit("1995-12", 4) . Subsequently, the reduce function would be called with reduce("1995-12", [3, 4]) , returning 7 .

“map”函数将针对每个文档调用一次，导致“emit（“1995-12”，3）”和“emit（“1995-12”，4）” 。随后，reduce函数将使用reduce（“1995-12”，[3,4]）进行调用，返回7。

The map and reduce functions are somewhat restricted in what they are allowed to do. They must be pure functions, which means they only use the data that is passed to them as input, they cannot perform additional database queries, and they must not have any side effects. These restrictions allow the database to run the functions anywhere, in any order, and rerun them on failure. However, they are nevertheless powerful: they can parse strings, call library functions, perform calculations, and more.

映射和归约函数在其允许执行的操作上有一定的限制。它们必须是纯函数，这意味着它们只能使用作为输入传递给它们的数据，不能执行额外的数据库查询，也不能产生任何副作用。这些限制使得数据库可以在任何地方以任何顺序运行这些函数，并在失败时重新运行它们。然而，它们仍然非常强大：它们可以解析字符串、调用库函数、执行计算等等。

MapReduce is a fairly low-level programming model for distributed execution on a cluster of machines. Higher-level query languages like SQL can be implemented as a pipeline of MapReduce operations (see Chapter 10 ), but there are also many distributed implementations of SQL that don’t use MapReduce. Note there is nothing in SQL that constrains it to running on a single machine, and MapReduce doesn’t have a monopoly on distributed query execution.

MapReduce是一个基于集群机器分布式执行的相对较低级的编程模型。高级查询语言如SQL可以作为MapReduce操作的流水线来实现（见第10章），但也有许多分布式的SQL实现不使用MapReduce。需要注意的是，SQL并不局限于单机运行，而MapReduce也不是唯一的分布式查询执行方案。

Being able to use JavaScript code in the middle of a query is a great feature for advanced queries, but it’s not limited to MapReduce—some SQL databases can be extended with JavaScript functions too [ 34 ].

JavaScript代码在查询过程中的使用是高级查询的重要功能，但它并不局限于MapReduce—某些SQL数据库也可以使用JavaScript函数扩展。[34]。

A usability problem with MapReduce is that you have to write two carefully coordinated JavaScript functions, which is often harder than writing a single query. Moreover, a declarative query language offers more opportunities for a query optimizer to improve the performance of a query. For these reasons, MongoDB 2.2 added support for a declarative query language called the aggregation pipeline [ 9 ]. In this language, the same shark-counting query looks like this:

MapReduce存在的一个可用性问题是你需要编写两个精心协调的JavaScript函数，通常比编写单个查询更困难。此外，声明性查询语言提供了更多的机会让查询优化器提高查询性能。出于这些原因，MongoDB 2.2添加了支持称为聚合管道的声明性查询语言[9]。在这种语言中，同样的鲨鱼计数查询看起来像这样：

db.observations.aggregate([
    { $match: { family: "Sharks" } },
    { $group: {
        _id: {
            year:  { $year:  "$observationTimestamp" },
            month: { $month: "$observationTimestamp" }
        },
        totalAnimals: { $sum: "$numAnimals" }
    } }
]);

The aggregation pipeline language is similar in expressiveness to a subset of SQL, but it uses a JSON-based syntax rather than SQL’s English-sentence-style syntax; the difference is perhaps a matter of taste. The moral of the story is that a NoSQL system may find itself accidentally reinventing SQL, albeit in disguise.

聚合管道语言在表达能力上与 SQL 的子集类似，但它使用基于 JSON 的语法，而不是 SQL 的英语句子样式语法；这种差异可能只是口味问题。故事的道德是，NoSQL 系统可能会意外地重新发明 SQL，尽管是伪装的。

Property Graphs

In the property graph model, each vertex consists of:

在属性图模型中，每个顶点由以下内容组成：

• A unique identifier

  一个唯一标识符

• A set of outgoing edges

  出边集合

• A set of incoming edges

  一组入边

• A collection of properties (key-value pairs)

  一组属性（键值对）

Each edge consists of:

每个边缘由：

• A unique identifier

  一个唯一标识符

• The vertex at which the edge starts (the tail vertex )

  边起始的顶点（尾部顶点）

• The vertex at which the edge ends (the head vertex )

  边缘的终点顶点（头顶点）。

• A label to describe the kind of relationship between the two vertices

  两个各自描述不同的实体之间关系类型的标签。

• A collection of properties (key-value pairs)

  一组属性（键值对）

You can think of a graph store as consisting of two relational tables, one for vertices and one for edges, as shown in Example 2-2 (this schema uses the PostgreSQL json datatype to store the properties of each vertex or edge). The head and tail vertex are stored for each edge; if you want the set of incoming or outgoing edges for a vertex, you can query the edges table by head_vertex or tail_vertex , respectively.

你可以将图存储视为由两个关系表组成，一个存储顶点，另一个存储边，如示例2-2所示（此架构使用PostgreSQL json数据类型来存储每个顶点或边的属性）。每个边都存储头部和尾部顶点；如果您想要一个顶点的传入或传出边的集合，则可以分别通过head_vertex或tail_vertex查询edges表。

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);

Some important aspects of this model are:

这个模型的一些重要方面是：

1. Any vertex can have an edge connecting it with any other vertex. There is no schema that restricts which kinds of things can or cannot be associated.

   任何顶点都可以与任何其他顶点连接一条边。没有任何模式限制哪些物品可以或不能关联。

2. Given any vertex, you can efficiently find both its incoming and its outgoing edges, and thus traverse the graph—i.e., follow a path through a chain of vertices—both forward and backward. (That’s why Example 2-2 has indexes on both the tail_vertex and head_vertex columns.)

   给定任何一个顶点，你可以高效地找到它的入边和出边，从而可以在图中遍历，即沿着顶点链条向前和向后走。（这就是为什么示例2-2在tail_vertex和head_vertex列上都有索引的原因。）

3. By using different labels for different kinds of relationships, you can store several different kinds of information in a single graph, while still maintaining a clean data model.

   通过为不同类型的关系使用不同的标签，您可以在单个图中存储多种不同类型的信息，同时仍然保持清晰的数据模型。

Those features give graphs a great deal of flexibility for data modeling, as illustrated in Figure 2-5 . The figure shows a few things that would be difficult to express in a traditional relational schema, such as different kinds of regional structures in different countries (France has départements and régions , whereas the US has counties and states ), quirks of history such as a country within a country (ignoring for now the intricacies of sovereign states and nations), and varying granularity of data (Lucy’s current residence is specified as a city, whereas her place of birth is specified only at the level of a state).

这些特性赋予图形数据建模以极大的灵活性，如图2-5所示。该图显示了一些传统关系模式难以表达的东西，例如不同国家的不同地区结构（法国有départements和régions，而美国有郡和州），历史上的奇怪现象，如国家内的国家（暂时忽略主权国家和民族的复杂性），以及数据的变化粒度（Lucy的目前居住地指定为城市，而她的出生地仅在州一级指定）。

You could imagine extending the graph to also include many other facts about Lucy and Alain, or other people. For instance, you could use it to indicate any food allergies they have (by introducing a vertex for each allergen, and an edge between a person and an allergen to indicate an allergy), and link the allergens with a set of vertices that show which foods contain which substances. Then you could write a query to find out what is safe for each person to eat. Graphs are good for evolvability: as you add features to your application, a graph can easily be extended to accommodate changes in your application’s data structures.

你可以想象将该图扩展以包括有关Lucy和Alain或其他人的许多其他事实。例如，您可以使用它来指示他们有哪些食物过敏症（通过为每种过敏原引入一个顶点，并在人和过敏原之间添加一条边来表示过敏症），并使用一组显示哪些食物含有哪些物质的顶点将过敏原连接起来。然后，您可以编写查询以查找每个人可以安全食用的食物。 图表很适合扩展性：随着您向应用程序添加功能，图表可以轻松扩展以适应应用程序数据结构的变化。

The Cypher Query Language

Cypher is a declarative query language for property graphs, created for the Neo4j graph database [ 37 ]. (It is named after a character in the movie The Matrix and is not related to ciphers in cryptography [ 38 ].)

Cypher是一种面向属性图的声明式查询语言，为Neo4j图数据库创建[37]。 (它的名字来源于电影《黑客帝国》中的一个角色，并与密码学中的加密术语[38]无关。)

Example 2-3 shows the Cypher query to insert the lefthand portion of Figure 2-5 into a graph database. The rest of the graph can be added similarly and is omitted for readability. Each vertex is given a symbolic name like USA or Idaho , and other parts of the query can use those names to create edges between the vertices, using an arrow notation: (Idaho) -[:WITHIN]-> (USA) creates an edge labeled WITHIN , with Idaho as the tail node and USA as the head node.

示例2-3展示了将图2-5左侧部分插入图形数据库的Cypher查询。图中其他部分可以类似地添加，为了便于阅读而被省略。每个顶点都被赋予一个象征性的名称，例如美国或爱达荷，查询的其他部分可以使用这些名称来创建顶点之间的边，使用箭头符号：“（爱达荷）-[:WITHIN]->（美国）”创建了一个标记为WITHIN的边，其中爱达荷作为尾部节点，美国作为头节点。

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)

When all the vertices and edges of Figure 2-5 are added to the database, we can start asking interesting questions: for example, find the names of all the people who emigrated from the United States to Europe . To be more precise, here we want to find all the vertices that have a BORN_IN edge to a location within the US, and also a LIVING_IN edge to a location within Europe, and return the name property of each of those vertices.

当图2-5的所有顶点和边被添加到数据库后，我们可以开始提出有趣的问题：例如，查找所有从美国移民到欧洲的人的名字。 更准确地说，我们要找到所有顶点，它们具有一条指向美国境内位置的BORN_IN边和一条指向欧洲境内位置的LIVING_IN边，并返回每个该顶点的名称属性。

Example 2-4 shows how to express that query in Cypher. The same arrow notation is used in a MATCH clause to find patterns in the graph: (person) -[:BORN_IN]-> () matches any two vertices that are related by an edge labeled BORN_IN . The tail vertex of that edge is bound to the variable person , and the head vertex is left unnamed.

例2-4展示了如何用Cypher表达该查询。在MATCH子句中使用相同的箭头符号来查找图中的模式：（person）- [：BORN_IN] - >（）匹配通过标记为BORN_IN的边缘相关的任意两个顶点。该边的尾顶点绑定到变量person，而头顶点则未命名。

MATCH
  (person) -[:BORN_IN]->  () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
  (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name

The query can be read as follows:

该查询可以理解为:

Find any vertex (call it person ) that meets both of the following conditions:

寻找符合以下两个条件的任何顶点（称之为个人）：

1. person has an outgoing BORN_IN edge to some vertex. From that vertex, you can follow a chain of outgoing WITHIN edges until eventually you reach a vertex of type Location , whose name property is equal to "United States" .

   某人将BORN_IN出边传递到某个顶点。从该顶点出发，您可以沿着输出WITHIN边的链，直到最终到达类型为“Location”的顶点，其名称属性等于“美国”。

2. That same person vertex also has an outgoing LIVES_IN edge. Following that edge, and then a chain of outgoing WITHIN edges, you eventually reach a vertex of type Location , whose name property is equal to "Europe" .

   同样的顶点还具有一个向外的“居住于”边。沿着那条边，然后是一系列的向外的“位于”边，你最终会到达一个类型为位置的顶点，其名称属性等于“欧洲”。

For each such person vertex, return the name property.

对于每个这样的人顶点，返回名称属性。

There are several possible ways of executing the query. The description given here suggests that you start by scanning all the people in the database, examine each person’s birthplace and residence, and return only those people who meet the criteria.

有几种可能的执行查询的方式。这里给出的描述建议您首先扫描数据库中的所有人员，检查每个人的出生地和居住地，只返回符合条件的人员。

But equivalently, you could start with the two Location vertices and work backward. If there is an index on the name property, you can probably efficiently find the two vertices representing the US and Europe. Then you can proceed to find all locations (states, regions, cities, etc.) in the US and Europe respectively by following all incoming WITHIN edges. Finally, you can look for people who can be found through an incoming BORN_IN or LIVES_IN edge at one of the location vertices.

然而同等地，你也可以从两个位置顶点开始向后推导。如果名称属性上有索引，你可能可以有效地找到代表美国和欧洲的两个顶点。然后，你可以通过跟随所有传入的WITHIN边缘，分别找到美国和欧洲的所有位置（州，地区，城市等）。最后，你可以在位置顶点之一通过传入的BORN_IN或LIVES_IN边缘查找可以找到的人。

As is typical for a declarative query language, you don’t need to specify such execution details when writing the query: the query optimizer automatically chooses the strategy that is predicted to be the most efficient, so you can get on with writing the rest of your application.

作为声明式查询语言的典型特点，写查询时无需指定执行细节：查询优化器会自动选择预测为最有效的策略，因此您可以继续编写应用程序的其他部分。

Graph Queries in SQL

Example 2-2 suggested that graph data can be represented in a relational database. But if we put graph data in a relational structure, can we also query it using SQL?

示例2-2指出图形数据可以在关系型数据库中表示。但是如果将图形数据放入关系结构中，我们是否也可以使用SQL查询它？

The answer is yes, but with some difficulty. In a relational database, you usually know in advance which joins you need in your query. In a graph query, you may need to traverse a variable number of edges before you find the vertex you’re looking for—that is, the number of joins is not fixed in advance.

答案是肯定的，但需要一些困难。在关系数据库中，你通常已经知道了你查询需要哪些连接。而在图形查询中，你可能需要遍历不同数量的边缘，才能找到你想要的顶点——也就是说，连接的数量在事先是不固定的。

In our example, that happens in the () -[:WITHIN*0..]-> () rule in the Cypher query. A person’s LIVES_IN edge may point at any kind of location: a street, a city, a district, a region, a state, etc. A city may be WITHIN a region, a region WITHIN a state, a state WITHIN a country, etc. The LIVES_IN edge may point directly at the location vertex you’re looking for, or it may be several levels removed in the location hierarchy.

在我们的示例中，这发生在Cypher查询中的()-[:WITHIN*0..]->()规则中。一个人的“居住在”边缘可能指向任何类型的位置：一条街道，一个城市，一个区域，一个地区，一个州等等。一个城市可能在一个地区内，在一个地区内在一个州内，在一个州内在一个国家内等等。 “居住在”边缘可以直接指向您正在查找的位置顶点，也可以在位置层次结构中被移除数个级别。

In Cypher, :WITHIN*0.. expresses that fact very concisely: it means “follow a WITHIN edge, zero or more times.” It is like the * operator in a regular expression.

在密码中，:WITHIN*0..表达了这个事实非常简洁：它的意思是“遵循一个WITHIN边缘，零次或多次。” 就像正则表达式中的*操作符一样。

Since SQL:1999, this idea of variable-length traversal paths in a query can be expressed using something called recursive common table expressions (the WITH RECURSIVE syntax). Example 2-5 shows the same query—finding the names of people who emigrated from the US to Europe—expressed in SQL using this technique (supported in PostgreSQL, IBM DB2, Oracle, and SQL Server). However, the syntax is very clumsy in comparison to Cypher.

自从1999年的SQL版本开始，可以使用称为“带递归的公共表达式”（WITH RECURSIVE语法）的东西来表达查询中的可变长度遍历路径这个思想。例如，示例2-5展示了通过使用这种技术（在PostgreSQL、IBM DB2、Oracle和SQL Server中支持）表达的查询——找到移民从美国到欧洲的人的姓名。但是，与Cypher相比，语法非常笨拙。

WITH RECURSIVE

  -- in_usa is the set of vertex IDs of all locations within the United States
  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 is the set of vertex IDs of all locations within Europe
  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 is the set of vertex IDs of all people born in the US
  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 is the set of vertex IDs of all people living in Europe
  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 to find those people who were both born in the US *and* live in Europe
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;

If the same query can be written in 4 lines in one query language but requires 29 lines in another, that just shows that different data models are designed to satisfy different use cases. It’s important to pick a data model that is suitable for your application.

如果同样的查询在一种查询语言中可以写成4行，而在另一种语言中需要29行，那只说明不同的数据模型是为满足不同的用例而设计的。选择适合您应用的数据模型非常重要。

Triple-Stores and SPARQL

The triple-store model is mostly equivalent to the property graph model, using different words to describe the same ideas. It is nevertheless worth discussing, because there are various tools and languages for triple-stores that can be valuable additions to your toolbox for building applications.

三元组模型基本上等同于财产图模型，只是使用不同的词语来描述相同的思想。然而，这值得讨论，因为有各种工具和语言可以用于三元组存储，这些都可以成为构建应用程序工具箱中有价值的补充。

In a triple-store, all information is stored in the form of very simple three-part statements: ( subject , predicate , object ). For example, in the triple ( Jim , likes , bananas ), Jim is the subject, likes is the predicate (verb), and bananas is the object.

在三元组存储中，所有信息都以非常简单的三部分语句（主语，谓语，宾语）的形式存储。例如，在三元组（Jim，likes，bananas）中，Jim是主语，likes是谓语（动词），bananas是宾语。

The subject of a triple is equivalent to a vertex in a graph. The object is one of two things:

一个三元组的主语相当于图中的一个顶点。宾语则是两种情况之一：

1. A value in a primitive datatype, such as a string or a number. In that case, the predicate and object of the triple are equivalent to the key and value of a property on the subject vertex. For example, ( lucy , age , 33 ) is like a vertex lucy with properties {"age":33} .

   简化版： 一个原始数据类型的值，例如字符串或数字。在这种情况下，三元组的谓词和对象等同于主题顶点上属性的键和值。例如，（卢西，年龄，33）就像一个具有属性{"age":33}的顶点卢西。

2. Another vertex in the graph. In that case, the predicate is an edge in the graph, the subject is the tail vertex, and the object is the head vertex. For example, in ( lucy , marriedTo , alain ) the subject and object lucy and alain are both vertices, and the predicate marriedTo is the label of the edge that connects them.

   图形中的另一个顶点。在这种情况下，谓词是图形中的一条边，主语是尾顶点，宾语是头顶点。例如，在(lucy，marriedTo，alain)中，主语和宾语lucy和alain都是顶点，谓词marriedTo是连接它们的边的标签。

Example 2-6 shows the same data as in Example 2-3 , written as triples in a format called Turtle , a subset of Notation3 ( N3 ) [ 39 ].

示例2-6展示了与示例2-3相同的数据，以称为Turtle的格式编写的三元组的形式表示，它是Notation3（N3）的子集。[39]。

@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".

In this example, vertices of the graph are written as _: someName . The name doesn’t mean anything outside of this file; it exists only because we otherwise wouldn’t know which triples refer to the same vertex. When the predicate represents an edge, the object is a vertex, as in _:idaho :within _:usa . When the predicate is a property, the object is a string literal, as in _:usa :name "United States" .

在这个例子中，图形的顶点被写成_:someName。这个名字并没有任何意义，存在的唯一目的是因为我们不知道哪些三元组引用同一个顶点。当谓词表示边时，对象是顶点，例如_:idaho :within _:usa。当谓词是属性时，对象是一个字符串文字，例如_:usa :name "United States"。

It’s quite repetitive to repeat the same subject over and over again, but fortunately you can use semicolons to say multiple things about the same subject. This makes the Turtle format quite nice and readable: see Example 2-7 .

重复地反复讲同一个主题相当乏味，但幸运的是，你可以使用分号来表达关于同一个主题的多个事情。这使得Turtle格式非常好读：见示例2-7。

@prefix : <urn:example:>.
_:lucy     a :Person;   :name "Lucy";          :bornIn _:idaho.
_:idaho    a :Location; :name "Idaho";         :type "state";   :within _:usa.
_:usa      a :Location; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".

<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>

PREFIX : <urn:example:>

SELECT ?personName WHERE {
  ?person :name ?personName.
  ?person :bornIn  / :within* / :name "United States".
  ?person :livesIn / :within* / :name "Europe".
}

(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location)   # Cypher

?person :bornIn / :within* ?location.                   # SPARQL

(usa {name:'United States'})   # Cypher

?usa :name "United States".    # SPARQL

The Foundation: Datalog

Datalog is a much older language than SPARQL or Cypher, having been studied extensively by academics in the 1980s [ 44 , 45 , 46 ]. It is less well known among software engineers, but it is nevertheless important, because it provides the foundation that later query languages build upon.

Datalog比SPARQL或Cypher语言更为古老，已经在20世纪80年代被学者广泛研究过。虽然在软件工程师中不是很知名，但它仍然非常重要，因为后来的查询语言都建立在它的基础上。

In practice, Datalog is used in a few data systems: for example, it is the query language of Datomic [ 40 ], and Cascalog [ 47 ] is a Datalog implementation for querying large datasets in Hadoop. ^viii

在实践中，Datalog 在一些数据系统中使用：例如，它是 Datomic 的查询语言 [40]，Cascalog是一个用于在 Hadoop 中查询大数据集的 Datalog 实现 [47]。

Datalog’s data model is similar to the triple-store model, generalized a bit. Instead of writing a triple as ( subject , predicate , object ), we write it as predicate ( subject , object ). Example 2-10 shows how to write the data from our example in Datalog.

Datalog的数据模型类似于三元组存储模型，但稍微推广一下。我们将三元组的写法 (主语，谓语，宾语) 转换成谓语(主语，宾语)的形式。例如，示例 2-10 展示了如何在 Datalog 中写入我们示例中的数据。

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).

Now that we have defined the data, we can write the same query as before, as shown in Example 2-11 . It looks a bit different from the equivalent in Cypher or SPARQL, but don’t let that put you off. Datalog is a subset of Prolog, which you might have seen before if you’ve studied computer science.

现在我们已经定义了数据，我们可以像示例2-11那样编写与之前相同的查询。它看起来与Cypher或SPARQL中的等效语句有些不同，但不要让它吓到你。Datalog是Prolog的一个子集，如果你学过计算机科学，可能已经见过它了。

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 and SPARQL jump in right away with SELECT , but Datalog takes a small step at a time. We define rules that tell the database about new predicates: here, we define two new predicates, within_recursive and migrated . These predicates aren’t triples stored in the database, but instead they are derived from data or from other rules. Rules can refer to other rules, just like functions can call other functions or recursively call themselves. Like this, complex queries can be built up a small piece at a time.

Cypher和SPARQL会立即使用SELECT，但Datalog会逐步迈出小步。我们定义规则来告诉数据库新谓词的存在：在这里，我们定义了两个新谓词，within_recursive和migrated。这些谓词不是存储在数据库中的三元组，而是从数据或其他规则派生出来的。规则可以引用其他规则，就像函数可以调用其他函数或递归调用自己一样。通过这种方式，可以逐步构建复杂的查询。

In rules, words that start with an uppercase letter are variables, and predicates are matched like in Cypher and SPARQL. For example, name(Location, Name) matches the triple name(namerica, 'North America') with variable bindings Location = namerica and Name = 'North America' .

规则中，以大写字母开头的单词是变量，谓词的匹配方式类似于Cypher和SPARQL。例如，name(Location，Name)与三元组name(namerica，'North America')匹配，绑定变量为Location = namerica和Name ='North America'。

A rule applies if the system can find a match for all predicates on the righthand side of the :- operator. When the rule applies, it’s as though the lefthand side of the :- was added to the database (with variables replaced by the values they matched).

当系统可以在“：-”运算符的右侧找到所有谓词的匹配时，规则适用。当规则适用时，就好像“：-”的左侧已被添加到数据库中（变量被匹配的值替换）。

One possible way of applying the rules is thus:

一种可能的规则应用方式如下：

1. name(namerica, 'North America') exists in the database, so rule 1 applies. It generates within_recursive(namerica, 'North America') .

   名称(name) (namerica, '北美洲') 在数据库中已存在，因此规则1适用。它生成within_recursive(namerica, '北美洲')。

2. within(usa, namerica) exists in the database and the previous step generated within_recursive(namerica, 'North America') , so rule 2 applies. It generates within_recursive(usa, 'North America') .

   在数据库中存在 `within(usa, namerica)`，并且之前一步生成了 `within_recursive(namerica, 'North America')`，因此应用了规则 2。它生成了 `within_recursive(usa, 'North America')`。

3. within(idaho, usa) exists in the database and the previous step generated within_recursive(usa, 'North America') , so rule 2 applies. It generates within_recursive(idaho, 'North America') .

   在数据库中存在位于美国爱达荷州的数据，并且之前的步骤生成了within_recursive(美国, '北美洲')，因此规则2适用。它会生成within_recursive(爱达荷州, '北美洲')。

By repeated application of rules 1 and 2, the within_recursive predicate can tell us all the locations in North America (or any other location name) contained in our database. This process is illustrated in Figure 2-6 .

通过反复应用规则1和规则2，within_recursive谓词可以告诉我们所有在我们数据库中包含的北美（或任何其他位置名称）的位置。该过程在图2-6中说明。

Figure 2-6. Determining that Idaho is in North America, using the Datalog rules from Example 2-11 .

Now rule 3 can find people who were born in some location BornIn and live in some location LivingIn . By querying with BornIn = 'United States' and LivingIn = 'Europe' , and leaving the person as a variable Who , we ask the Datalog system to find out which values can appear for the variable Who . So, finally we get the same answer as in the earlier Cypher and SPARQL queries.

现在规则3可以查找出生在BornIn某地并住在LivingIn某地的人。通过查询BornIn = 'United States'和LivingIn = 'Europe'，并将人作为变量Who，我们要求Datalog系统查找哪些值可以出现在变量Who中。因此，最终我们得到与早期Cypher和SPARQL查询相同的答案。

The Datalog approach requires a different kind of thinking to the other query languages discussed in this chapter, but it’s a very powerful approach, because rules can be combined and reused in different queries. It’s less convenient for simple one-off queries, but it can cope better if your data is complex.

Datalog方法需要与本章中讨论的其他查询语言不同的思维方式，但它是一种非常强大的方法，因为规则可以在不同的查询中组合和重复使用。对于简单的一次性查询来说可能不太方便，但如果你的数据较为复杂，它处理起来更加从容。