Update/Delete By Query API

Intro::

_update_by_query 와 _delete_by_query 에 대해서 알아봅시다. 엘라스틱서치 실무 가이드의 영화 인덱스를 사용하였습니다.

_update_by_query

batch

slice

결론적으로 슬라이스 별로 batch 만큼의 문서를 처리하며, 모든 문서를 처리할 때 까지 과정을 반복한다고 이해하면 된다.

// 내용 변경
POST movie_search/_update_by_query?conflicts=proceed&slices=5&scroll_size=5000
{
  "script": {
    "source": "ctx._source.test = params.test",
    "params": {
      "test": "변경되었습니다"
    }, 
    "lang": "painless"
  }, 
  "query": {
    "range": {
      "prdtYear": {
        "gt": 10
      }
    }
  }
}

// 필드 삭제
POST movie_search/_update_by_query?conflicts=proceed&slices=auto&scroll_size=5000
{
  "script": {
    "source": "ctx._source.remove(params.test)",
    "params": {
      "test": "test"
    }, 
    "lang": "painless"
  }, 
  "query": {
    "range": {
      "prdtYear": {
        "gt": 10
      }
    }
  }
}

• conflicts=proceed
• 버전 충돌이 일어나도 저장

• slices=5
• 5개의 슬라이스로 병렬작업

• scroll_size=5000
• 5000개의 문서를 한번에 처리

_delete_by_query

해당 API는 지정한 쿼리에 일치하는 모든 문서를 삭제합니다. _update_by_query 와 유사한 구조를 가지고 있습니다.

궁금한점

1. 한 샤드가 기본적으로 10000개의 문서를 가지고 있는데, 실제로 검색을 했을때 10000개 보다 개수가 많다면 어떻게 문서들을 가져오는지?
1. search_after를 사용해서 다음 문서들을 가져온다.
2. 일반적으로 페이징을 사용하기 때문에 한번에 10000건 이상 검색할 일이 없기도 하다고 한다.

2. 10000개 이상의 문서를 검색하게 될때, 검색을 할 때마다 검색 조건에 부합하는 문서들이 정렬되는 건지???
1. 그렇다.
2. 이를 해결하기 위해 pit을 생성하여 사용하도록 권고한다고 한다.
1. multi index 검색 시에는 사용할 수 없다고 한다.
2. pit 자체가 코스트를 가지고 있기 때문에 사용되지 않는 시점이라면 바로 삭제해주는 것이 좋다.

References::

Update By Query API | Elasticsearch Guide [7.17] | Elastic

Updates documents that match the specified query. If no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.

https://www.elastic.co/guide/en/elasticsearch/reference/7.17/docs-update-by-query.html

Point in time API | Elasticsearch Guide [8.13] | Elastic

A search request by default executes against the most recent visible data of the target indices, which is called point in time. Elasticsearch pit (point in time) is a lightweight view into the state of the data as it existed when initiated. In some cases, it’s preferred to perform multiple search requests using the same point in time. For example, if refreshes happen between search_after requests, then the results of those requests might not be consistent as changes happening between searches are only visible to the more recent point in time.

https://www.elastic.co/guide/en/elasticsearch/reference/current/point-in-time-api.html