Chapter/chapter04 part20

040_Distributed_CRUD/00_Intro.asciidoc

@@ -1,25 +1,21 @@
 [[distributed-docs]]
-== Distributed Document Store
+== 分布式文档存储
 
-In the preceding chapter, we looked at all the ways to put data into your index and
-then retrieve it.  But we glossed over many technical details surrounding how
-the data is distributed and fetched from the cluster.  This separation is done
-on purpose; you don't really need to know how data is distributed to work
-with Elasticsearch.  It just works.
+在前面的章节，我们介绍了如何索引和查询数据，不过我们忽略了很多底层的技术细节，
+例如文件是如何分布到集群的，又是如何从集群中获取的。
+Elasticsearch 本意就是隐藏这些底层细节，让我们好专注在业务开发中，所以其实你不必了解这么深入也无妨。
 
-In this chapter, we dive into those internal, technical details
-to help you understand how your data is stored in a distributed system.
+在这个章节中，我们将深入探索这些核心的技术细节，这能帮助你更好地理解数据如何被存储到这个分布式系统中。
 
-.Content Warning
+
+.注意
 ****
 
-The information presented in this chapter is for your interest. You are not required to
-understand and remember all the detail in order to use Elasticsearch. The
-options that are discussed are for advanced users only.
+这个章节包含了一些高级话题，上面也提到过，就算你不记住和理解所有的细节仍然能正常使用 Elasticsearch。
+如果你有兴趣的话，这个章节可以作为你的课外兴趣读物，扩展你的知识面。
 
-Read the section to gain a taste for how things work, and to know where the
-information is in case you need to refer to it in the future, but don't be
-overwhelmed by the details.
+如果你在阅读这个章节的时候感到很吃力，也不用担心。
+这个章节仅仅只是用来告诉你 Elasticsearch 是如何工作的，
+将来在工作中如果你需要用到这个章节提供的知识，可以再回过头来翻阅。
 
 ****
-

050_Search/00_Intro.asciidoc

@@ -1,60 +1,43 @@
 [[search]]
-== Searching--The Basic Tools
+== 搜索——最基本的工具
 
-So far, we have learned how to use Elasticsearch as a simple NoSQL-style
-distributed document store. We can ((("searching")))throw JSON documents at Elasticsearch and
-retrieve each one by ID. But the real power of Elasticsearch lies in its
-ability to make sense out of chaos -- to turn Big Data into Big Information.
+现在，我们已经学会了如何使用 Elasticsearch 作为一个简单的 NoSQL 风格的分布式文档存储系统。我们可以((("searching")))将一个 JSON 文档扔到 Elasticsearch 里，然后根据 ID 检索。但 Elasticsearch 真正强大之处在于可以从无规律的数据中找出有意义的信息——从“大数据”到“大信息”。
 
-This is the reason that we use structured JSON documents, rather than
-amorphous blobs of data.  Elasticsearch not only _stores_ the document, but
-also _indexes_ the content of the document in order to make it searchable.
+Elasticsearch 不只会_存储（stores）_ 文档，为了能被搜索到也会为文档添加_索引（indexes）_ ，这也是为什么我们使用结构化的 JSON 文档，而不是无结构的二进制数据。
 
-_Every field in a document is indexed and can be queried_. ((("indexing"))) And it's not just
-that. During a single query, Elasticsearch can use _all_ of these indices, to
-return results at breath-taking speed.  That's something that you could never
-consider doing with a traditional database.
+_文档中的每个字段都将被索引并且可以被查询_ 。((("indexing")))不仅如此，在简单查询时，Elasticsearch 可以使用 _所有（all）_ 这些索引字段，以惊人的速度返回结果。这是你永远不会考虑用传统数据库去做的一些事情。
 
-A _search_ can be any of the following:
+_搜索（search）_ 可以做到：
 
-* A structured query on concrete fields((("fields", "searching on")))((("searching", "types of searches"))) like `gender` or `age`, sorted by
-  a field like `join_date`, similar to the type of query that you could construct 
-  in SQL
+* 在类似于 `gender` 或者 `age` 这样的字段((("fields", "searching on")))((("searching", "types of searches")))上使用结构化查询，`join_date` 这样的字段上使用排序，就像SQL的结构化查询一样。
 
-* A full-text query, which finds all documents matching the search keywords,
-  and returns them sorted by _relevance_
+* 全文检索，找出所有匹配关键字的文档并按照_相关性（relevance）_ 排序后返回结果。
 
-* A combination of the two
+* 以上二者兼而有之。
 
