Skip to content

chapter9_part1: /060_Distributed_Search/00_Intro.asciidoc #255

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 17, 2016
Merged

chapter9_part1: /060_Distributed_Search/00_Intro.asciidoc #255

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b1366a0
chapter9_part1: /060_Distributed_Search/00_Intro.asciidoc
Sep 8, 2016
76eee1a
Update 00_Intro.asciidoc
Sep 12, 2016
430d826
modified: 00_Intro.asciidoc
Oct 17, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions 060_Distributed_Search/00_Intro.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,3 +32,22 @@ 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_.

[[distributed-search]]
== 分布式检索执行
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

可以加个“策略“或者”方法“


在继续之前，我们将讨论一下在分布式环境中搜索是怎么运行的。 ((("distributed search execution"))) 这比基本的 _create-read-update-delete_ (CRUD) 请求，即 <<distributed-docs>> 章节中的 ((("CRUD (create-read-update-delete) operations"))) 要复杂一些。
Copy link

@luotitan luotitan Sep 13, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“将”->“先”
“运行”-> "执行"
create-read-update-delete 增删改查 ，感觉还是翻译下比较合理
后面这句建议翻译成这样：这比我们在《xx》中讨论的基础的增删改查请求要稍微复杂一点。
修改以后review下是否存在空格。


.内容提示
****

你有兴趣的话可以读一读这章，注意的是并不需要为了使用Elasticsearch而理解和记住所有的细节。
这章的阅读目的只为在脑海中形成服务运行的梗概以及了解信息的存放位置以便不时之需，但是不要被细节搞的云里雾里。
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

整体翻译的不错，但”搞得云里雾里“过于口语化，建议”但是不要过于陷入细节“


****

一条运行CRUD的操作处理一条单个的文档，这些文档中与 `_index` 、 `_type` 和 <<routing-value,`routing` values>> 有着特殊的连接，其中 <<routing-value,`routing` values>> 的默认值为文档中的 `_id` 值。这表示我们确切的知道集群中哪个分片含有此文档。
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

一条运行CRUD的操作处理一条单个的文档 -> 一个 CRUD 操作只对单个文档进行处理
后面这句翻译错了
文档的唯一性由 _index 、 _type 和<<routing-value,routing values>>（通常默认是该文档的 _id ）的组合来确定


搜索需要一种更加复杂的运行模型因为我们不知道查询会命中哪条文档，这些文档有可能在集群的任何分片上。一条查询请求务必询问我们在意的所有索引的所有分片来确保是否有任何命中的文档。
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

运行 ->执行
因为我们不知道查询会匹配哪些文档
逗号->冒号
后面这句建议翻译成：
一个搜索请求必须询问我们关注的索引（index or indices）的所有分片来确定它们是否含有任何匹配的文档。


但是发现所有的命中文档仅仅是开始。多分片中的结果必须在 `search` 接口返回一个 ``page'' 结果前和单个的筛选后的列表联系起来，为此，查询执行分为两步，先是 _query ，后是 fetch_ 。
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

但是发现所有的命中文档仅仅是开始 -> 但是发现所有的匹配文档仅仅是事情的一半。
combined 这个词的意思是组合而不是联系
在 search API 返回一页（ ``page''）结果前，来自多个分片的结果必须被组合放到一个有序列表中。
后面一句翻译成：”因此，搜索被分成两步执行，我们称之为 query then fetch。“
（query then fetch）是个专有名词