1-04-5. Partial Updates to a Document

The update API , as shown in Figure 11, “document의 부분적 업데이트”, combines the read and write patterns explained previously.

Figure 11, “document의 부분적 업데이트”에서 보듯이, update API는 위에서 설명한 읽기와 쓰기 형태의 의 조합이다.

Figure 11. document의 부분적 업데이트

Here is the sequence of steps used to perform a partial update on a document:

document의 부분적인 업데이트를 수행하는데 사용되는 일련의 과정을 나열하였다.

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

   클라이언트가 업데이트 request를 Node 1 로 보낸다.

2. It forwards the request to Node 3, where the primary shard is allocated.

   request는 primary shard가 할당되어 있는 Node 3 으로 전송된다.

3. Node 3 retrieves the document from the primary shard, changes the JSON in the _sourcefield, and tries to reindex the document on the primary shard. If the document has already been changed by another process, it retries step 3 up to retry_on_conflict times, before giving up.

   Node 3 은 primary shard로부터 document를 가져와, _source field에 있는 JSON을 변경하고, primary shard의 document를 다시 색인하려 시도한다. 만약 document가 다른 프로세스에 의해 이미 변경되었다면, 그만두기 전에, retry_on_conflict 에 정의된 횟수만큼, 단계 3을 반복한다.

4. If Node 3 has managed to update the document successfully, it forwards the new version of the document in parallel to the replica shards on Node 1 and Node 2 to be reindexed. Once all replica shards report success, Node 3 reports success to the coordinating node, which reports success to the client.

   Node 3 이 document를 성공적으로 업데이트했다면, 재색인할 수 있도록 Node 1 과 Node 2 에 있는 replica shard로 병렬로 document의 새로운 버전을 전달한다. 모든 replica shard가 성공했다고 보고하면, Node 3 는 coordinating node(node 1)에게 성공했다고 보고하고, Node 1은 클라이언트에게 성공을 보고한다.

The update API also accepts the routing, consistency, and timeout parameters that are explained in Creating, Indexing, and Deleting a Document.

update API 또한 Creating, Indexing, and Deleting a Document에서 설명한, routing, consistency, 그리고 timeout 매개변수를 사용할 수 있다.

document 기반의 replication

When a primary shard forwards changes to its replica shards, it doesn’t forward the update request. Instead it forwards the new version of the full document. Remember that these changes are forwarded to the replica shards asynchronously, and there is no guarantee that they will arrive in the same order that they were sent. If Elasticsearch forwarded just the change, it is possible that changes would be applied in the wrong order, resulting in a corrupt document.

primary shard가 replica shard로 변경 사항을 전달할 때, update request를 전달하지 않는다. 대신 전체 document의 새로운 버전을 전달한다. 이 변경 사항은 replica shard에게 비동기적으로 전달된다는 점과, 전달된 순서와 동일하게 도착한다는 것을 보장할 수 없다는 점을 기억하자. Elasticsearch가 단지 변경 사항만을 전달한다면, 해당 변경 사항이 잘못된 순서로 적용되어, 잘못된 document가 될 수 있다.