-While many searches will just work out of((("full text search"))) the box, to use Elasticsearch to
-its full potential, you need to understand three subjects:
+很多搜索都是开箱即用的((("full text search")))，为了充分挖掘 Elasticsearch 的潜力，你需要理解以下三个概念：
 
- _Mapping_::     
-   How the data in each field is interpreted
-
- _Analysis_::    
-   How full text is processed to make it searchable
-
- _Query DSL_::   
-   The flexible, powerful query language used by Elasticsearch
+ _映射（Mapping）_ ::
+   描述数据在每个字段内如何存储
 
-Each of these is a big subject in its own right, and we explain them in
-detail in <<search-in-depth>>. The chapters in this section introduce the
-basic concepts of all three--just enough to help you to get an overall
-understanding of how search works.
+ _分析（Analysis）_ ::
+   全文是如何处理使之可以被搜索的
 
-We will start by explaining the `search` API in its simplest form.
+ _领域特定查询语言（Query DSL）_ ::
+   Elasticsearch 中强大灵活的查询语言
 
-.Test Data
+以上提到的每个点都是一个大话题，我们将在 <<search-in-depth>> 一章详细阐述它们。本章节我们将介绍这三点的一些基本概念——仅仅帮助你大致了解搜索是如何工作的。
+
+我们将使用最简单的形式开始介绍 `search` API。
+
+.测试数据
 
 ****
 
-The documents that we will use for test purposes in this chapter can be found
-in this gist: https://gist.github.com/clintongormley/8579281.
+本章节的测试数据可以在这里找到： https://gist.github.com/clintongormley/8579281 。
 
-You can copy the commands and paste them into your shell in order to follow
-along with this chapter.
+你可以把这些命令复制到终端中执行来实践本章的例子。
 
-Alternatively, if you're in the online version of this book, you can link:sense_widget.html?snippets/050_Search/Test_data.json[click here to open in Sense].
+另外，如果你读的是在线版本，可以 link:sense_widget.html?snippets/050_Search/Test_data.json[点击这个链接] 感受下。
 
 ****

060_Distributed_Search/00_Intro.asciidoc

@@ -1,34 +1,29 @@
 [[distributed-search]]
-== Distributed Search Execution
+== 执行分布式检索
 
-Before moving on, we are going to take a detour and talk about how search is
-executed in a distributed environment.((("distributed search execution")))  It is a bit more complicated than the
-basic _create-read-update-delete_ (CRUD) requests((("CRUD (create-read-update-delete) operations"))) that we discussed in
-<<distributed-docs>>.
+在继续之前，我们将绕道讨论一下在分布式环境中搜索是怎么执行的。
+((("distributed search execution"))) 这比我们在 <<distributed-docs>> 章节讨论的基本的 _增-删-改-查_ (CRUD)((("CRUD (create-read-update-delete) operations")))请求要复杂一些。
 
-.Content Warning
+
+.内容提示
 ****
 
-The information presented in this chapter is for your interest. You are not required to
-understand and remember all the detail in order to use Elasticsearch.
+你可以根据兴趣阅读本章内容。你并不需要为了使用 Elasticsearch 而理解和记住所有的细节。
 
-Read this chapter to gain a taste for how things work, and to know where the
-information is in case you need to refer to it in the future, but don't be
-overwhelmed by the detail.
+这章的阅读目的只为初步了解下工作原理，以便将来需要时可以及时找到这些知识，
+但是不要被细节所困扰。
 
 ****
 
