1-04-6. Multidocument Patterns

The patterns for the mget and bulk APIs are similar to those for individual documents. The difference is that the coordinating node knows in which shard each document lives. It breaks up the multidocument request into a multidocument request per shard, and forwards these in parallel to each participating node.

mget 이나 bulk API의 형태는 개별 document의 그것과 유사하다. coordinating node는 document가 어느 shard에 있는지 알고 있다는 것이 차이점이다. multi-document request는 shard별 로 multi-document request로 나누어지고, 각각의 참여하고 있는 node에 병렬로 이 request를 전달한다.

Once it receives answers from each node, it collates their responses into a single response, which it returns to the client, as shown in Figure 12, “mget 을 이용하여 다수의 document를 가져온다”.

Figure 12, “mget 을 이용하여 다수의 document를 가져온다”에서 보듯이, 각 node에서 response를 받으면, 그 response들을 단일 response으로 모아서 클라이언트에게 반환한다.

Figure 12. mget 을 이용하여 다수의 document를 가져온다

Here is the sequence of steps necessary to retrieve multiple documents with a single mget request:

단일 mget request로 다수의 document를 가져올 때 필요한, 일련의 과정을 나열하였다.

1. The client sends an mget request to Node 1.

   클라이언트가 Node 1 에 mget request를 보낸다.

2. Node 1 builds a multi-get request per shard, and forwards these requests in parallel to the nodes hosting each required primary or replica shard. Once all replies have been received, Node 1 builds the response and returns it to the client.

   Node 1 은 shard 별로 multi-get request를 만들고, 요구되는 primary 또는 replica shard 각각을 가지고 있는 node에, 이들 request를 병렬로 전송한다. 모든 response를 받으면, Node 1 은 response를 만들어 클라이언트에게 반환한다.

A routing parameter can be set for each document in the docs array.

docs 배열에 있는 각 document에 routing 매개변수를 설정할 수 있다.

The bulk API, as depicted in Figure 13, “bulk 로 다수의 document를 변경한다”, allows the execution of multiple create, index, delete, and update requests within a single bulk request.

Figure 13, “bulk 로 다수의 document를 변경한다”에서 보듯이, bulk API는 단일 bulk request 내에서 다수의 create, index, delete, 그리고 update request를 실행한다.

Figure 13. bulk 로 다수의 document를 변경한다

The sequence of steps followed by the bulk API are as follows:

bulk API의 일련의 과정은 다음과 같다.

1. The client sends a bulk request to Node 1.

   클라이언트가 Node 1 에 bulk request를 보낸다.

2. Node 1 builds a bulk request per shard, and forwards these requests in parallel to the nodes hosting each involved primary shard.

   Node 1 은 shard 별로 bulk request를 만들고, 관련된 primary shard 각각을 가지고 있는 node에, 병렬로 이들 request를 전송한다.

3. The primary shard executes each action serially, one after another. As each action succeeds, the primary forwards the new document (or deletion) to its replica shards in parallel, and then moves on to the next action. Once all replica shards report success for all actions, the node reports success to the coordinating node, which collates the responses and returns them to the client.

   primary shard는 각각의 action을 연속으로 차례차례 실행한다. 각 action이 성공하면, primary는 새로운 document(또는 지워진 document)를 그것의 replica shard로 병렬로 전달한다. 그리고 나서 다음 action을 진행한다. 모든 replica shard가 모든 action에 대해 성공을 보고하면, 그 node는 coordinating node에게 성공을 보고하고, coordinating node는 response를 수집해서 클라이언트에게 반환한다.

The bulk API also accepts the consistency parameter at the top level for the whole bulk request, and the routing parameter in the metadata for each request.

bulk API 또한, 전체 bulk request의 top-level에서, consistency 매개변수를 사용할 수 있고, 각 request의 metadata에서 routing 매개변수를 사용할 수 있다.

Why the Funny Format?edit

When we learned about bulk requests earlier in Cheaper in Bulk, you may have asked yourself, "Why does the bulk API require the funny format with the newline characters, instead of just sending the requests wrapped in a JSON array, like the mget API?"

Cheaper in Bulk에서 초반에 bulk request에 대해 이야기할 때, "bulk API는 왜 newline 문자가 들어가는 이상한 format을 요구하는 걸까? 대신 mget API처럼, JSON 배열로 감싸서 request를 보내도 되는데" 라는 의문이 들었을지도 모르겠다.

To answer this, we need to explain a little background: Each document referenced in a bulk request may belong to a different primary shard, each of which may be allocated to any of the nodes in the cluster. This means that every action inside a bulk request needs to be forwarded to the correct shard on the correct node.

답을 하자면, 약간의 배경을 설명할 필요가 있다. bulk request에 언급된 각 document는 다른 primary shard에 속할 수도 있고, 각각의 shard는 cluster의 어떤 node에도 할당되어 있을 수 있다. 즉, bulkrequest 내의 모든 action 은 올바른 node의 올바른 shard로 전달되어야 한다.

If the individual requests were wrapped up in a JSON array, that would mean that we would need to do the following:

개별 request가 JSON 배열로 감싸져 있으면, 아래와 같은 것이 필요하다는 것을 의미한다.

• Parse the JSON into an array (including the document data, which can be very large)

  배열에 있는 JSON을 분석한다. (매우 클 수도 있는 document 데이터를 포함해서)

• Look at each request to determine which shard it should go to

  어느 shard로 갈 것인지를 결정하기 위해 각 request를 검토한다.

• Create an array of requests for each shard

  각 shard를 위한 request의 배열을 만든다.

• Serialize these arrays into the internal transport format

  내부 전송 format으로 이들 배열을 직렬화 한다.

• Send the requests to each shard

  각 shard로 request를 보낸다.

It would work, but would need a lot of RAM to hold copies of essentially the same data, and would create many more data structures that the Java Virtual Machine (JVM) would have to spend time garbage collecting.

작동은 하지만, 본질적으로 동일한 데이터의 복사본을 유지하기 위해, 많은 RAM이 필요할 것이고, 매우 많은 데이터 구조가 생성될 것이고, JVM은 garbage collection에 많은 시간을 소비해야 한다.

Instead, Elasticsearch reaches up into the networking buffer, where the raw request has been received, and reads the data directly. It uses the newline characters to identify and parse just the small action/metadata lines in order to decide which shard should handle each request.

대신, Elasticsearch는 네트워크 버퍼에 도달하면, raw request를 받아, 바로 읽는다. 각 request를 어느 shard에서 처리할 것인지를 결정하기 위해, 작은 action/metadata line을 구분하고 parsing하기 위해, newline 문자를 사용한다.

These raw requests are forwarded directly to the correct shard. There is no redundant copying of data, no wasted data structures. The entire request process is handled in the smallest amount of memory possible.

이런 raw request는 올바른 shard로 바로 전달된다. 불필요한 데이터의 복사도 없고, 데이터 구조의 낭비도 없다. 전체 request 프로세스는 가능한 한 최소의 메모리로 처리된다.