elasticsearch 학습노트(18)-Elasticsearch document 내부 원리 삭제, 일치성 메커니즘 쓰기

1. Elasticsearch 내부 원리 삭제

다음은 직접 눌러서 삭제 수정 요청이 Elasticsearch 내부에서 무엇을 했는지 설명합니다.그림(1) 클라이언트가 먼저 노드 node를 선택하여 요청을 보냅니다. 이 노드 node는 바로 조정 노드 coordinating node입니다. (2) 조정 노드 coordinating node는docuemnt 데이터에 대한 루트를 하고 요청을 대응하는 node(primary shard 포함)에 전달합니다. (3) 실제 node의primary shard는 요청을 처리합니다.그리고 데이터를 대응하는replicashard를 포함하는node(4) 조율 노드coordinatingnode에 동기화합니다. 만약primaryshard를 포함하는node와 모든replicashard를 포함하는node가 해결되면 응답 결과를 클라이언트에게 되돌려줍니다.
다음은 수동으로 그림을 그려서 위의 과정을 보여 줍니다. 만약에 우리가 두 개의 노드, 5개의primaryshardreplica=1이 있다고 가정하면
1. 클라이언트가 조정 노드 node22에 삭제 요청을 보내고 조정 노드 node2는 요청 루트를primaryshard를 포함하는node13,node1 처리 요청으로 보내고 대응하는replicashard를 포함하는node24, 조정 노드 node2에 동기화합니다. 만약primaryshard를 포함하는node1과 모든replicashard를 포함하는node2가 해결된 것을 발견하면 응답 클라이언트에게 되돌아옵니다.

2, 쓰기 정합성 보장 메커니즘(wait_for_active_shards로 대체된 제거됨)

consistency 기본적으로, 메인 필름은 법정 수량 또는 대부분의 섹션 복사본이 필요합니다. (그중 섹션 복사본은 메인 필름이나 섹션이 될 수 있습니다.) 쓰기 작업을 시도하기 전에 사용할 수 있습니다.네트워크 구역에 데이터를 쓰는'wrong side'를 방지하기 위해서입니다.법정 인원수는 다음과 같이 정의됩니다.
int((primary + number_of_replicas)/2) + 1에서 허용하는 값consistency는 one(주요 조각만), all(주요 및 모든 복사본) 또는 기본quorum 또는 대부분의 조각 복사본입니다.
주의, 그것number_of_replicas는 현재 활동의 복사본 수가 아니라 색인 설정에서 지정한 복사본 수입니다.인덱스에 세 개의 복사본이 있어야 한다고 지정한 경우 중재는 다음과 같습니다.
int ((primary + 3 replicas)/2) + 1 = 4 단, 두 노드만 시작하면 중재를 충족시킬 충분한 활동 분할 사본이 없고, 문서를 인덱스하거나 삭제할 수 없습니다.
timeout 사용 가능한 분할 사본이 부족하면 무슨 일이 일어날까요?Elasticsearch는 더 많은 영화가 나오기를 기다리고 있습니다.기본적으로 최대 1분까지 기다립니다.필요하면 타임아웃 파라미터를 사용하여 100밀리초, 30s는 30초로 더 빨리 중단할 수 있습니다.기본적으로 새 인덱스는 복사본이 있습니다. 이것은 필요한qorum을 충족시키기 위해 두 개의 이벤트 분할 복사본이 필요하다는 것을 의미합니다.그러나 이러한 기본 설정은 우리가 단일 노드 군집에 대해 어떤 유용한 조작도 하지 못하게 할 것이다.이 문제를 피하기 위해number_of_replicas가 1보다 크면 중재를 강제적으로 요구합니다.
consistency 매개 변수를 제거한 후wait_for_active_shards라는 매개 변수가 대체되었습니다.왜냐하면, consistency 검사는 Put 전에 한 것이다.그러나 검사를 할 때,shard는quorum을 만족시켰지만, 진정으로primaryshard에서replica로 쓰기 전에는shard가 끊어지지만,UpdateApi는succeed로 되돌아옵니다.따라서 이 검사는 리플리카의 성공적인 쓰기를 보장할 수 없으며, 심지어primaryshard의 성공적인 쓰기 여부도 보장할 수 없습니다.
시스템 쓰기의 탄력성을 높이기 위해wait_for_active_shards, 색인 작업을 계속하기 전에 일정 수량의 이벤트 분할 복사본을 기다리는 것으로 설정할 수 있습니다.필요한 활성 분할 사본을 사용할 수 없는 경우 필요한 분할 사본이 시작되거나 시간이 초과될 때까지 쓰기 작업을 기다리고 다시 시도해야 합니다.기본적으로 쓰기 작업은 주 조각이 계속 (즉wait_for_active_shards=1) 하기 전에만 활성화될 때까지 기다립니다.이 설정은 쓰기 작업에 필요한 조각 사본을 쓰지 않을 가능성을 크게 낮추지만, 쓰기 작업이 시작되기 전에 발생하기 때문에 이러한 가능성을 완전히 없애지는 않습니다.쓰기 작업이 진행 중인 경우 조각 분할 사본 수량에 대한 복사는 실패할 수 있지만 주 조각에서 성공할 수 있습니다.에서_shards 쓰기 작업의 응답 부분은 복사 성공/실패 조각의 몫을 보여 줍니다.

PUT /test_index/_doc/20?wait_for_active_shards=1
{
  "test_field":"test consistency"
}
{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "20",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 10,
  "_primary_term" : 2
}

"_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  }