Elastic Search

특징

• 검색 엔진: 전문 검색 지원, 역색인 통한 빠른 속도, 애널라이저 통한 형태소 분석
• 분산 처리
• 고가용성
• 수평적 확장성
• JSON기반 REST API 
• 준실시간 검색: 역색인으로부터 검색이 가능해지기까지 1초의 시간이 걸리기에, 준실시간 검색이라 할 수있다.
• 조인과 트랜잭션 미지원

 

Elasticsearch에서 하나의 인덱스에 하나의 타입만 구성할 수 있다는 제약이 있지만, 다른 타입을 사용해야 하는 경우에는 배열이나 다양한 필드로 여러 데이터를 저장하는 방법을 사용할 수 있다.

 

문서 색인

 

1. 색인(Indexing)

PUT [인덱스 이름] /_doc/[_id값]
{
    [문서 내용]
}

 

데이터를 Elasticsearch에 저장하는 과정. 이 작업은 주로 문서(document)를 특정 형식으로 Elasticsearch의 인덱스에 저장하는 데 사용됩니다. 저장된 데이터는 Elasticsearch에서 효율적으로 검색될 수 있도록 구조화

문서 식별 위해 _id 사용, _id 사용 안할 경우 자동생성

 

2. 조회

GET [인덱스 이름] /_doc/[_id값]

 

3. 문서 업데이트

POST [인덱스 이름] /_update/[_id값]
{
    “doc”:{
    [문서 내용]
    }
}

 

4. 문서 검색

GET [인덱스 이름]/_search

Post [인덱스 이름]/_serach

검색에 body를 사용하다보니, get을 쓰는것도 post를 쓰는것도 이상하다. 따라서 둘다 되도록 하였다.

 

5  문서 삭제

DELETE [인덱스 이름]/_doc/[_id값]

 

구조

 

• 문서
• 인덱스: 문서 모아 놓은 단위
• 샤드: 인덱스에서 각 문서의 내용을 여러 샤드로 분리해서 분산 저장, 고가용성을 위해 샤드 복제본
• 노드: 하나의 노드는 여러 개의 샤드, 고가용성을 위해 같은 종류 샤드를 같은 노드에 배치 하지 않음
• 클러스터: 노드 여러개가 모임

 

 

루씬

 

문서 색인하고 검색하는 라이브러리

앨라스틱서치는 아파치 루씬을 코어 라이브러리로 사용한다.

• 루씬 flush: 엘라스틱서치 refresh가 이러한 루씬 flush를 이용, 루씬 flush != 엘라스틱서치 flush
• 루씬 commit: 주기적으로 커널의 페이지 캐시 내용과, 실제 디스크에 기록된 내용의 동기화 필요
• 루씬 인덱스: 파일들을 모아 불변의 데이터 단위가 세그먼트,  여러개의 세그먼트 -> 루씬 인덱스가 되고, 이게 엘라스틱서치 샤드, 그리고 이러한 엘러스틱서치 샤드가 모여 엘라스틱서치 인덱스가 됨
• translog: commit은 비용이 많이들어, 작업 로그를 남겼다가 나중에 처리. translog크기도 적절히 유지해야하며 이를 루씬 commit이 해줌

 

 

인덱스

 

numbers_of_shards: 인덱스가 데이터를 몇 개의 샤드로 쪼갤지 정함, 샤드가 많아지면 클러스터 성능이 떨어지고, 샤드가 적으면 샤드 하나의 크기가 커지기에, 장애 복구에 오랜 시간 걸림 -> 적절한 조치 필요

numbers_of_replicas: 주 샤드 하나당 복제본 샤드를 몇개 둘지, 고가용성 고려

refresh_interval: referesh를 얼마나 자주 수행할 지 지정, refresh 되어야 검색 대상이 된다. 

 

인덱스는 두 개의 정보 단위를 가진다. settings, mappings

 

• 매핑: 문서가 인덱스에 어떻게 색인되고 저장될지 정의
  • 동적 매핑: 엘라스틱서치가 자동 생성해주는 매핑
  • 명시적 매핑: 사용자가 직접 매핑 지정 (권장)

 

필드타입

• 심플 타입: text, keyword, date, 숫자타입
• 계층 구조 지원 타입: object, nested

 

