Elasticsearch 공부 정리 - 3

개념 정리

1. Analysis

 

• 텍스트 분석(text analysis)이라고도 함
• text field/values에만 적용 가능
• text value는 document를 색인할 때 analysis 적용
• 결과는 검색에 효율적인 자료구조에 저장됨
  • "_source" 키에 매칭 되는 객체에 값들이 색인됨
  • 해당 객체는 document를 색인할 때 값 그대로를 저장
• document를 검색할 때 _source 객체가 사용되지는 않음
  • 앞서 언급했듯이 _source 객체는 document를 색인할 때 값 그대로를 가지고 있음
  • 제품의 설명이 길 경우 전처리 없이는 효율적으로 검색할 수 없기 때문에 _source 객체를 검색할 때 사용하지 않음
  • text는 전처리가 진행된 후 저장이 됨
• 정리하자면 document -> analyzer -> storage 구조
  • analyzer는 character filters, tokenizer, token filters로 구성
• character filters
  • 문자를 추가, 제거 혹은 수정하는 필터
  • analyzer는 0개 이상의 character filter를 가지고 있음 (가지고 있을 수도 있고 없을 수도 있다는 뜻)
  • character filter는 정의한 순서대로 적용됨
  • 예제 (html_strip filter)
    • Input: "I&apos;m in a <em>good</em> mood&nbsp;-&nbsp;and I <strong>love</strong> gudetama!"
    • Output: I'm in a good mood - and I love gudetama!
• Tokenizers
  • analyzer는 하나의 tokenizer를 가지고 있음
  • Tokenizer는 문장을 token 단위로 나눔
  • token 단위로 나누는 과정에서 일부 문자가 제거될 수도 있음
  • 예제 (standard)
    • Input: "I REALLY like beer!"
    • Output: ["I", "REALLY", "like", "beer"]
• Token Filters
  • tokenizer의 아웃풋 즉, 토큰들을 input으로 받음
  • token 필터는 token들을 추가, 제거 혹은 수정할 수 있음
  • analyzer는 0개 이상의 token filter를 가지고 있음 (가지고 있을 수도 있고 없을 수도 있다는 뜻)
  • character filter와 마찬가지로 정의한 순선대로 적용됨
  • 예제 (lowercase filter)
    • Input: ["I", "REALLY", "like", "beer"]
    • Output: ["i", "really", "like", "beer"]
• Built-in and custom components
  • 기본적으로 제공되는 analyzers, character filters, tokenizers, token filters 존재
  • 커스텀하게 만들 수도 있음

 

2. Inverted Indices

 

• field 값은 여러 자료구조 중 하나에 저장됨
  • field의 데이터 타입에 따라 저장되는 자료구조가 결정됨
• 효율적인 데이터 접근을 보장
  • 지정된 용어를 검색하는 것은 데이터를 집계하는 것과 다르게 처리
• elasticsearch가 아닌 Apache Lucene에서 처리
• inverted indices
  • 용어(term)와 해당 용어가 어떤 document에 저장되어있는지를 매핑해주는 자료구조
  • outside the context of analyzers, we use the terminology "terms"
  • 용어는 알파벳 순으로 정렬됨
  • inverted indices는 용어와 document id 외에도 다양한 정보를 저장
    • ex) relevance scoring을 위한 정보도 저장
    • 얼마나 연관이 있는지를 점수로 표현함
  • 각 text field마다 inverted index가 생성됨
  • numeric, date 타입은 BKD 트리를 이용
    • 내부적으로 date가 long 타입으로 저장되기 때문에 numeric과 같은 자료구조로 저장됨
• inverted indices 예시
  • document #1: "2 guys walk into   a bar, but the third... Ducks! :-)"
  • document #2: "2 guys went into a bar"
  • document #3: "2 ducks walked around the lake"

 

Term	Document #1	Document #2	Document #3
2	X	X	X
a	X	X
around			X
bar	X	X
but	X
ducks	X		X
guys	X	X
into	X	X
lake			X
the	X		X
third	X
walk	X		X
went		X

 

3. mapping

 

• document의 구조를 정의
  • ex) 필드와 필드들의 데이터 타입
  • 값이 색인되는 방법을 구성하는 데도 사용.
• 관계형 데이터베이스의 테이블 스키마와 비슷한 개념
• Explicit mapping (명시적인 매핑)
  • 필드 매핑을 직접 정의
  • MySQL에서의 DDL문과 비슷
