[ 기초부터 다지는 ElasticSearch 운영 노하우] 4장. ElasticSearch 기본 개념
4.1 클러스터와 노드의 개념
ElasticSearch 클러스터 :
여러개의 ElasticSearch프로세스(=노드)들을 하나의 ElasticSearch프로세스 처럼 사용.
-
어느 노드에 API를 요청해도 동일한 응답과 동작을 보장.
-
하나의 노드를 이용해도, 단일 노드로 구성괸 클러스터로 동작.
-
사용자의 요청을 클러스터 단위로 처리.
-
하나의 노드가 죽어도, 다른 노드에서 응답 처리 가능 → 안정성
-
고유한 클러스터명
+UUID
(Universally Unique Identifier)로 노드들을 클러스터링함. -
클러스터 정보 확인
$ curl localhost:9200
{
"name" : "eunsolJos-MacBook-Pro.local", # 노드 이름
"cluster_name" : "elasticsearch", # 클러스터명
"cluster_uuid" : "FHHVK_dITWeUef1Jts8qmQ", # 클러스터UUID (클러스터 생성시 자동 부여)
"version" : {
"number" : "7.13.1",
"build_flavor" : "default",
"build_type" : "tar",
"build_hash" : "9a7758028e4ea59bcab41c12004603c5a7dd84a9",
"build_date" : "2021-05-28T17:40:59.346932922Z",
"build_snapshot" : false,
"lucene_version" : "8.8.2",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
노드 역할
-
마스터(Master-eligible)
-
클러스터 상태, 메타데이터 관리. 반드시 한대 이상.
-
클러스터내 모든 노드 → 현재노드 상태, 성능정보, 가진 샤드의 정보를 마스터 노드에 알림.
-
마스터 노드 → 모든 노드들에게 자신의 상태 보고.
-
위 정보들을 수집/관리 하며 클러스터의 안정성을 확보하는 작업 진행.
-
마스터 노드(Master) & 마스터 후보 노드(Master-eligible)
실제 메타데이터를 관리하는
마스터 노드
는 한개마스터 노드 3개로 구성된 클러스터? 나머지 두갠
마스터 후보 노드
!마스터 노드
&마스터 후보 노드
항상 같은 메타 데이터를 유지해, 장애발생시 중단없는 서비스 가능.
-
-
데이터(Data)
- 사용자의 문서를 실제로 저장.
- 검색요청을 처리해 결과 리턴.
- 처리 하지 못할 경우, 다른 데이터 노드로 요청. (By. 마스터 노드로 부터 받은 클러스터 정보 바탕)
-
인제스트(Ingest)
- 사용자 문서 저장(색인)전 문서내용 사전처리.
- 데이터 노드 저장전 특정 필드값 가공. (사용자요청 → 인제스트 노드 → 데이터 노드)
-
코디네이트(Coordinate)
- 사용자의 요청을 데이터 노드로 전달. + 데이터 노드로 부터 결과를 취합
- 저장/처리는 하지 않는 데이터 노드.
-
하나의 노드에서 모든 역할을 수행 가능
실 서비스시에는 역할에 따라 노드 수를 구성한다.
---- ElasticSearch Cluster --------------------------------------
| |
| ----Node---- ----Node---- ----Node---- |
| | master | | master | | master | |
| | coordinate | | coordinate | | coordinate | |
| ------------ ------------ ------------ |
| |
| ----Node---- ----Node---- ----Node---- |
| | data | | data | | data | |
| | ingest | | ingest | | ingest | |
| | coordinate | | coordinate | | coordinate | |
| ------------ ------------ ------------ |
------------------------------------------------------------------
4.2 인덱스와 타입
인덱스
- 사용자 데이터가 저장되는 논리적인 공간 (in RDBMS 데이터베이스)
- 인덱스 이름은 클러스터 내에서 유일.
- 인덱스에 저장된 문서들은 모든 Data Role 이 포함된 노드에 분산 저장됨.
타입
- 인덱스 안의 데이터를 유형별로 논리적으로 나눈 공간 (in RDBMS 테이블)
- 문서들을 논리적으로 한번더 나눈다는 의미. (테이블 = 타입) 유사.
- doc 로 타입명 권고. (5.x 버전에선 로 시작하는 타입명 사용X)
※ 하나의 인덱스
에는 하나의 타입
만 가질 수 있다. (ElasticSearch 6.x 이후)
-
멀티 타입을 허용하지 않게된 이유?
하나의 인덱스에 서로 다른 타입에서 동일한 이름의 JSON문서 필드 존재 가능.
인덱스 + JSON문서 필드로 조회 → 의도하지 않은 타입의 필드가 조회됨.
ex.
test_index / test_type1 / name필드
test_index / test_type2 / name필드
조회 :
curl -XGET "http://localhost:9200/test_idex/_search?q=name:elasticsearch&pretty"
⇒ 두 타입에서 문서가 조회됨.
4.3 샤드와 세그먼트
샤드
- 인덱스에 색인 되는 문서들이 저장되는 논리적인 공간
세그먼트
-
샤드의 데이터들을 가지고 있는 물리적인 파일
-
불변(immutable)
수정 : 기존 색인된 문서를 update시 버전이 변경됨
삭제 : 기존 문서를 삭제(불용처리)하고 → 동일한 문서id로 새로운 문서를 색인한다.
※ 세그먼트 병합
세그먼트의 불변 특성으로 인해 update/delete 시 불용처리된 세그먼트들이 다수 존재.
⇒ 백그라운드에서 세그먼트 병합 처리를 한다.
-
불용처리된 세그먼트를 디스크에서 삭제
-
여러개의 작은 세그먼트들을 큰 세그먼크로 합침.
⇒ 검색 요청시 접근 파일의 수가 줄어, 적은 비용으로 빠른 응답을 줌
-
문서 저장 과정
- 샤드에 분리 저장(논리) by. 해시 알고리즘
- 색인된 문서는 시스템의 메모리 버퍼 캐시에 저장됨 (검색 불가능)
- refresh 과정 후 (10장)
- 디스크에 세그먼트 단위로 문서가 저장 (검색가능)
노드 & 인덱스 & 샤드 & 세그먼트
: 인덱스 (1:N) 샤드 (1:N) 세그먼트
4.4 프라이머리 샤드와 레플리카 샤드
ElasticSearch 클러스터 서비스의 연속성, 안정성 유지를 위한 필수 작업!
프라이머리 샤드
- 최초 인덱스 생성시 개수 결정. 변경불가. → 중요하고, 어려운작업 (12장)
curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_shards" : 5 }'
- 어떤 문서를 어떤 샤드에 저장? by 해시 알고리즘 (프라이머리 샤드 번호 = Hash(문서ID) % 프라이머리 샤드 개수)
- 만약 프라이머리 샤드의 개수가 변한다면, 문서들의 프라이머리 샤드 번호를 모두 변경해줘야함. 그래서 변경 불가.
레플리카 샤드
- 프라이머리 샤드와 동일한 문서를 가짐
- 사용자 검색 요청에도 응답 가능 → 응답속도 향상
- N번 샤드 장애 → N번 샤드에 저장된 문서 조회 불가 → 레플리카(복제) 샤드를 만들어둠 → 안정성
- 반드시 프라이머리 샤드와 다른 노드에 저장
- 노드 장애 발생 → 해당 레플리카 샤드가 프라이머리 샤드로 변경 → 추가로 레플리카 샤드가 생성
레플리카 샤드 개수는 운영중에도 변경 가능
curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_replicas" : 5 }'
0개로 하면, 존재하던거 모두 제거
검색성능에도 영향
4.5 매핑
매핑 : RDBMS의 스키마와 유사한 개념
- JSON 문서의 키, 형태값을 정의
- 정적매핑 : 미리 정의함
- 동적매칭 : 최초 색인된 문서를 바탕으로 자동으로 매핑(높은편의성)
- 매핑 생성후 문서는 매핑정보에 따라 색인 되어야함. (long타입으로 정의된 필드에 문자열 색인시 에러)
필드 데이터 타입 종류
-
String : text, keyword
-
Numeric : long, integer, short, byte, double, float, half_float, scaled_float
-
Date : date
-
Boolean : boolean
-
Binary : binary
-
Range : integer_range, float_range, long_range, double_range, date_range
-
매핑정보 확인
curl -X GET "localhost:9200/firstindex/_mapping?pretty"
{
"firstindex" : { # 인덱스명
"mappings" : {
"_doc" : { # 타입명
"properties" : {
"필드명" : {
"type" : "text", # text데이터타입의 매핑이 생성
"fields" : {
"keyword" : { # keyword데이터타입의 매핑이 추가로 생성됨
"type" : "keyword",
"ignore_above" : 256
}
}
},
...
}
}
}
}
}
Author And Source
이 문제에 관하여([ 기초부터 다지는 ElasticSearch 운영 노하우] 4장. ElasticSearch 기본 개념), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@agpine12/기초부터-다지는-ElasticSearch-운영-노하우-4장.-ElasticSearch-기본-개념저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)