##取回階段 查詢階段辨別出那些滿足搜索請求的document，但我們仍然需要取回那些document本身。這就是取回階段的工作，如圖分布式搜索的取回階段所示。  圖2 分布式搜索取回階段 分發階段由以下步驟構成： 1.協調節點辨別出哪個document需要取回，并且向相關分片發出`GET`請求。 2.每個分片加載document并且根據需要_豐富（enrich）_它們，然后再將document返回協調節點。 3.一旦所有的document都被取回，協調節點會將結果返回給客戶端。 協調節點先決定哪些document是_實際（actually）_需要取回的。例如，我們指定查詢```{ "from": 90, "size": 10 }```，那么前90條將會被丟棄，只有之后的10條會需要取回。這些document可能來自與原始查詢請求相關的某個、某些或者全部分片。 協調節點為每個持有相關document的分片建立多點get請求然后發送請求到處理查詢階段的分片副本。 分片加載document主體——`_source` field。如果需要，還會根據元數據豐富結果和高亮搜索片斷。一旦協調節點收到所有結果，會將它們匯集到單一的回答響應里，這個響應將會返回給客戶端。 ###深分頁 **** 查詢然后取回過程雖然支持通過使用`from`和`size`參數進行分頁，但是_要在有限范圍內（within limited）_。還記得每個分片必須構造一個長度為`from+size`的優先隊列吧，所有這些都要傳回協調節點。這意味著協調節點要通過對`分片數量 * (from + size)`個document進行排序來找到正確的`size`個document。 根據document的數量，分片的數量以及所使用的硬件，對10,000到50,000條結果（1,000到5,000頁）深分頁是可行的。但是對于足夠大的`from`值，排序過程將會變得非常繁重，會使用巨大量的CPU，內存和帶寬。因此，強烈不建議使用深分頁。 在實際中，“深分頁者”也是很少的一部人。一般人會在翻了兩三頁后就停止翻頁，并會更改搜索標準。那些不正常情況通常是機器人或者網絡爬蟲的行為。它們會持續不斷地一頁接著一頁地獲取頁面直到服務器到崩潰的邊緣。 如果你確實需要從集群里獲取大量documents，你可以通過設置搜索類型`scan`禁用排序，來高效地做這件事。這一點將在后面的章節討論。 **** <!-- === Fetch Phase The query phase identifies which documents satisfy((("distributed search execution", "fetch phase")))((("fetch phase of distributed search"))) the search request, but we still need to retrieve the documents themselves. This is the job of the fetch phase, shown in <<img-distrib-fetch>>. [[img-distrib-fetch]] .Fetch phase of distributed search image::images/elas_0902.png["Fetch Phase of distributed search"] The distributed phase consists of the following steps: 1. The coordinating node identifies which documents need to be fetched and issues a multi `GET` request to the relevant shards. 2. Each shard loads the documents and _enriches_ them, if required, and then returns the documents to the coordinating node. 3. Once all documents have been fetched, the coordinating node returns the results to the client. The coordinating node first decides which documents _actually_ need to be fetched. For instance, if our query specified `{ "from": 90, "size": 10 }`, the first 90 results would be discarded and only the next 10 results would need to be retrieved. These documents may come from one, some, or all of the shards involved in the original search request. The coordinating node builds a <<distrib-multi-doc,multi-get request>> for each shard that holds a pertinent document and sends the request to the same shard copy that handled the query phase. The shard loads the document bodies--the `_source` field--and, if requested, enriches the results with metadata and <<highlighting-intro,search snippet highlighting>>. Once the coordinating node receives all results, it assembles them into a single response that it returns to the client. .Deep Pagination **** The query-then-fetch process supports pagination with the `from` and `size` parameters, but _within limits_. ((("size parameter")))((("from parameter")))((("pagination", "supported by query-then-fetch process")))((("deep paging, problems with"))) Remember that each shard must build a priority queue of length `from + size`, all of which need to be passed back to the coordinating node. And the coordinating node needs to sort through `number_of_shards * (from + size)` documents in order to find the correct `size` documents. Depending on the size of your documents, the number of shards, and the hardware you are using, paging 10,000 to 50,000 results (1,000 to 5,000 pages) deep should be perfectly doable. But with big-enough `from` values, the sorting process can become very heavy indeed, using vast amounts of CPU, memory, and bandwidth. For this reason, we strongly advise against deep paging. In practice, ``deep pagers'' are seldom human anyway. A human will stop paging after two or three pages and will change the search criteria. The culprits are usually bots or web spiders that tirelessly keep fetching page after page until your servers crumble at the knees. If you _do_ need to fetch large numbers of docs from your cluster, you can do so efficiently by disabling sorting with the `scan` search type, which we discuss <<scan-scroll,later in this chapter>>. **** -->