-A CRUD operation deals with a single document that has a unique combination of
-`_index`, `_type`, and <<routing-value,`routing` values>> (which defaults to the
-document's `_id`). This means that we know exactly which shard in the cluster
-holds that document.
+一个 CRUD 操作只对单个文档进行处理，文档的唯一性由 `_index`, `_type`,
+和 <<routing-value,`routing` values>> （通常默认是该文档的 `_id` ）的组合来确定。
+这表示我们确切的知道集群中哪个分片含有此文档。
+
+
+搜索需要一种更加复杂的执行模型因为我们不知道查询会命中哪些文档: 这些文档有可能在集群的任何分片上。
+一个搜索请求必须询问我们关注的索引（index or indices）的所有分片的某个副本来确定它们是否含有任何匹配的文档。
 
-Search requires a more complicated execution model because we don't know which
-documents will match the query: they could be on any shard in the cluster. A
-search request has to consult a copy of every shard in the index or indices
-we're interested in to see if they have any matching documents.
 
-But finding all matching documents is only half the story. Results from
-multiple shards must be combined into a single sorted list before the `search`
-API can return a ``page'' of results. For this reason, search is executed in a
-two-phase process called _query then fetch_.
+但是找到所有的匹配文档仅仅完成事情的一半。
+在 `search` 接口返回一个 ``page`` 结果之前，多分片中的结果必须组合成单个排序列表。
+为此，搜索被执行成一个两阶段过程，我们称之为 _query then fetch_ 。

070_Index_Mgmt/10_Settings.asciidoc

@@ -1,28 +1,22 @@
-=== Index Settings
+[[index-settings]]
+=== 索引设置
 
-There are many many knobs((("index settings"))) that you can twiddle to
-customize index behavior, which you can read about in the
-{ref}/index-modules.html[Index Modules reference documentation],
-but...
+你可以通过修改配置来((("index settings")))自定义索引行为，详细配置参照
+{ref}/index-modules.html[索引模块]
 
-TIP: Elasticsearch comes with good defaults. Don't twiddle these knobs until
-you understand what they do and why you should change them.
+TIP: Elasticsearch 提供了优化好的默认配置。 除非你理解这些配置的作用并且知道为什么要去修改，否则不要随意修改。
 
-Two of the most important((("shards", "number_of_shards index setting")))((("number_of_shards setting")))((("index settings", "number_of_shards"))) settings are as follows:
+下面是两个((("shards", "number_of_shards index setting")))((("number_of_shards setting")))((("index settings", "number_of_shards"))) 最重要的设置：
 
 `number_of_shards`::
 
-    The number of primary shards that an index should have,
-    which defaults to `5`.  This setting cannot be changed
-    after index creation.
+    每个索引的主分片数，默认值是 `5` 。这个配置在索引创建后不能修改。
 
 `number_of_replicas`::
 
-    The number of replica shards (copies) that each primary shard
-    should have, which defaults to `1`.  This setting can be changed
-    at any time on a live index.
+    每个主分片的副本数，默认值是 `1` 。对于活动的索引库，这个配置可以随时修改。
 
-For instance, we could create a small index--just((("index settings", "number_of_replicas")))((("replica shards", "number_of_replicas index setting"))) one primary shard--and no replica shards with the following request:
+例如，我们可以创建只有((("index settings", "number_of_replicas")))((("replica shards", "number_of_replicas index setting"))) 一个主分片，没有副本的小索引：
 
 [source,js]
 --------------------------------------------------
@@ -36,8 +30,8 @@ PUT /my_temp_index
 --------------------------------------------------
 // SENSE: 070_Index_Mgmt/10_Settings.json
 
-Later, we can change the number of replica shards dynamically using the
-`update-index-settings` API as((("update-index-settings API"))) follows:
+然后，我们可以用
+`update-index-settings` API ((("update-index-settings API"))) 动态修改副本数：
 
 [source,js]
 --------------------------------------------------
@@ -47,5 +41,3 @@ PUT /my_temp_index/_settings
 }
 --------------------------------------------------
 // SENSE: 070_Index_Mgmt/10_Settings.json
-
-

070_Index_Mgmt/32_Metadata_all.asciidoc

@@ -1,15 +1,9 @@
 [[all-field]]
-==== Metadata: _all Field
+==== 元数据: _all 字段
 
-In <<search-lite>>, we introduced the `_all` field: a special field that
-indexes the ((("metadata, document", "_all field")))((("_all field", sortas="all field")))values from all other fields as one big string. The `query_string`
-query clause (and searches performed as `?q=john`) defaults to searching in
-the `_all` field if no other field is specified.
+在 <<search-lite>> 中，我们介绍了 `_all` 字段：一个把其它字段值((("metadata, document", "_all field")))((("_all field", sortas="all field")))当作一个大字符串来索引的特殊字段。 `query_string` 查询子句(搜索 `?q=john` )在没有指定字段时默认使用 `_all` 字段。
 
-The `_all` field is useful during the exploratory phase of a new application,
-while you are still unsure about the final structure that your documents will
-have. You can throw any query string at it and you have a good chance of
-finding the document you're after:
+`_all` 字段在新应用的探索阶段，当你还不清楚文档的最终结构时是比较有用的。你可以使用这个字段来做任何查询，并且有很大可能找到需要的文档：
 
 [source,js]
 --------------------------------------------------
@@ -22,24 +16,14 @@ GET /_search
 --------------------------------------------------
 
 
-As your application evolves and your search requirements become more exacting,
-you will find yourself using the `_all` field less and less. The `_all` field
-is a shotgun approach to search. By querying individual fields, you have more
-flexbility, power, and fine-grained control over which results are considered
-to be most relevant.
+随着应用的发展，搜索需求变得更加明确，你会发现自己越来越少使用 `_all` 字段。 `_all` 字段是搜索的应急之策。通过查询指定字段，你的查询更加灵活、强大，你也可以对相关性最高的搜索结果进行更细粒度的控制。
 
 [NOTE]
 ====
