Elasticsearch 7.10의 Paginate 검색 결과

기본적으로 검색은 상위 10개의 일치하는 항목을 되돌려줍니다.더 큰 결과를 찾으려면 검색 API의from과size 매개 변수를 사용할 수 있습니다.from 매개 변수는 건너뛸 일치 수를 정의합니다. 기본값은 0입니다.size 매개 변수는 되돌릴 최대 일치수입니다.이 두 파라미터는 결과 페이지를 공동으로 정의했다.

GET /_search
{
  "from": 5,
  "size": 20,
  "query": {
    "match": {
      "user.id": "kimchy"
    }
  }
}

from과size를 과도하게 사용해서 페이지를 나누거나 한 번에 너무 많은 결과를 요청하는 것을 피하십시오.검색 요청은 보통 여러 개의 섹션을 뛰어넘습니다.각 조각은 요청한 적중력과 이전 페이지의 적중력을 메모리에 불러와야 합니다.깊은 페이지나 대량의 결과에 대해 이러한 조작은 메모리와 CPU 사용률을 현저하게 증가시켜 성능 저하나 노드 고장을 초래할 수 있다.
기본적으로from과size 페이지를 10000개 이상 바꿀 수 없습니다.이 제한은 index입니다.max_result_윈도우 인덱스 설정에 설정된 보호 조치입니다.10000개 이상의 일치하는 항목을 페이지별로 조회하려면 search_after 매개 변수.
WARNING: Elasticsearch는 Lucene의 내부 문서 ID를 무승부로 사용합니다.이러한 내부 문서 ID는 동일한 데이터의 사본 간에 완전히 다를 수 있습니다.페이지별 검색이 적중되었을 때, 같은 정렬 값을 가진 문서의 순서가 일치하지 않는 것을 간혹 볼 수 있습니다.

Search after

search_after 매개 변수, 이전 페이지의sortvalues 그룹을 사용하여 일치하는 다음 페이지를 검색합니다.
search_ 사용after는 같은query와sort 값을 가진 여러 개의 검색 요청을 요구합니다.이 요청 사이refresh가 발생하면 결과의 순서가 바뀌어 페이지 사이의 결과가 일치하지 않을 수 있습니다.이러한 상황을 방지하기 위해 검색 과정에서 현재 색인 상태를 유지하기 위해 시점(PIT)을 만들 수 있습니다.

POST /my-index-000001/_pit?keep_alive=1m

API가 PIT ID를 반환합니다.

{
  "id": "46ToAwMDaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQNpZHkFdXVpZDIrBm5vZGVfMwAAAAAAAAAAKgFjA2lkeQV1dWlkMioGbm9kZV8yAAAAAAAAAAAMAWICBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
}

결과의 첫 페이지를 얻으려면sort 파라미터가 있는 검색 요청을 제출하십시오.PIT를 사용하는 경우 pit.id 매개 변수에 PIT ID를 지정하고 요청 경로에서 대상 데이터 흐름이나 인덱스를 생략합니다.
WARNING: 정렬에 tiebreaker 필드를 추가하는 것을 권장합니다.tiebreaker 필드는 모든 문서에 유일한 값을 포함해야 합니다.tiebreaker 필드를 포함하지 않으면 페이지 결과가 분실되거나 반복적으로 일치할 수 있습니다.

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "elkbee"
    }
  },
  "pit": {
	    "id":  "46ToAwMDaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQNpZHkFdXVpZDIrBm5vZGVfMwAAAAAAAAAAKgFjA2lkeQV1dWlkMioGbm9kZV8yAAAAAAAAAAAMAWICBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",       #   PIT ID
	    "keep_alive": "1m"
  },
  "sort": [    #  
    {"@timestamp": "asc"},
    {"tie_breaker_id": "asc"}
  ]
}

검색 응답은 일치하는 항목마다 정렬 값 그룹을 포함합니다.PIT를 사용하는 경우 응답하는 pit_id 매개변수에는 업데이트된 PIT ID가 포함되어 있습니다.

