Elasticsearch Fields _소스 반환값 필드 설정

공식 문서: 검색 시 Elasticsearch Fields 관리

Elasticsearch 반환값 필드 설정

Elasticsearch의 성능을 최대한 향상시키려면 검색 요청이 되돌아오는 필드의 수를 제어하는 것이 중요하다.이 장에서 우리는 우리의 응용을 어떻게 최적화하는지, 모든 검색 결과에서 우리가 필요로 하는 필드만 선택적으로 되돌려주는지 설명할 것이다.

소개

검색에서 매개 변수 fields 를 사용하면 모든 검색 적중 항목 (검색 결과hit) 이 되돌아오는 열 (fields) 을 제한할 수 있습니다.이 기능은 대량의 데이터 전송을 최적화하는 데 사용되며, Elasticsearch 검색 결과에 대량의 반환열이 있을 때, 관련 열만 되돌려줍니다.물론 그것은 매우 간단하게 들리지만, 그것은 성능에 큰 영향을 미친다. 검색 성능은 문서로 돌아가는 수량과 모든 문서의 크기 두 가지 요소와 반비례한다.
이러한 상황을 고려하여 문서의 평균 크기가 20KB이면 조회 요청이 10개의 조회 결과를 되돌려주는 것은 평균 200KB의 데이터이다.만약 1초에 100번을 요청한다면 우리는 20M의 대역폭을 필요로 한다.만약에 우리가 유용한 필드만 되돌려주면 문서의 크기를 800바이트까지 줄일 수 있다고 합리적으로 가정하면 요청마다 대체적으로 8KB의 데이터량만 되돌려주고 초당 100번을 요청하면 800KB의 대역폭만 필요로 한다.대규모로 사용하려면 결과가 가능한 한 작아야 한다는 보장이 매우 중요하고 실용적이다.
기본적으로 열려 있는 필드는 _source 입니다. 이 필드는 해석된 문서의 내용을 포함하고 있으며, 매번 조회한 후에 되돌아옵니다.문서의 모든 컨텐트를 찾고 해석할 필요가 없을 때 반환된 필드 fields 를 제한하여 귀중한 서버 CPU 시간과 디스크 IO를 절약할 수 있습니다.위에서 말한 fields만으로도 이 점을 실현할 수 있다.원본 문서 (document) 와 열 (fields) 을 동시에 되돌려야 한다면, 매개 변수 _source 를 사용하여 필터를 할 수 있으며, 그 다음에 그 사용법을 소개할 것입니다.
필드의 또 다른 특성은 널리 알려지지 않았으며, 쿼리 필드 (metadata-fields) 에도 사용할 수 있습니다.이 필드의 값은 원래 문서를 조회하는 데 필요한 시간이 아니라 밀리초 단위로 조회 결과를 되돌려줍니다.이것은 확실히 매우 실용적인 기교다.

네스트 데이터 및 네스트 열(Nested Fields and Nested Data)

어떤 때는 간단한 필드만 조회하는 것이 부족하지만, 이때 우리는 끼워 넣은 필드의 데이터를 동태적으로 조회해야 할 수도 있다.이런 상황에서 우리는 _ttl 을 사용할 수 없습니다. 그렇지 않으면 다음과 같은 실패 정보만 얻을 수 있습니다. 번역자 주석: 이 정보는 Elasticsearch 로그에 있는 것입니다. 일반적인 상황에서 컨트롤러에서 볼 수 없습니다.

{
    ...,
    "_shards": {
        "failures": [
            {
                "index": "index-name",
                "shard": 2,
                "status": 400,
                "reason": "ElasticsearchIllegalArgumentException[field [field_with_nested_data] isn't a leaf field]"
            }
        ]
    },...
}

이 이상은 fields 잎 노드에만 사용할 수 있는 데이터(즉, 이 노드에는 하위 노드가 없음) 때문이다.비잎 노드를 불러올 수 있도록 조회할 때 fields 파라미터를 사용해야 합니다. 이 파라미터는 원본 문서의 특성을 활성화할 수 있습니다. (원본 문서를 필터할 수 있습니다.) 아래에서 상세하게 설명합니다.

소스 문서 필터링(Source Filtering)

원본 문서 필터링은 질의에서 원본 JSON 문서의 일부가 반환되는 것을 제어합니다.우리는 열을 포함하거나 배제할 수 있습니다. 패턴 일치를 통해 열 이름의 접근 경로를 필터하면 됩니다.이것은 검색 노드에서 호출 클라이언트까지의 대역폭만 절약할 수 있을 뿐, cpu 시간과 디스크 IO를 절약할 수 없습니다. _source 를 사용하지 않으면.이것은 원본 문서 필터를 사용할 때, 모든 검색 결과에 대해 원본 문서를 분석하고, 제공된 패턴에 따라 일치하게 반환값에 이 열을 포함하거나 배제해야 하기 때문이다.그러나 우리의 최적화 계획에서 그것은 여전히 매우 중요한 방식이고 사용이 매우 쉬워서 우리는 그것으로부터 최적화의 첫걸음을 열 수 있다.
1.0 버전 이전에 더욱 널리 알려진 검색 방식인 partialfields가 있었는데, 지금은 유행이 지났고, 본고의 원본 문서에 의해 필터링되어 대체되었다.
뒤에 두 단락이 더 있는데 제가 사용한 적이 없기 때문에 내용의 번역에 대해 잘 파악하지 못합니다.당분간 번역 안 할게요.미완성 계속...
번역자 첨부: fields 및 fields의 사용 방식

//fields
{
  // 
  ……
  "fields": [
    "goods_sale_number",
    "id"
  ]
}

//_source
{
  // 
  ……
  "_source": [
    "goods_sale_number",
    "id"
  ]
}

사실 별 차이가 없다. 단지 두 개의 메커니즘이 다르고 _source 플러그인 유형만 지원한다.본문이 너에게 도움이 될 수 있기를 바란다.