-One of the important factors taken into account by the
-<<relevance-intro,relevance algorithm>>
-is the length of the field: the shorter the field, the more important. A term
-that appears in a short `title` field is likely to be more important than the
-same term that appears somewhere in a long `content` field. This distinction
-between field lengths disappears in the `_all` field.
+<<relevance-intro,relevance algorithm>> 考虑的一个最重要的原则是字段的长度：字段越短越重要。 在较短的 `title` 字段中出现的短语可能比在较长的 `content` 字段中出现的短语更加重要。字段长度的区别在 `_all` 字段中不会出现。
 ====
 
-If you decide that you no longer need the `_all` field, you can disable it
-with this mapping:
+如果你不再需要 `_all` 字段，你可以通过下面的映射来禁用：
 
 [source,js]
 --------------------------------------------------
@@ -51,17 +35,9 @@ PUT /my_index/_mapping/my_type
 }
 --------------------------------------------------
 
+通过 `include_in_all` 设置来逐个控制字段是否要包含在 `_all` 字段中，((("include_in_all setting")))默认值是 `true`。在一个对象(或根对象)上设置 `include_in_all` 可以修改这个对象中的所有字段的默认行为。
 
-Inclusion in the `_all` field can be controlled on a field-by-field basis
-by using the `include_in_all` setting, ((("include_in_all setting")))which defaults to `true`.  Setting
-`include_in_all` on an object (or on the root object) changes the
-default for all fields within that object.
-
-You may find that you want to keep the `_all` field around to use
-as a catchall full-text field just for specific fields, such as
-`title`, `overview`, `summary`, and `tags`. Instead of disabling the `_all`
-field completely, disable `include_in_all` for all fields by default,
-and enable it only on the fields you choose:
+你可能想要保留 `_all` 字段作为一个只包含某些特定字段的全文字段，例如只包含 `title`，`overview`，`summary` 和 `tags`。 相对于完全禁用 `_all` 字段，你可以为所有字段默认禁用 `include_in_all` 选项，仅在你选择的字段上启用：
 
 [source,js]
 --------------------------------------------------
@@ -81,11 +57,7 @@ PUT /my_index/my_type/_mapping
 --------------------------------------------------
 
 
-Remember that the `_all` field is just((("analyzers", "configuring for all field"))) an analyzed `string` field.  It
-uses the default analyzer to analyze its values, regardless of which
-analyzer has been set on the fields where the values originate.  And
-like any `string` field, you can configure which analyzer the `_all`
-field should use:
+记住，`_all` 字段仅仅是一个((("analyzers", "configuring for all field"))) 经过分词的 `string` 字段。它使用默认分词器来分析它的值，不管这个值原本所在字段指定的分词器。就像所有 `string` 字段，你可以配置 `_all` 字段使用的分词器：
 
 [source,js]
 --------------------------------------------------

070_Index_Mgmt/33_Metadata_ID.asciidoc

@@ -1,25 +1,22 @@
-==== Metadata: Document Identity
+==== 元数据：文档标识
 
-There are four metadata fields ((("metadata, document", "identity")))associated with document identity:
+文档标识与四个元数据字段((("metadata, document", "identity")))相关：
 
 `_id`::
-   The string ID of the document
+   文档的 ID 字符串
 
 `_type`::
-   The type name of the document
+   文档的类型名
 
 `_index`::
-   The index where the document lives
+   文档所在的索引
 
 `_uid`::
-   The `_type` and `_id` concatenated together as `type#id`
+   `_type` 和 `_id` 连接在一起构造成 `type#id`
 
-By default, the `_uid` field is((("id field"))) stored (can be retrieved) and
-indexed (searchable).  The `_type` field((("type field")))((("index field")))((("uid field"))) is indexed but not stored,
-and the `_id` and `_index` fields are neither indexed nor stored, meaning
-they don't really exist.
+默认情况下， `_uid` 字段是被((("id field")))存储（可取回）和索引（可搜索）的。
+`_type` 字段((("type field")))((("index field")))((("uid field")))被索引但是没有存储，
+`_id` 和 `_index` 字段则既没有被索引也没有被存储，这意味着它们并不是真实存在的。
 
-In spite of this, you can query the `_id` field as though it were a real
-field.  Elasticsearch uses the `_uid` field to derive the `_id`. Although you
-can change the `index` and `store` settings for these fields, you almost
-never need to do so.
+尽管如此，你仍然可以像真实字段一样查询 `_id` 字段。Elasticsearch 使用 `_uid` 字段来派生出 `_id` 。
+虽然你可以修改这些字段的 `index` 和 `store` 设置，但是基本上不需要这么做。