• Dynamic mapping (동적 매핑)
  • Elasticsearch에서 field mapping을 정의해 줌
  • 상당히 유연하기 때문에 특정 필드에는 명시적인 매핑을 적용하고 나머지 필드에는 동적 매핑을 부여하는 방법을 사용해도 됨

 

4. Overview of data types

 

• object data type
  • json 타입에 사용되는 데이터 타입
  • inner object 존재 가능
  • "properties" 매개변수를 통해 매핑
  • Apache Lucene은 object 타입을 지원 안 하기 때문에 object 타입 그대로 저장 안 됨
    • JSON 타입 객체 색인을 보장하기 위해 object 타입은 변환됨
    • in particular, objects are flatted
    • ex) employee.name, employee.age
    • JSON 배열이라면? 각각의 field가 배열
• nested data type
  • object data type과 비슷하지만 object 관계를 유지한다는 점이 차이점
    • 객체 배열을 색인할 때 유용
  • nested 쿼리를 통해 각각의 객체를 독립적으로 조회할 수 있음
  • nested 객체들은 hidden document로 저장되기 때문에 직접 검색하지 않는 한 보이지 않음
• keyword data type
  • 값이 정확히 일치할 때 사용됨
  • filtering, aggregations, sorting에 사용됨
  • ex) searching for articled with a status of PUBLISHED
  • full-text searches를 진행할 때 keyword data type이 아닌 text data type을 사용하는 것을 추천
    • full-text search는 값이 정확히 일치하지 않아도 되는 검색
    • ex) searching the body text of an article

 

5. How the keyword data type works

 

• keyword 필드는 keyword analyzer에 의해 분석됨
• keyword analyzer는 no-op analyzer
  • 해당 analyzer는 들어오는 문장 그대로를 하나의 토큰으로 만듦
  • 값이 정확히 일치하는 검색에 사용되는 것을 목적으로 만들어짐
  • standard analyzer의 경우 특정 기호들을 배제하고 모두 소문자로 만듦
  • keyword analyzer는 문장 그대로 저장함
  • 적용하면 좋은 사례: email 주소, 신문기사 배포 상태
  • keyword analyzer에 lowercase token filter 적용 가능

 

6. Understanding type coercion

 

• document를 색인할 때 데이터 타입이 검증이 됨
  • 검증이 진행될 때 유효하지 않은 값들은 저장이 안 됨
  • ex) text field에 object data type을 색인하려고 할 때
• 어쩔 때는 잘 못된 데이터 타입을 제공해도 색인이 되는 경우가 있음
• 복습을 하자면 _source 객체는 색인할 때 값 그대로를 저장
  • 명시적 매핑에 의해 price라는 필드 데이터 타입이 float로 정의되어있다고 가정했을 때 
  • 문자열 "7.4"를 제공하더라도 coercion에 의해 7.4 float 타입으로 변환돼서 저장됨 
    • 변환이 되었더라도 _source 객체 내 price에는 7.4가 아닌 "7.4"로 저장되어 있음
  • 검색 쿼리에서는 _source 객체에 저장된 값이 아닌 inverted indices 혹은 BKD 트리 내 값을 이용
  • 정리를 하자면 _source 객체는 값이 어떻게 색인되었는지가 아닌 초기에 제공된 값을 저장
    • _source 객체 내 값을 이용할 때 coercion을 고려해봐야 함
    • 해당 예제에서는 _source 객체 내 price 값이 문자열일 수도 있고 float 타입일 수도 있음
• 추가로 알아야 할 사항
  • integer 타입으로 매핑된 필드에 소수점을 저장하려고 하면 정수로 변환이 돼서 저장됨
  • 동적 매핑에는 coercion이 적용 안됨
  • 항상 올바른 데이터 타입을 사용하는 것을 추천
    
    • 특히, 처음 필드를 색인할 때 올바른 데이터 타입을 저장하는 것이 중요
  • coercion은 디폴트로 활성화가 되어 있는 상태
    
    • 비활성화해서 항상 올바른 type으로 받고 나머지는 error 던지는 게 안전할 듯

 

7. Understanding arrays

 

• 배열 data type은 존재하지 않음
• 모든 field는 0개 이상의 값을 가지고 있을 수 있음
  • 별도 배열 data type이 존재하지 않기 때문에 설정이나 매핑을 지정하지 않아도 됨
  • 문서를 색인할 때 아래와 같이 배열을 제공하면 됨

POST /_analyze
{
    "text": ["Strings are simply", "merged together"],
    "analyzer": "standard"
}