배열: 여러 타입이 혼홥된 배열의 색인은 실패. 한가지 종류 데이터만 색인 가능

 

• object: JSON문서는 필드 하위에 다른 필드를 포함하는 객체 데이터가 담길 수 있다.  내부적으로 평탄화된 키-값 쌍으로 색인됨
  • 이때 평탄화되는 과정이 중요하다. 배열을 구성하는 객체 딩터를 서로 독립적인 데이터로 취급하지 않는다.
• nestd: 배열 내 각 객체를 독립적으로 취급함. 각 객체를 내부적으로 별도의 루씬 문서로 분리해 저장한다. 이러한 동작 방식이 독특하기에 nested 쿼리를 전용으로 이용해서 검색. 각 객체를 별도의 문서로 분리해서 저장하기에, 성능 문제 가능

 

정리하면

• object(default) - 용도: 일반적인 계층 구조, 성능: 가볍다. 검색: 일반 쿼리
• nested - 용도:  배열 내 각 객체를 독립적으로 취급, 성능: 무겁고, 내부 문서로 생성. 검색: 전용 nested 쿼리

 

문자열 타입

• text: 애널라이저가 적용된 후 색인됨. 여러 토큰으로 쪼갬. 텀: 쪼개진 토큰에 지정한 필터를 적용하여 후처리 작업 후 역색인에 들어가는 형태.
  • Hello world -> hello를 검색하면 나옴
• keyword: 쪼개지 않고 역색인을 구성. 간단한 전처리 후 단일 텀으로 역색인을 구성
  • Hello world -> hello를 검색하면 안 나옴

 

애널라이저&노멀라이저

 

애널라이저의 한 종류가 토크나이저. 반대 개념으로 노멀라이져

text 타입과 keyword 타입의 색인 과정. 출처 <엘라스틱 서치 바이블>, 위키북스

match 쿼리: 검색 대상 필드가 text 타입인 경우 검색 질의어도 애널라이저로 분석

 

애널라이저

0개 이상의 캐릭터 필터, 1개이상의 토크나이저, 0개 이상의 토큰 필터로 구성됨

Text Analysis란? 엘라스틱서치에 저장되는 doc는 모든 문자열(text) 필드별로 역인덱스를 생성하여 문자열 field가 저장될 때 데이터에서 검색어 토큰을 저장하기 위해 거치는 모든 단계를 의미

데이터 입력 -> 필터링 -> 토크나이저 -> 토큰 필터

입력 텍스트: 애널라이저는 원본 텍스트 데이터를 입력받음

 

캐릭터 필터(Character Filter)

• 텍스트의 전처리 단계로, 텍스트에서 특정 문자를 수정하거나 제거하는 작업
• ex) 특수 문자를 제거하거나, 대소문자를 변환하는 등의 작업
• 이 단계에서 텍스트는 변형되지만 아직은 하나의 긴 문자열 형태로 남아 있다.

토크나이저(Tokenizer)

• 캐릭터 필터가 적용된 텍스트에서 단어나 문장 등의 단위로 텍스트를 나누는 단계
• 이때 토큰은 단어, 구, 기호 등으로 나누어진다.
• ex) "I love NLP"라는 문장이 있다면, "I", "love", "NLP"라는 세 개의 토큰으로 분리

토큰 필터(Token Filter)

• 분리된 토큰에 대해 추가적인 변형을 가하는 단계
• 불용어 제거(stop words removal), 형태소 분석, 어간 추출(stemming), 표제어 추출(lemmatization) 
• ex) "running"을 "run"으로 바꾸거나, 불필요한 단어를 제거하는 작업

최종 분석 완료된 텀

• 최종적으로 이 모든 단계를 거친 후, 분석된 토큰 스트림이 최종 분석 결과로 반환

 

• 내장 애널라이저로 하고자 하는 것을 하기에 부족하다면 커스텀 애널라이저 사용 가능
• 캐릭터 필터, 토크나이저, 토큰 필터에 적절히 적용하여 자신만의 애널라이저를 만들 수 있다.
• nori, smartcn,kuromoji 을  사용하여 한,중,일 언어를 분석할 수 있다.

 

노멀라이저

 

노멀라이저는 텍스트를 표준화하는 작업을 하며, 캐릭터 필터와 토큰 필터로 구성.

