1. Fielddata 란?
만약 특정 field로 정렬을 수행할때, query에 매칭되는 모든 document의 정렬 기준 field에 접근을 해야한다. 역인덱스(inverted index)라고 불리는 이러한 구조는 검색을 수행할때 탁월하지만, 정렬을 수행할 경우 이상적인 방법은 아니다.
역인덱스 개념 참고 - http://www.elastic.co/guide/en/elasticsearch/guide/master/inverted-index.html
다시말해, 검색을 할때는 해당 term을 document에 mapping (inverted index) 시키지만, 정렬을 수행 할때는 document를 term에 mapping 시키는것이 더 효율 적이라는 말이다.
바로 'uninverted index' 개념이 필요한 것이다.
이러한 uninverted index 개념을 실현하여 정렬을 더 효율적으로 하기 위해, Elasticsearch는 정렬 기준이 되는 field를 메모리에 적재(load)하는데, 이때 특정 query에 매치되는 document의 field 뿐아니라, 모든 document의 field를 메모리에 적재 한다
모든 field를 적재하는 이유는, 요청 때마다 매번 메모리에 적재하여 사용하는 것보다, 미리 모든 field를 몽창 적재해 놓으면, 그 다음에 수행되는 query에도 사용하기 용이하기 때문이란다. 물론 새로운 document가 인덱싱 되면 그 document의 field도 적재가 된다.
이것이 Fielddata의 기본적인 개념이다.
Fielddata는 다음과 같은 경우 사용하게 된다.
색인되는 모든 field를 메모리에 적재하는 특징 때문에, 굉장히 많은 메모리를 소비하는것은 물론 문제다. 이는 다음 포스팅에 살펴볼 Memory 부족으로 인한 OOM이나, CircuitBreakingExcpetion의 원인이 될 수도 있다.
Fielddata는 다음과 같은 경우 사용하게 된다.
- Sorting on a field
- Aggregations on a field
- Certain filters(예를 들어 geolocation filters와 같은)
- Scripts that refer to fields
색인되는 모든 field를 메모리에 적재하는 특징 때문에, 굉장히 많은 메모리를 소비하는것은 물론 문제다. 이는 다음 포스팅에 살펴볼 Memory 부족으로 인한 OOM이나, CircuitBreakingExcpetion의 원인이 될 수도 있다.
하지만, 이러한 메모리 부족 문제는 클러스터에 노드를 추가 하는 등의 수평적 확장(Horizontal scaling)을 통해 해결 할 수 있다.
2. Fielddata Monitoring
Fielddata에 의해서 어느정도의 메모리가 사용되고 있는지 모니터링 할 수 있다.
아래와 같은 api를 사용하자
① index 레벨에서의 조회
$ curl -XGET 'localhost:9200/_stats/fielddata?fields=*&pretty'
위 api는 각 index별로 전체적인 fielddata 상태를 출력한다
② node 레벨에서의 조회
$ curl -XGET 'localhost:9200/_nodes/stats/indices/fielddata?fields=*&pretty'
위 api는 클러스터 내의 각 node별로 사용되고 있는 fielddatad 상태를 출력한다.
댓글 없음:
댓글 쓰기