회사에서 계속해서 다중인덱스 조회를 원하는 니즈가 있었다. 언젠가 해야지 해야지 했는데 이번에는 진짜 시작해야될듯했다… ㅠㅠ 그래서 찾아보니 검색스피드튜닝(https://www.elastic.co/guide/en/elasticsearch/reference/8.5/tune-for-search-speed.html) 을 위한 참고자료가 있었다. 사실 이전에 봤었는데 대충 지나갔었다. ^0^; 이번에는 자세히 살펴보게 되었다.
검색스피드튜닝 을 위한 방법은 여러가지가 있는데, 하드웨어 변경이 아닌 인덱스 설정이나 쿼리 설정을 바꿀 수 있는 선안에서 해결해보고자 했다. 살펴보니 script, nested 쿼리는 사용하지 말라고 했는데(사실 알고 있었음..ㅠ) 이미 사용할 수밖에 없는 서비스가 되어버려 패스…. 그나마 발견한 방법들이 아래와 같았다.
| 장점 | 단점 | |
|---|---|---|
| 인덱스 정렬 | • 인덱스를 정렬해둔 것과 동일한 필드로 정렬하는 쿼리문을 호출하여 그에 대한 결과를 반환하도록 요청하고자 한다면, 이때 Elasticsearch에서 이미 인덱스 정렬을 해뒀기 때문에 쿼리 시점에 그에 결과를 정렬할 필요가 없음 • 필드 간에 AND를 사용하는 쿼리일 경우, 이러한 필드에 대한 인덱스 정렬은 필드를 그룹화함 • 디스크 공간을 약 40% 절약할 수 있음 | • 성능테스트 필요 → 실서버가 이미 오픈되어 실서버 환경으로 테스트할 수 없음 • 정렬된 인덱스이기 때문에 저장시 쓰기성능이 40~50%까지 떨어질 수 있음 • 인덱스 생성 시 정의하기 때문에 인덱스를 다시 생성해야함 |
| eager global ordinal | • 집계 성능을 최적화하는 데 사용 • fielddata를 활성화한 text, keyword..에서 사용 • 사전식 순서로 각 고유 용어에 대해 증분 번호를 매겨 사용하여 매핑 (아래 참고자료 참고) • JVM 힙에 저장 • 기본값은 false → 검색시 로드됨 / true → 인덱싱시 로드됨 | • 성능테스트 필요 → 실서버가 이미 오픈되어 실서버 환경으로 테스트할 수 없음 • 필드 새로 매핑 필요한지 체크 |
| 기존 로직 변경 | 대외비 | 대외비 |
참고:
검색 스피드 튜닝
https://www.elastic.co/guide/en/elasticsearch/reference/8.5/tune-for-search-speed.html
인덱스 정렬
https://www.elastic.co/kr/blog/space-savings-a-lesser-known-benefit-of-index-sorting-in-elasticsearchhttps://ksk-developer.tistory.com/45https://www.elastic.co/guide/en/elasticsearch/reference/master/index-modules-index-sorting.html
eager global ordinal
https://www.elastic.co/guide/en/elasticsearch/reference/8.5/eager-global-ordinals.htmlhttps://wedul.site/502https://hexists.tistory.com/161https://ksk-developer.tistory.com/26https://medium.com/driven-by-code/elasticsearch-global-ordinals-31df2806391f