노멀라이저의 목표는 텍스트를 일정한 규칙에 따라 변형하여 최종적으로 단일 토큰을 생성하는 것

• 캐릭터 필터 (Character Filter): 텍스트의 문자 단위에서 변경을 수행
  • ex) 특수 문자를 제거하거나 대소문자를 통일하는 작업을 합니다.
• 토큰 필터 (Token Filter): 분리된 토큰에 대해 변형
  • ex) 불용어를 제거하거나, 어간 추출(stemming), 표제어 추출(lemmatization)을 하는 작업

목표는 단일 토큰을 생성하는 것인데, 이때 글자 단위로 작업을 수행하는 필터만 사용할 수 있다는 점이 중요한 특징

즉, 텍스트 분석을 통해 토큰을 분리한 후, 그 토큰을 표준화하고 처리하는 방식

 

템플릿 (Template)

템플릿은 사전에 정의된 설정을 통해 인덱스가 일관된 방식으로 생성되도록 하는 방법

도커 컴포즈(Docker Compose)와 비슷

• 도커 컴포즈가 여러 개의 컨테이너를 사전 정의된 설정으로 쉽게 배포할 수 있게 해주듯, 템플릿은 인덱스 생성 시 여러 설정을 미리 정의하여, 일관성 있는 인덱스 설정을 자동화

템플릿을 사용하면 기본 설정을 한번 정의해두고, 이후 인덱스가 생성될 때 그 설정이 자동으로 적용되므로, 여러 인덱스에서 동일한 설정을 반복적으로 사용 가능

• 컴포넌트 템플릿 (Component Template): 중복되는 설정을 작은 블록으로 쪼개어 여러 템플릿에서 재사용할 수 있도록 만든 템플
• 레거시 템플릿 (Legacy Template): 이전 버전의 템플릿
• 동적 템플릿 (Dynamic Template): 새로 들어오는 필드에 대해 사전 정의된 매핑 규칙을 자동으로 적용하는 템플릿

 

라우팅

요청을 처리할 때, 특정 샤드(shard)나 인덱스로 데이터를 분배하는 역할

 즉, 클러스터 내에서 데이터가 어디에 저장될지 결정하는 데이터 라우팅을 담당

라우팅 값 기입하지 않으면 전체 샤드 대상으로 검색 수행, 명시하면 단일 샤드 대상으로 검색 수행

• 목적: 요청을 처리할 때 적절한 샤드로 데이터를 라우팅하여 효율적인 검색과 색인을 지원합니다.
• 예시: 특정 문서가 어느 샤드에 있는지 알아내어 그 샤드로 요청을 전달합니다.

 

집계(aggregation)

 

size 0 -> 문서 내용을 반환하지 않고 집계 결과만 받기 위해 사용

집계 작업의 핵심은 집계 연산이다. 검색 쿼리 문서 내용이 핵심이 아니다.

검색 쿼리에서 불필요한 문서들을 반환하지 않기 때문에 시스템의 성능을 최적화 가능

 

집계 작업은 검색 쿼리에 매칭된 모든 문서에 대해 수행 -> 과도한 양이 될 수 있다.

따라서 통제되지 않은 사용자에게 키바나를 열지 말아야 한다. 사용량이 많아졌을 경우의 부하를 생각해야함

 

• 메트릭 집계: 산술 연산
  • avg, max, min, sum
  • stats: count, min, max, avg, sum을 한번에 반환하는 다중 값 숫자 메트릭 집계
  • cardinality: 지정한 필드가 가진 고유한 값의 개수를 계산하여 반환 + precision_threshold 옵션으로 정확도 조절, 최종 cardinality보다 높다면 정확도가 충분하다.
• 버킷집계: 문서를 특정 기준으로 여러 부분집합으로 나눔. 이 부분집합을 버킷이라 한다. 버킷에 포함된 문서를 대상으로 별도의 하위 집계 수행가능
  • 문서 전체에 대해 여러 구간의 버킷으로 분할 하고, 각 버킷에 대한 하위 집계를 수행하는 것이 핵심. 버킷에 버킷에 버킷을 계속 생성 가능하나 적당한 하위 집계 깊이를 지정해야 한다.
  • 엘라스틱서치는 샤드에 집계 요청 분산되어 들어오면 샤드 요청 캐시에 저장하였다가, 동일한 집계요청에 사용한다.