• 두 개의 문자열 사이에 공백을 두고 합쳐진 상태로 inverted indices 생김
• 문자열 필드가 아닐 경우 해당 값은 분석 과정 없이 Apache Lucene이 제공하는 자료 구조 중 적절한 자료 구조에 multiple value로 저장이 됨
• 제약사항
  • 배열 내 값들은 모두 같은 data type이어야 함
  • Coercion은 이미 매핑된 field에만 적용됨
    • 동적 매핑을 통해 필드를 매핑할 경우 배열은 모두 같은 data type을 가지고 있어야 함
  • 개인적으로 coercion 비활성화하는 것을 추천
    • 운영할 때 편의성보다는 불확실성을 배제하는 것이 맞다고 봄
• nested arrays
  • arrays may contain nested arrays
  • arrays are flattend during indexing
  • [1, [2, 3]]은 [1, 2, 3]으로 평탄화 진행됨
• 명심해야 할 점
  
  • 배열 내 값들을 독립적으로 검색하기 위해서는 nested array data type으로 색인해야 함

 

8. How dates work in Elasticsearch

 

• 3가지 타입 중 하나로 표현
  • specially formatted strings
  • Milliseconds since the epoch (long)
  • Seconds since the epoch (integer)
• Epoch는 1970.01.01을 의미
• 커스텀 포맷도 지원
• 3가지 포맷 지원
  • A date without time
  • A date with time
  • Milliseconds since the epoch (long)
• timezone을 명시하지 않으면 UTC timezone으로 간주
• ISO 8601 specification에 맞춰서 날짜를 포맷팅 해야 함
• date field는 아래와 같이 저장되어야 함
  
  • 내부적으로 epoch 이후 경과한 시간을 밀리세컨드 단위로 저장 (long 타입)
  • 색인될 때 내부적으로 long 타입으로 변환해서 저장
  • 날짜는 UTC timezone으로 변환돼서 저장됨
  • 검색 쿼리를 호출할 때도 위와 같은 구조로 진행됨

 

9. Missing fields

 

• Elasticsearch 내 모든 필드는 optional
• 문서를 색인할 때 특정 필드를 누락시켜도 됨
  • 관계형 데이터베이스와 달리 NOT NULL 필드 없음
• 따라서, 검증이 필요한 필드에 대해서는 애플리케이션 레벨에서 진행되어야 함
• 명시적 매핑을 추가한다고 해서 NOT NULL 필드가 되는 것이 아님
• 검색 쿼리는 누락된 필드에 대해서 자동으로 처리함

 

10. Mapping parameters

 

• doc_values parameter 비활성화
  • 디스크 공간을 아끼려면 doc_values 파라미터를 false로 지정
    • false로 지정할 경우 색인 성능도 소폭 증가함
  • aggregations, sorting, scripting을 사용하지 않을 때만 false로 지정
  • 정말 큰 인덱스에 대해서만 유효 (크기가 작은 인덱스에 대해서는 무의미)
  • 새로운 인덱스에 문서들을 재색인 하지 않는 한 설정 변경 불가
    • 적용할 때 주의 필요
    • 사전 검토 필요

• norms parameter
  • 연관도(relevance scoring) 측정할 때 normalization 요소 적용
  • 보통 검색할 때 결과 필터링과 함께 연관도 기준으로 정렬하는 것을 원함
    • 구글 검색 결과 5페이지는 연관성 없는 경우가 있음 (relevance 기준 정렬)
  • 디스크 공간 절약을 위해 norms parameter 또한 비활성화 가능
    • 연관도를 측정하지 않는 필드에 대해서 유용함
    • norms를 비활성화하더라도 필터링과 집계 가능
    • 제품명은 연관도 측정이 필수이므로 norms 활성화 필요
• index parameter
  • 필드 색인 비활성화도 가능
  • 비활성화하더라도 _source 객체에는 저장이 됨
  • 검색 쿼리에 해당 필드를 사용하지 않을 경우 유용함
  • 색인 성능을 소폭 높이고 디스크 공간을 아낄 수 있음
  • 시계열 데이터에 주로 사용됨
  • 색인이 비활성화될 경우 집계 처리 불가 (aggregation 불가)
• null_value parameter
  • null 값은 색인 및 검색 불가능
  • 해당 파라미터는 null 값을 다른 값으로 변환할 때 사용
  • 명시적인 null 값에 대해서만 적용 가능
    
    • 빈 배열을 제공할 때는 적용 불가능
  • 변환하는 값은 정의된 field mapping 타입과 일치해야 함
  • _source 내 저장된 값에는 영향을 주지 않음
