Line 세미나. 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법 - 1. 검색 쿼리 개선

- 발표자 : Taku Tada

시스템 상황

- 유저가 곡을 검색 할 시 meta search api server에 요청이 들어오고 Elasticsearch에 검색을 요청한다.

- 8천 500만건의 데이터가 엘라스틱 서치에 들어가 있다.

- 지금 발표하는 내용은 음악에 대한 검색과 책 데이터등에서 활용될 수 있다고 생각한다.

- 기존에 검색에 사용되던 플드는 오직 Track Name 하나 뿐이었는데 추후 기능 피처로 트랙이름, 부가적인 트랙정보, 앨범이름, 아티스트 이름, 레이블 프로덕트 코드, ISRC와 같응ㄴ 데이터를 조회 조건으로 같이 걸어야했다. 이로인해 기존에 1초 걸리던 검색이 5초 정도의 시간으로 증가하게 되었다.

 

 

느렸던 이유

- 기존에는 keyword 타입으로 와일드 카드를 이용해서 조회를 했다.

- 이는 공식 문서에서도 그렇고 엄청 느리다고 나와있다.

- 마찬가지로 라인에서도 느렸다.

 

 

그럼 왜 키워드 타입을 사용했나?

- 빠르게 릴리즈 해야했다.

- text 타입의 경우 tokenize 개발이 필요했고 트랙, 앨범, 아티스트 이름은 명사(고유명사)이고 짧기 때문에 사전 기반에 text type이 효율적이지 않다고 판단했다.

- 슬랭과 지역 사투리와 같은 부분이 많아서 형태소 분석을 하기에는 적합하지 않았다.

 

 

기능개선

- 기존에 analyze 되지 않았던 타입을 text 타입으로 변경하여 analyze할 수 있도록 변경

- 역인덱스를 이용해서 거대한 데이터를 빠르게 조회할 수 있도록 match 쿼리 실행

- tokenize는 기존의 방식이 아닌 n-gram을 사용해서 토큰이 나눠질 수 잏도록 생성

- 하지만 ID 2와 같이 역인덱스 테이블에서 찾아지는 여부로 보여지기 때문에 순서보장이 되지 않음. 이는 사용자에게 불편함을 도래

- 이를 해결하기 위해서 ngram 사이즈마다 필드를 만들고 (1, 2, 3) 3이상은 3으로 통일했다. 이 이상 순서 문제가 발생할일이 별로 없다고 판단.

- 참고 (https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-ngram-tokenizer.html)

N-gram tokenizer | Elasticsearch Guide [7.15] | Elastic

 

 

결과

- text-match 쿼리의 결과가 keyword-wildcard보다 성능은 드라마틱하게 좋았고 설계한 쿼리는 방식의 위와 같다.

 

 

 

내 생각

- 나도 자동완성 프로젝트를 진행하면서 n-gram tokenizer를 개발하여 사용했었다. 이곳에서 사용하는 앨범이름, 아티스트 이름등은 길이가 길어봐야 10자? 내외이기 때문에 이 방법이 유의미 했을 것 같은데 만약 100자가 넘는 텍스트의 경우에서는 이방법을 사용하게 되면 heap overflow가 발생한다. 실제로 인덱싱 매핑하다가 100자가 넘는 텍스트를 n-gram tokenizer를 사용하려 했을 때 문제가 되었다. 

- 필드가 많지 않고 여러 필드를 조화해서 검색결과를 내보내지 않는 경우에서는 유의미할 것 같다. 말그대로 음악, 책 검색등에서는 좋은 성과가 나올 것 같다.

- 이런 방식으로도 풀어서 사용할 수 있구나 라고 볼 수 있어서 좋았다.

- 세미나를 위한 발표내용보다 실제 경험을 공유하는 것 같아 좋았다. 좋은회사다.