{
  "pit_id" : "46ToAwEPbXktaW5kZXgtMDAwMDAxFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAFldicVdzOFFtVHZTZDFoWWowTGkwS0EAAAAAAAAAAAQURzZzcUszUUJ5U1NMX3Jyak5ET0wBFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAAA==",    #   ID
  "took" : 17,
  "timed_out" : false,
  "_shards" : ...,
  "hits" : {
    "total" : ...,
    "max_score" : null,
    "hits" : [
      ...
      {
        "_index" : "my-index-000001",
        "_id" : "FaslK3QBySSL_rrj9zM5",
        "_score" : null,
        "_source" : ...,
        "sort" : [       #                           
          4098435132000,
          "FaslK3QBySSL_rrj9zM5"
        ]
      }
    ]
  }
}

다음 페이지의 결과를 가져오려면 마지막으로 일치하는 정렬 값을 search_after 매개 변수가 이전 검색을 다시 실행합니다.PIT를 사용하는 경우 pit.id 매개변수에 최신 PIT ID가 사용됩니다.검색된query와sort 매개 변수는 변하지 않아야 합니다.제공하면from 매개 변수는 0 (기본값) 또는 -1 이어야 합니다.

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "elkbee"
    }
  },
  "pit": {
	    "id":  "46ToAwEPbXktaW5kZXgtMDAwMDAxFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAFldicVdzOFFtVHZTZDFoWWowTGkwS0EAAAAAAAAAAAQURzZzcUszUUJ5U1NMX3Jyak5ET0wBFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAAA==",    #   PIT ID
	    "keep_alive": "1m"
  },
  "sort": [
    {"@timestamp": "asc"},
    {"tie_breaker_id": "asc"}
  ],
  "search_after": [        #                          
    4098435132000,
    "FaslK3QBySSL_rrj9zM5"
  ]
} 

다른 페이지의 결과를 얻기 위해 이 과정을 반복할 수 있습니다.PIT를 사용하는 경우 각 검색 요청의keep_alive 매개 변수는 PIT의 보존 기간을 연장합니다.
완료되면 PIT를 삭제해야 합니다.

DELETE /_pit
{
    "id" : "46ToAwEPbXktaW5kZXgtMDAwMDAxFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAFldicVdzOFFtVHZTZDFoWWowTGkwS0EAAAAAAAAAAAQURzZzcUszUUJ5U1NMX3Jyak5ET0wBFnVzaTVuenpUVGQ2TFNheUxVUG5LVVEAAA=="
}

Scroll search results

IMPORTANT: 우리는 더 이상 scroll API를 사용하여 깊이 있는 페이지를 나누는 것을 권장하지 않습니다.10000여 개의 일치 항목을 열람할 때 색인 상태를 유지해야 한다면 시간점(PIT)이 있는 search_after 매개 변수.
검색 요청이 하나의'페이지'결과를 되돌려 줄 때, scroll API는 하나의 검색 요청으로부터 대량의 결과 (심지어 모든 결과) 를 검색하는 데 사용할 수 있으며, 그 방식은 전통적인 데이터베이스에서 커서를 사용하는 방식과 거의 같다.
scroll은 실시간 사용자 요청에 사용되는 것이 아니라 대량의 데이터를 처리하는 데 사용됩니다. 예를 들어 하나의 데이터 흐름이나 인덱스의 내용을 서로 다른 설정을 가진 새로운 데이터 흐름이나 인덱스로 다시 인덱스하기 위해서입니다.
노트: scroll 요청에서 되돌아온 결과는 초기 검색 요청을 보낼 때 데이터 흐름이나 색인 상태, 예를 들어 시간 스냅샷을 반영합니다.문서의 후속 변경 사항(인덱스, 업데이트 또는 삭제)은 이후의 검색 요청에만 영향을 미칩니다.
scroll을 사용하기 위해서, 초기 검색 요청은 검색 문자열에 scroll 파라미터를 지정해야 합니다. 이 파라미터는 Elasticsearch가'검색 상하문'을 활성 상태로 유지해야 하는 시간을 알려 줍니다. 예를 들어?scroll=1m .

POST /my-index-000001/_search?scroll=1m
{
  "size": 100,
  "query": {
    "match": {
      "message": "foo"
    }
  }
}

위의 요청 결과는 하나의_scroll_id, 다음 결과를 검색하기 위해 scroll API에 전달해야 합니다.