• copy_to parameter
  • "group field"에 다수의 field 값들을 복사하기 위해 사용되는 매개변수
  • 복사한 값을 저장할 field명을 명시하면 됨
  • ex) first_name 값과 last_name 값을 -> full_name이라는 값에 복사
  • terms/token은 복사가 안되고 값만 복사됨
  • _source 객체 내 복사된 필드는 저장 안 됨

 

비고. doc_value란?

• Elasticsearch는 다양한 자료구조를 사용함
• inverted indices는 검색에 효율적
• "Doc values"는 Apache Lucene에서 제공한 자료구조
  • 문서를 terms로 변환할 때 효율적인 자료구조
• Essentially and "uninverted" inverted index
• sorting, aggregations, 그리고 scripting에 사용되는 자료구조

 

11. Limitations for updating mappings

 

• 일반적으로 한번 정의된 field 매핑은 변경 불가
• 대신 새로운 field 매핑을 추가 가능
• 일반적으로 field 매핑 설정을 변경할 수 없는 이유는?
  • 기존에 색인된 문서에 문제가 발생하기 때문
  • 문자열 값들은 이미 분석이 되고 저장이 된 상태
  • 매핑 설정을 변경할 경우 전체 자료구조를 다시 빌드해야 하는 상황이 발생할 수도 있음
• 인덱스가 비어있더라도 field 매핑 변경 불가
• field 매핑은 제외도 안됨
  • 위와 같은 효과를 원하면 문서를 색인할 때 해당 필드 제외한 상태로 색인
• field 매핑을 변경하기 위해서는 새로운 인덱스에 기존 문서들을 재색인하는 것이 한 방법

 

Reindex API

• 문서를 재색인하기 전에 스냅샷을 생성
• 버전 충돌이 발생할 경우 쿼리 호출을 중단시킴
• 재색인이 진행되는 인덱스는 비어있지 않아도 됨

 

Batching & Throttling

• Reindex API는 배치로 작업 수행
  • update by query랑 delete by query api도 마찬가지
  • 내부적으로 scroll api 사용
  • scroll api를 통해 몇백만 건의 문서를 재색인하는데 효율적으로 진행
• 성능에 미치는 영향을 제한하도록 Throttling 적용 가능
  • 상용에서 운영되는 클러스터에 유용한 설정

 

12. Index Templates

 

• index template은 설정 정보와 매핑 정보를 명시
• index template은 정규 문법 패턴에 맞는 인덱스들에 적용
  • 와일드카드 패턴도 가능
• index templates은 새로운 인덱스가 생길 때마다 적용
• index 생성했을 때 설정과 index template 설정이 겹치는 경우 index 생성했을 때 부여한 설정이 더 우선순위를 가진다
• 새로운 인덱스는 여러 index template 패턴에 겹칠 수 있음
  • 이럴 경우 order 매개변수를 적용하여 index template 간 우선순위 부여 가능
  • 값은 정수이며 더 낮은 값이 더 높은 우선순위를 가짐
• index templates은 새로운 설정 정보와 매핑 정보로 업데이트 가능
  • 업데이트된 설정/매핑 정보는 새로 생긴 인덱스에 적용
  • 기존에 생성된 인덱스에는 업데이트된 index template 영향 안 끼침

 

13. Elastic Common Schema (ECS)

 

• 자주 쓰이는 공통 필드에 대한 명세서
• ECS 도입 전에는 비슷한 성격을 가지는 필드 이름 간 연관성을 찾을 수 없었음 
  • 예를 들자면, nginx와 apache로부터 받은 log들은 다른 필드명을 가지고 있음
  • ex) apache2.access.url, nginx.access.url
  • 웹 서버를 변경하면 필드 이름이 다르기 때문에 여러 문제를 야기
  • 따라서 ECS를 통해 필드 이름을 동일하게 유지함으로써 키바나가 어떤 웹서버로부터 이벤트가 발생했는지 알 필요가 없도록 처리
• 일반적으로 여러 소스로부터 동시에 데이터를 수집함
  • 예를 들어, postgres 데이터베이스, kafka, nginx, 그리고 redis 클러스터와 같은 서비스로부터 데이터를 수집하는 서비스를 운영하는 것이 일반적
  • 이럴 경우 보통 분당 한 번 이벤트를 처리할 것이고, 처리 완료 시간을 timestamp 형식으로 저장
  • 각 서비스가 필드명을 다르게 지정하는 대신 ECS 규격을 통해 필드명을 @timestamp로 통일
  • 타임스탬프 필드의 이름이 이벤트 소스와 관계없이 동일하기 때문에 데이터를 활용할 때 보다 쉽게 처리 가능