•  range: 지정한 필드값을 기준으로 문서를 원하는 버킷 구간으로 쪼갬. 경계 기준값을 지정
• date_range: date 타입 필드를 대상으로 한 range 집계, now가 포함된 집계 요청은 당연히 캐시되지 않음.
• histogram:   지정한 필드값을 기준으로 문서를 원하는 버킷 구간으로 쪼갬. 버킷의 간격을 지정. interfval, offset
• date_histogram: date 타입 필드를 대상으로 한 histogram 집계. calendar_interval, fixed_interval 사용
• terms: 지정 필드에 대한 가장 빈도수가 높은 term 순서대로 버킷 생성.
• 예를 들어, "카테고리" 필드에서 ["A", "B", "A", "C", "B", "A"]가 있다면, terms 집계는 A, B, C 순으로 가장 빈도 높은 값을 나열

각 샤드에서 size개수만큼 term을 뽑아 빈도수를 세는데, 각 샤드에서 수행된 계산을 한곳으로 모아 합산한후 size 개수만큼 버킷을 뽑는다. 따라서 size 개수와 각 문서의 분포에 따라 그 결과가 정확하지 않을 수도 있다. 

terms 집계는 상위 term을 뽑아서 집계를 수행한다. 전부 순회하여 집계하려면 size를 늘리는 방식보다 composite 집계 사용을 권장

 

• 예를 들어, 3개의 샤드에 데이터가 분산되어 있고, size = 3으로 상위 3개의 term을 뽑는 집계를 요청한다고 가정
• 샤드 1: ["A", "B", "A"]에서 상위 3개 term은 A, B.
• 샤드 2: ["A", "C"]에서 상위 3개 term은 A, C.
• 샤드 3: ["B", "A", "B"]에서 상위 3개 term은 B, A.

각 샤드는 자신이 처리할 수 있는 문서들만 보고 상위 3개 term을 뽑기 때문에, 전체 데이터를 종합한 결과에서 상위 size개의 term이 정확히 반영되지 않을 수 있다.

예를 들어, A가 실제로는 가장 많이 등장했지만, 샤드 2에서는 A가 상위 3개 안에 포함되지만, B는 다른 샤드에서 더 많이 등장하여 최종 집계에서 B가 더 많이 등장하는 것처럼 나타날 수 있다.

 

composite: sources로 지정된 하위 집계의 버킷 전부를 페이지네이션하여 순회

 

파이프라인집계: 다른 집계 결과를 집계 대상으로 한다. bucket_path 인자를 통해 다른 집계 결과를 상대경로로 가지고 와서 사용

ex) "판매액"을 기준으로 카테고리별 판매액 합계를 집계한 후, 그 값을 이용해 카테고리별 판매액의 누적합이나 최대 판매액을 가진 카테고리를 구할 수 있다.

> 하위 집계로 이동, . 하위 메트릭으로 이동

cumulative_sum: 다른 집계 값을 누적하여 합산

max_bucket: 다른 집계 결과로 그 결과가 가장 큰 버킷의 key, 결과를 구하는 집계

{
  "aggs": {
    "daily_sales": {  // 1. 일별 판매 집계 시작
      "date_histogram": {  // 2. 날짜별로 데이터를 그룹화
        "field": "date",  // 날짜 필드를 기준으로 그룹화
        "interval": "day"  // 하루 단위로 집계
      },
      "aggs": {  // 3. 하위 집계 정의
        "total_sales": {  // 4. 각 날짜의 판매액 합계
          "sum": {  // 5. 판매액 필드의 합산
            "field": "sales"  // "sales" 필드의 값을 합산
          }
        },
        "cumulative_sales": {  // 6. 판매액 누적합 집계
          "cumulative_sum": {  // 7. 누적합 계산
            "buckets_path": "total_sales"  // 8. "total_sales" 집계 결과를 사용
          }
        }
      }
    }
  }
}

"date" 필드에 대해 date_histogram을 사용하여 데이터를 일별로 그룹화하고, 그 안에서 각 날짜별 판매액 합계(total_sales)를 구한다.

그런 다음, cumulative_sum을 사용하여 각 날짜별 판매액 합계의 누적합을 계산한다.