POST /_search/scroll     #   GET   POST ，  URL  ，                                                            
{
  "scroll" : "1m",     # scroll   Elasticsearch   1                                                              
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="      # scroll_id  
}

크기 매개 변수는 매 결과가 되돌아오는 최대 일치 수를 설정할 수 있습니다.scroll API를 호출할 때마다 다음 결과를 되돌려줍니다. 다른 결과가 없을 때까지hits 수조가 비어 있습니다.
IMPORTANT: 초기 검색 요청 및 후속 scroll 요청마다 하나씩_scroll_id .비록_scroll_id는 두 번의 요청 사이에 변경될 수 있지만 항상 변경되는 것은 아닙니다. 어떤 경우에도 최근에 받은 _만 사용해야 합니다.scroll_id .
참고: 집합 지정을 요청하면 초기 검색 응답에만 집합 결과가 포함됩니다.
NOTE:scroll 요청은 정렬 순서를 _로 설정할 수 있는 최적화 기능을 제공합니다.doc 시간이 더 빠릅니다.순서를 고려하지 않고 모든 문서를 훑어보는 것이 가장 효과적인 선택입니다.

GET /_search?scroll=1m
{
  "sort": [
    "_doc"
  ]
}

Keeping the search context alive
scroll은 초기 검색 요청 시 검색과 일치하는 모든 문서를 되돌려줍니다.그것은 이 문서들에 대한 후속 변경 사항을 무시했다.scroll_id는 검색 상하문을 표시합니다. 이 상하문은 Elasticsearch를 추적하여 정확한 문서에 필요한 모든 것을 되돌려줍니다.검색 컨텍스트는 초기 요청에 의해 작성되고 후속 요청에 의해 활성 상태로 유지됩니다.
scroll 매개 변수 (검색 요청과 모든 scroll 요청에 전달) 는 Elasticsearch가 검색 상하문을 얼마나 오래 유지해야 하는지 알려 줍니다.그것의 값 (예를 들어 1m, Time units 참조) 은 모든 데이터를 처리하는 데 충분한 시간이 필요하지 않고, 이전 결과를 처리하는 데 충분한 시간이 필요합니다.모든 scroll 요청 (scroll 파라미터가 있음) 은 새로운 만료 시간을 설정합니다.scroll 매개 변수에서 scroll 요청을 전달하지 않으면 검색 상하문은 이 scroll 요청의 일부분으로 방출됩니다.
일반적으로 백그라운드 병합 과정은 비교적 작은 세그먼트를 한데 합쳐서 새로운 비교적 큰 세그먼트를 만들어서 색인을 최적화시킨다.더 이상 작은 세그먼트가 필요하지 않으면 삭제합니다.scroll 과정 중, 이 과정은 계속 진행되지만, 열려 있는 검색 상하문은 오래된 세그먼트를 삭제하는 것을 방지할 수 있습니다. 왜냐하면 그들은 여전히 사용 중이기 때문입니다.
TIP: 이전 세그먼트를 활성 상태로 유지하려면 디스크 공간과 파일 핸들이 더 필요합니다.노드가 충분한 빈 파일 핸들로 구성되었는지 확인하십시오.File Descriptors 를 참조하십시오.
또한 세그먼트에 삭제되거나 업데이트된 문서가 포함된 경우 검색 컨텍스트는 해당 세그먼트의 각 문서가 초기 검색 요청 시 활성 상태인지 추적해야 합니다.만약 인덱스에 열려 있는 스크롤이 많다면, 이 인덱스들은 끊임없이 삭제되거나 업데이트될 것입니다. 노드가 충분한 공간을 가지고 있는지 확인하십시오.
노트: 스크롤을 너무 많이 열어 문제를 방지하기 위해 사용자가 특정한 제한을 초과한 스크롤 바를 열 수 없습니다.기본적으로 scrolls를 최대 500까지 엽니다.검색을 사용할 수 있습니다.max_open_scroll_context 군집 설정으로 이 제한을 업데이트합니다.
nodes stats API를 사용하여 검색 컨텍스트가 얼마나 열려 있는지 확인할 수 있습니다.

GET /_nodes/stats/indices/search

