elasticsearch index sorting으로 퍼포먼스 향상

sorting index는 루씬에서 sorting을 지원하기 위해 indexSorter라는 것을 도입해 검색 시점이 아니라 색인과 병합 시점에 문서를 정렬하는 방법을 제공하고 검색 포퍼먼스 향상을 위해서 도입된 개념이다

 

예시를 통해 알아보자

PUT scores
{
  "settings": {
    "index": {
      "sort.field": "points", 
      "sort.order": "desc"  
    }
  },
  "mappings": {
    "properties": {
      "points": {
        "type": "date"
      }
    }
  }
}

GET scores/_search
{
  "size": 3,
  "sort": [
      { "points": "desc" }
  ]
}

쉽게 알기 위해서 1 나의 샤드에서 세그먼트가 1나만 존재한다고 했을 때

인덱스 소팅은 아래 이미지와 같이 이미 정렬해서 데이터를 저장하므로 3개의 다큐먼트만 읽고 stop을 해서 검색 속도를 향상한다

아래의 예제에서도 같은 설명을 하고 있다.

 

PUT players
{
    "settings" : {
        "index" : {
            "sort.field" : ["region", "game", "skill-rating", "map"], 
            "sort.order" : ["asc", "asc", "asc", "asc"] 
        }
    },
    "mappings": {
        "player": {
            "properties": {
                "playerid": {
                  "type": "keyword"
                },
                "region": {
                  "type": "keyword"
                },
                "skill-rating" : {
                  "type" : "integer"
                },
                "game" : {
                  "type" : "keyword"
                },
                "map" : {
                  "type" : "keyword"
                }
            }
        }
    }
}

---

GET players/_search
{
  "size": 3,
  "track_total_hits" : false,
  "query" : { 
    "bool" : {
      "filter" : [
        { "term" : { "region" : "eu" } },
        { "term" : { "game" : "dragons-lair" } },
        { "term" : { "skill-rating" : 9 } },
        { "term" : { "map" : "castle" } } 
      ]
    }
  }
}

 

정렬을 위한 쓰기 비용 발생

정렬된 값을 저장하기 위해서는 정렬되지 않을 것을 저장하는 것보다 더 많은 비용이 발생하게 된다 이로 인해 쓰기 성능이 40~50%까지 떨어질 수 있다 이러한 이유로 index sorting를 사용할 때에는 신중하게 생각하고 선택해야 한다

 

알고 가자!

1. 세그먼트 별로 문서 ID가 할당되며 샤드 내부의 세그먼트가 정렬되는 방식이므로 primary shard가 여러 개면 정렬을 해주긴 해줘야 한다
2. track_total_hits를 false 해주거나 제거해서 사용해야 한다
3. docvlaue를 지원하는 type만 가능하다
4. nested field는 지원하지 않는다
5. flush, merge시에 정렬되어 저장된다
6. 기존에는 부합되는 다큐먼트를 다 읽는다면 정렬이 되었기 때문에 부합된 것들 중에서 사이즈만큼만 읽는다
7. 실제로는 위의 이미지 같이 하나의 세그먼트가 아니라 여러 개의 세그먼트가 있을 것이다 그래서 각 세그먼트에서 요청된 사이즈 크기만큼 읽고 반환한다
8. aggr 할 때에는 다 읽어야 하기 때문에 성능 이점을 살릴 수 없다

 

참조 

www.elastic.co/kr/blog/index-sorting-elasticsearch-6-0