• ECS는 공통 필드에 동일한 이름을 지정
  • ex) 로그 혹은 http 필드 등에 적용
• 필수는 아니고 권장사항

 

ECS의 사용 사례

• ECS에서는 문서를 이벤트라고 칭함
  • ECS는 이벤트가 아닌 문서에 대해서는 명세서를 제공 안 함
  • 사용 사례와 독립적이어야 함 
    • 제품명을 나타내는 필드명을 제공하지는 않음
• 표준 이벤트에 가장 유용
  
  • ex) 웹 서버 로그, 메트릭 정보, 등등
• ECS는 Elastic Stack 제품에 의해 자동으로 처리
  
  • ex) File beats, Logstash
  • ELK 로깅 시스템을 적용할 경우 별도로 ECS에 대한 처리를 할 필요 없음
  • 따라서 ECS는 Elastic Stack 외 다른 시스템을 구축할 때 유용.

 

14. Dynamic Mapping

 

JSON	ELASTICSEARCH
string	아래 중 하나 * text field with keyword mapping * date field * (float or long field)
integer	long
floating point number	float
boolean (true/false)	boolean
object	object
array	Depends on the first non-null value

 

• 동적 매핑을 false로 설정하는 경우
  • 명시적 매핑이 정의되지 않은 필드가 들어와도 됨
    
    • 색인이 되지는 않지만 _source 객체 내 저장은 됨
    • 해당 필드에 대해서는 nverted index가 생성되지 않음
    • 색인되지 않기 때문에 해당 필드에 대해 검색 쿼리를 호출하더라도 결과가 안 나옴
  • 매핑이 정의되지 않을 경우 색인이 되지 않음
    • 동적 매핑이 활성화되어 있을 때는 정의되어 있지 않은 필드에 대해 동적 매핑이 적용된 후 색인 진행
  • false일 경우 색인을 위해서는 새로운 필드에 대해서 명시적 매핑이 필요

 

• 동적 매핑을 strict로 설정할 경우
  • elasticsearch는 매핑되지 않은 필드가 들어올 경우 색인 및 저장 안 되도록 처리
    • 모든 필드에 대해 명시적 매핑 적용 필요
    • 관계형 데이터베이스와 비슷하게 동작
  • 특정 필드에만 동적 매핑 설정 부여 가능

 

• mapping dynamic template 부여 가능

 

• index templates vs dynamic templates
  • index template는 정규 문법 표현식에 매칭 되는 신규 인덱스에 대해 인덱스 설정 및 매핑 적용
  • dynamic template는 새로운 field에 적용
    • 동적 매핑이 활성화되어있을 때 가능

 

15. Mapping 설정 적용할 때 추천

 

• 동적 매핑은 편의성을 제공하지만 실제 운영 환경에서 적용하는 것은 추천하지 않음
• 많은 문서를 저장할 때는 최적화된 매핑 설정을 적용하여 디스크 공간을 아끼는 것을 추천
• 동적 매핑 설정을 "strict"로 설정함으로써 예상치 못한 결과를 방지
• 문자열을 항상 text와 keyword 둘 다 매핑할 필요 없음
  • 보통 둘 중 하나만 필요함 
  • 각각 매핑할 때마다 디스크 공간이 필요하므로 하나만 매핑하는 것을 추천
  • 정확히 일치하는 검색 그리고 집계, 정렬 혹은 필터링이 필요한 것에 대해서는 keyword
  • full-text 검색에 대해서는 text 매핑
• coercion 비활성화함으로써 알맞은 data type만 저장되도록 처리하는 것을 추천
• numeric 데이터는 기본적으로 long data type이 적용되는데 범위가 21억 미만이라면 디스크 공간을 아끼기 위해서는 integer 데이터 타입 부여하는 것을 추천
• 소수점 데이터는 기본적으로 double 데이터 타입이 적용되는데 경우에 따라서는 float 데이터 타입으로도 충분할 수 있음
  • double은 보다 정확도가 높지만 디스크 공간을 두배로 차지함
  • 보통 float만으로도 충분
