elasticseaarch eager global ordinal를 사용해 퍼포먼스를 올려보자

문자열 fielddata의 메모리 사용을 줄이는 기술중 하나가 ordinal이다

cardinality가 작은 status필드 가진 10억개의 문서가 있다고 생각해보자

status_deleted, status_pending, status_published라는 세가지 상태 값이 있고 10억개면 이 전체를 메모리에 유지하기 위해서는 1나당 14 ~ 16 바이트가 필요하며 전체 데이터로는 약 15gb가 필요하다 이처럼 비싼 비용을 들이는 대신 세개의 교유 한 문자열을 식별, 정렬해서 번호를 매긴다 0, 1, 2

ordinal data

이처럼 하게 되면 아래와 같이 메모리 사용량이 15gb에서 1gb미만으로 줄게 된다 문자열 보단 숫자가 용량을 훨씬 더 적게 먹기 때문이고 비교 연산, 네트워크 등등에서 많은 이점을 가지고 갈 수 있게 된다

ordinal data

분산 처리인 엘라스틱서치에서 1000개의 데이터를 정렬한다고 했을 때 여러개의 노드의 샤드에서 데이터를 받아와야 한다 global_eager_ordinal이 없다면 문자열로 데이터를 받아와야 하는데 상당한 네트워크 비용이 들고

그 문자열을 비교하여 정렬했을 때도 비용이 많이 들게 된다 그러나 숫자로 데이터를 받아와서 정렬한 뒤에 서수를 원본으로 교체한다 상당한 비용을 절약할 수 있다

글로벌 서수와 로컬 서수가 있는데 로컬 서수는 각 데이터노드의 샤드를 커버하며 글로벌 서수는 코디네이터와 같은 데이터의 전체를 받아서 처리하는 영역에 있는 서수이다

 

 

*

1. 서수는 문자만 사용되어집니다 숫자(정수, 지리, 날짜 등) 데이터는 서수를 사용할 수 없고 fielddata를 활성화한 text , keyword, ip, keyword type을 지원한다
2. 물론 서수가 비용이 안들어가는 것은 아니다 해당 값이 제거되거나 새로운 값이 추가 되었을 때 서수가 다시 작성해야된다 재구축은 모든 세그먼트에서 고유 용어를 읽어와야 하므로 비용이 발생하는데 더 무시무시한 것은 cardinality의 크기가 클 경우이다 예를들면 성별인 경우에는 cardinality가 작기 때문에 비용이 덜 들지만주민등록번호 같은 것은 고유하기때문에 cardinality의 크기가 엄청 커져 엄청난 비용이 들게된다 그래서 색인이 자주 발생하고 쿼리가 자주 발생하지 않는 곳은 색인 시점보다 쿼리 시점에 비용이 발생하도록 하는 것이 유리하다 그래서 refresh_interval 늘리면 cpu 사용도 줄이고 글로벌 서수 리빌드도 줄일 수 있다
3. global ordinal은 field data cache로 인해서 부분적으로 힙 메모리를 사용한다
4. eager global ordinals를 true로 하면 refresh할 때 global ordinals가 빌드 되고 false로 하면 검색 시점에 계산을 한다 즉 global ordinal은 false로 해도 사용하지만 색인시 사용할 것이냐 검색시 사용할것이냐로 나누어지는 것이다
5. fielddata를 활성화한 text type을 가지고 집계를 할 경우에도 global ordinal을 사용한다

참조

https://www.elastic.co/guide/en/elasticsearch/guide/current/preload-fielddata.html#global-ordinals

Preloading Fielddata | Elasticsearch: The Definitive Guide [2.x] | Elastic

www.elastic.co/guide/en/elasticsearch/reference/master/eager-global-ordinals.html#_avoiding_global_ordinal_loading

eager_global_ordinals | Elasticsearch Reference [master] | Elastic

medium.com/driven-by-code/elasticsearch-global-ordinals-31df2806391f

Elasticsearch Global Ordinals