Merge pull request #320 from elasticsearch-cn/revert-255-chapter/chapter9_part1

Revert "chapter9_part1: /060_Distributed_Search/00_Intro.asciidoc"

Author: luotitan

060_Distributed_Search/00_Intro.asciidoc

@@ -32,22 +32,3 @@ 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]]
-== 分布式检索执行
-
-在继续之前，我们将讨论一下在分布式环境中搜索是怎么运行的。 ((("distributed search execution"))) 这比基本的 _create-read-update-delete_ (CRUD) 请求，即 <<distributed-docs>> 章节中的 ((("CRUD (create-read-update-delete) operations"))) 要复杂一些。
-
-.内容提示
-****
-
-你有兴趣的话可以读一读这章，注意的是并不需要为了使用Elasticsearch而理解和记住所有的细节。
-这章的阅读目的只为在脑海中形成服务运行的梗概以及了解信息的存放位置以便不时之需，但是不要被细节搞的云里雾里。
-
-****
-
-一条运行CRUD的操作处理一条单个的文档，这些文档中与 `_index` 、 `_type` 和 <<routing-value,`routing` values>> 有着特殊的连接，其中 <<routing-value,`routing` values>> 的默认值为文档中的 `_id` 值。这表示我们确切的知道集群中哪个分片含有此文档。
-
-搜索需要一种更加复杂的运行模型因为我们不知道查询会命中哪条文档，这些文档有可能在集群的任何分片上。一条查询请求务必询问我们在意的所有索引的所有分片来确保是否有任何命中的文档。
-
-但是发现所有的命中文档仅仅是开始。多分片中的结果必须在 `search` 接口返回一个 ``page'' 结果前和单个的筛选后的列表联系起来，为此，查询执行分为两步，先是 _query ，后是 fetch_ 。