• 정렬, 집계, 혹은 scripting이 필요 없을 경우 doc_values를 false로 지정
• 연관도 점수가 필요 없는 경우 norms를 false로 지정
• 값에 대한 필터링이 필요 없을 경우 index를 false로 지정
  • index를 false로 지정하더라도 집계는 여전히 가능 (aggregation)
• 위와 같은 고민은 많은 문서를 저장할 때만 고려
  • 비교적 적은 양의 문서를 저장하는 경우에는 위와 같은 고민을 하는 것이 오버 엔지니어링일 수 있음

 

16. Stemming & stop words (영어에 적용되므로 별도로 번역 안 함)

 

• stemming reduces words to their root form
  • E.g. loved -> love and drinking -> drink
  • I loved drinking bottles of wine on last year's vacation. -> I love drink bottl of wine on last year vacat.
  • Stemming is just something elasticsearch uses internally, so no one is going to actually see these terms
• stop words are words that are filtered out during text analysis
  • common words such as "a", "the", "at", "of", "on", etc
• they provide little to no value for relevance scoring
• fairly common to remove such words
  • less common in elasticsearch today than in the past
    • the relevance algorithm has been improved significantly
• not removed by default, and I generally don't recommend removing stop words
• specifying the "keyword" analyzer is a trick to avoid removing stop words from the query, because we actually wnat to know if the document contains "that"

 

17. Built-in Analyzers (기본적으로 제공되는 Analyzer... 한국어는 제공 X)

 

• standard analyzer
  • splits text at word boundaries and removes punctuation
    • done by the standard tokenizer
  • lowercases letters with the lowercase token filter
  • contains the stop token filter (disabled by default)
  • ex) "Is that Peter's cute-looking dog" -> ["is", "that", "peter's", "cute", "looking", "dog" ]
• simple analyzer
  • similar to the standard analyzer
    • splits into tokens when encountering anything else than letters
  • lowercases letters with the lowercase tokenizer
    • unusual and a performance hack
  • ex) "Is that Peter's cute-looking dog" -> ["is", "that", "peter", "s", "cute", "looking", "dog"]
• whitespace analyzer
  • splits text into tokens by whitespace
  • does not lowercase letters
  • ex) "Is that Peter's cute-looking dog?" -> ["Is", "that", "Peter's", "cute-looking", "dog?"]
• keyword analyzer
  • No-op analyzer that leaves the input text intact
    • it simply outputs it as a single token
  • used for keyword field by default
    • used for exact matching
  • ex) "Is that Peter's cute-looking dog?" -> [ "Is that Peter's cute-looking dog?" ]
• pattern analyzer
  • a regular expression is used to match token separators
    • it should match whatever should split the text into tokens
  • this analyzer is very flexible
  • the default pattern matches all non-word characters (\W+)
  • Lowercases letters by default
  • ex) "Is that Peter's cute-looking dog?" -> ["is", "that", "peter", "s", "cute", "looking", "dog"] 
• Language Analyzers
  • 한국어는 지원하지 않는다...

 

 

오픈소스 한국어 형태소 분석기

• 노리
• 아리랑
• 온전한닢
• 등등

 

https://esbook.kimjmin.net/06-text-analysis/6.7-stemming/6.7.2-nori

6.7.2 노리 (nori) 한글 형태소 분석기 - Elastic 가이드북

 

 

18. Open & Closed indices

 

• 인덱스가 open 상태일 때 색인과 검색 가능
• 인덱스가 close 상태일 때 요청이 거절됨
  • 읽기/쓰기 요청들은 거절됨
  • 몇몇의 작업을 진행할 때 close 상태로 진행해야 함
• 인덱스를 열고 닫는 과정은 비교적 빠르게 진행이 되지만 운영 환경에서는 조심스럽게 접근할 필요 있음
  • ex) 절대 다운되면 안 되는 시스템에서는 불가
• 찰나의 순간도 다운되면 안 되는 인덱스에 대해서는 새로운 인덱스를 생성하고 재색인을 진행하는 방법 적용
  • 업데이트된 설정을 적용한 새로운 인덱스 생성
  • 인덱스 alias를 적용하여 전환
  • 기존 문서들 재색인

 

dynamic and static settings

• 동적 설정의 경우 인덱스를 닫지 않아도 변경 가능
• static 설정의 경우 변경하기 위해서는 먼저 인덱스를 닫아야 함
  • 다시 인덱스를 열어줄 때까지 사용 불가
• analyzer 설정은 static 설정이기 때문에 analyzer를 변경하기 위해서는 downtime이 불가피

 

출처

Udemy (elasticsearch-complete-guide)