Clear scroll
scroll이 시간을 초과하면 검색 상하문은 자동으로 삭제됩니다.단, 이전 절에서 말한 바와 같이 scroll을 열지 않는 것은 대가가 있기 때문에 더 이상 사용하지 않으면clear-scroll API로 스크롤을 명확하게 제거합니다.

DELETE /_search/scroll
{
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}

여러 scroll ID를 배열로 전달할 수 있습니다.

DELETE /_search/scroll
{
  "scroll_id" : [
    "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==",
    "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB"
  ]
}

사용 가능_all 매개 변수는 모든 검색 컨텍스트를 지웁니다.

DELETE /_search/scroll/_all

scroll_id도 검색 문자열 매개 변수나 요청 본문에서 전달할 수 있습니다.여러 scroll ID는 쉼표로 구분된 값으로 전달될 수 있습니다.

DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==,DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB

Sliced scroll
대량의 문서를 되돌려주는 scroll 조회에 대해 scroll을 여러 개의 슬라이스로 나눌 수 있습니다. 이 슬라이스는 독립적으로 사용할 수 있습니다.

GET /my-index-000001/_search?scroll=1m
{
  "slice": {
    "id": 0,      #   ID                
    "max": 2      #                  
  },
  "query": {
    "match": {
      "message": "foo"
    }
  }
}
GET /my-index-000001/_search?scroll=1m
{
  "slice": {
    "id": 1,
    "max": 2
  },
  "query": {
    "match": {
      "message": "foo"
    }
  }
}

첫 번째 요청의 결과는 첫 번째 영화 (id:0) 에 속하는 문서를 되돌려주고, 두 번째 요청의 결과는 두 번째 영화에 속하는 문서를 되돌려줍니다.슬라이스의 최대 수량이 2로 설정되어 있기 때문에 두 요청의 결과의 병합은 슬라이스가 아닌 스크롤 조회의 결과와 같다.기본적으로 조각을 분할한 다음 _슬라이스 (doc) =floorMod(hashCode(doc._id),max) 예를 들어 슬라이스 수가 2와 사용자가 4개의 슬라이스를 요청하면 슬라이스 0과 2를 첫 번째 슬라이스에 분배하고 슬라이스 1과 3을 두 번째 슬라이스에 분배합니다.
모든 scroll은 독립적이며, 어떠한 scroll 요청처럼 병행 처리할 수 있습니다.
노트: 슬라이스의 수가 슬라이스의 수량보다 많으면 슬라이스 필터는 처음 호출할 때 매우 느리고, 복잡도는 O(N)이며, 메모리 비용은 각 슬라이스 N위와 같고, 여기서 N은 슬라이스의 문서 총수입니다.몇 번 호출한 후에 필터를 캐시해야 하며, 그 후의 호출은 더욱 빨라야 하지만, 메모리 폭발을 피하기 위해 병행 실행되는 슬라이스 조회의 수량을 제한해야 한다.
이런 비용을 완전히 피하기 위해 다른 필드를 사용할 수 있는 doc_values는 슬라이스를 진행하지만 사용자는 이 필드에 다음과 같은 속성이 있는지 확인해야 합니다.

이 필드는 숫자입니다

doc_values는 이 필드에서 사용됩니다

문서마다 값을 포함해야 합니다.문서의 지정된 필드에 여러 개의 값이 있는 경우 첫 번째 값을 사용합니다

문서를 만들 때 각 문서의 값을 한 번 설정하고 영원히 업데이트하지 마십시오.이렇게 하면 모든 절편이 확실한 결과를 얻을 수 있다

이 필드의 기수는 매우 높을 것이다.이렇게 하면 각 슬라이스에서 얻은 문서의 수가 대체로 같음을 확보할 수 있다

  GET /my-index-000001/_search?scroll=1m
  {
    "slice": {
      "field": "@timestamp",
      "id": 0,
      "max": 10
    },
    "query": {
      "match": {
        "message": "foo"
      }
    }
  }

시간 기반 인덱스만 추가하면timestamp 필드를 안전하게 사용할 수 있습니다.
기본적으로, 매번 scroll이 허용하는 최대 슬라이스 수는 1024로 제한됩니다.index를 업데이트할 수 있습니다.max_slices_per_이 제한을 우회하기 위해 scroll 인덱스 설정.
자세한 내용은 홈페이지:https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html