Elasticsearch7 이상부터 사용해야하는 이유

성능 개선과 안정화

더 빠른 상위 검색:

이전에는 "이것", "을"과 같이 빈번하게 등장하는 용어를 쿼리에 입력했을 때 도큐먼트의 점수를 계산하도록 하였지만 이는 검색을 최적화하는데 효과적이지 못했다. 그래서 이제는 이런 빈번한 단어들은 건너뛰고 전체 도큐먼트가 아닌 top 10,000개의 도큐먼트에서 쿼리를 합니다

Adaptive Replica Selection

Elasticsearch는 데이터를 분산 처리하기 위해 샤딩(sharding)을 사용합니다. Elasticsearch 7에서는 샤딩 관련 알고리즘과 프로세스를 개선하여 샤딩을 더 효율적으로 관리하게 되었고, 이로 인해 대규모 데이터 세트에 대한 검색 및 인덱싱 성능이 향상되었습니다.  이전에는 라운드로빈 방식으로 레플리카 노드에 전달되었지만 이제는 검색요청에 걸리는 시간을 추적하고 비교하여 여러개의 Replica 중 빠른 Replica를 능동적으로 찾아 쿼리합니다.

 

새로운 Similarity 모델 도입 (BM25):

Elasticsearch 7에서는 문서의 유사도를 계산하는 방법을 개선했습니다. 이전에는 TF/IDF 방식을 사용했으나, 이는 각 문서에 특정 단어가 얼마나 자주 등장하는지에 중점을 두었습니다. 그러나 Elasticsearch 7에서는 Okapi BM25 모델을 새로 도입하여 문서의 순위를 더욱 정확하게 결정할 수 있게 되었습니다.

 

안정화와 사용성 개선

• 디폴트 Primary Shard 개수가 5 에서 1로 변경됩니다.
• 기본 번들에 JDK 추가
• Java High-Level Rest Client로 모든 기능 마이그레이션
• Maximum 메모리 사용시 제한을 두어 OOM이 발생하지 않도록 하는 기능 추가

 

참조

https://www.elastic.co/kr/blog/elasticsearch-7-0-0-released

Elasticsearch 7.0.0 released

http://kimjmin.net/2019/04/2019-04-elastic-stack-7-release/

Elastic Stack 7.0 출시 밎 지금까지의 변경들 - Jongmin's Lifelog

 

API 변경과 매핑 타입의 삭제

성능 개선 이외에도 중요하다고 생각되는 것은 API의 변경과 매핑 타입이 삭제이다. 이것은 기존 엘라스틱 서치를 업글레이드 하는 것에 대해 큰 계기가 되었고 엘라스틱 스택에서도 마이그레이션하는 것을 권장하며 리인덱싱(재색인)하는 방법에 대해서도 자세히 기술하여 문서에 정리를 해놓았다.

 

매핑 타입이란? 

트위터라는 인덱스가 존재한다고 했을 때 트위터는 유저 타입과 트윗이라는 타입을 가지게 됩니다. 유저라는 타입은 "이름", "닉네임", "이메일" 필드를 가지게 되고 트윗이라는 타입은 "내용", "생성일", 그리고 유저가 가지고 있는 "닉네임"이라는 필드를 가지게 됩니다. 각 도큐먼트에는 _type의 이름이 포함된 메타필드가 존재하여 하나 이상의 검색 건으로 제한 할 수 있었다.

GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name":"kimchy"
    }
  }
}

_type 필드는 문서의 _id와 결합하여 _uid 필드를 생성했으므로, 동일한 _id를 가진 다른 타입의 문서들이 하나의 인덱스에서 존재할 수 있었다. 매핑 타입은 또한 문서간의 부모-자식 관계를 설정하는 데 사용되면서 question 타입의 문서는 answer 타입의 문서의 부모가 될 수 있었다.

 

 

삭제한 이유 

Elasticsearch 초기에는 우리가 "인덱스"를 SQL 데이터베이스의 "데이터베이스"에 비유하고, "타입"을 "테이블"과 동일시했습니다.

 

이는 잘못된 비유로, 잘못된 가정을 유발했습니다. SQL 데이터베이스에서, 테이블들은 서로 독립적입니다. 한 테이블의 열은 다른 테이블의 같은 이름의 열에 영향을 미치지 않습니다. 그러나 이는 매핑 타입의 필드에 대해선 해당되지 않습니다.

 

Elasticsearch 인덱스에서, 서로 다른 매핑 타입에서 같은 이름을 가진 필드들은 내부적으로 같은 Lucene 필드에 의해 지원됩니다. 다시 말해, 위의 예를 사용하면, user 타입의 user_name 필드는 tweet 타입의 user_name 필드와 동일한 필드에 저장되며,
두 user_name 필드는 두 타입에서 모두 같은 매핑을 가지게 됩니다.

 

이는 예를 들어, 한 타입에서는 다른 타입의 필드를 사용하고 싶을 때 곤란을 초래할 수 있습니다.

 

뿐만 아니라, 공통 필드가 거의 없거나 서로 다른 다른 엔티티를 같은 인덱스에 저장하게 되면서 데이터의 독립성을 해치게 되고, Lucene의 문서 압축 효율성을 해치게 됩니다.

 

이러한 이유로, 우리는 Elasticsearch에서 매핑 타입의 개념을 제거하기로 결정했습니다.

 

참조

https://www.elastic.co/blog/removal-of-mapping-types-elasticsearch