1-09-2. Fetch Phase

The query phase identifies which documents satisfy the search request, but we still need to retrieve the documents themselves. This is the job of the fetch phase, shown in Figure 15, “분산 검색의 fetch 절”.

query 절은 어떤 document가 검색 request를 만족하는지를 확인할 뿐이다. 이제 document 자체를 가져와야 한다. 이것이, Figure 15, “분산 검색의 fetch 절”에서 보이는 fetch 절의 역할이다.

Figure 15. 분산 검색의 fetch 절

The distributed phase consists of the following steps:

fetch 절은 다음과 같은 단계로 구성된다.

1. The coordinating node identifies which documents need to be fetched and issues a multi GETrequest to the relevant shards.

   조정(coordinating) node는 가져올(be fetched) document를 확인하고, 관련 shard에 다중 GETrequest를 요청한다.

2. Each shard loads the documents and enriches them, if required, and then returns the documents to the coordinating node.

   각 shard는 document와 request한 metadata등을 가져와, 조정 node로 반환한다.

3. Once all documents have been fetched, the coordinating node returns the results to the client.

   모든 document를 가져오면, 조정(coordinating) node는 결과를 클라이언트로 반환한다.

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.

먼저, 조정 node는 실제로 가져와야 할 document가 어떤 것인지를, 결정한다. 예를 들어, query가 { "from": 90, "size": 10 } 이라면, 처음 90개는 버리고, 그 다음 10개만 가져와야 한다. 이들 document는 원래의 검색 request에 포함되는, 하나 이상 또는 모든 shard로부터 가져올 수 있다.

The coordinating node builds a 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.

조정 node는 관련된 document를 가지고 있는 각 shard에 대해, multi-get request를 생성하고, query 절이 처리된, 동일한 shard의 복사본으로 request를 전송한다.

The shard loads the document bodies—the _source field—and, if requested, enriches the results with metadata and search snippet highlighting. Once the coordinating node receives all results, it assembles them into a single response that it returns to the client.

shard는 document의 body(_source field), 필요하다면, metadata와 highlight 정보 등을 로드한다. 조정 node가 모든 결과를 받으면, 그것들을 하나의 response으로 조합하고, 클라이언트로 반환한다.

Deep Pagination

The query-then-fetch process supports pagination with the from and size parameters, but within limits. 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.

query-then-fetch 프로세스는 한도 내에서, from 과 size 매개변수를 통한, page 계산을 지원한다. 각 shard가 조정 node로 반환해야 하는, from + size 의 크기로, 우선순위 queue를 생성해야 한다는 점을 기억하자. 그리고, 조정 node는 올바른 size 의 document를 찾기 위해,number_of_shards * ( from + size ) 의 document를 처리해, 정렬해야 한다.

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.

document의 크기, shard의 수, 사용하고 있는 H/W에 따라, 10,000 ~ 50,000개(1,000 ~ 5,000 페이지) 정도의 페이지 계산은 완벽하게 처리할 수 있다. 그러나, 너무 큰 from 값은, 정렬 프로세스가 막대한 양의 CPU, 메모리, bandwidth를 사용하여, 사실 매우 무거워진다. 이런 이유로, 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.

실제로, "deep pagers"는 사람들이 거의 사용하지 않는다. 사용자들은 2~3 페이지를 본 후에는, 페이징을 멈추고, 검색 기준을 변경한다. 서버가 down될때까지, 쉬지 않고 page를 가져오는 범인은 일반적으로, bot 이나 web spider 이다.

If you do need to fetch large numbers of docs from your cluster, you can do so efficiently by disabling sorting with the scroll query, which we discuss later in this chapter.

만약 cluster에서 많은 document를 가져와야 한다면, 이 장의 후반부에서 이야기할, scrollquery로, 정렬을 비활성화하여, 효율적으로 할 수 있다.