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)
인제스트(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 | |
| ------------ ------------ ------------ |
------------------------------------------------------------------
※ 하나의 인덱스
에는 하나의 타입
만 가질 수 있다. (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"
⇒ 두 타입에서 문서가 조회됨.
샤드의 데이터들을 가지고 있는 물리적인 파일
불변(immutable)
수정 : 기존 색인된 문서를 update시 버전이 변경됨
삭제 : 기존 문서를 삭제(불용처리)하고 → 동일한 문서id로 새로운 문서를 색인한다.
※ 세그먼트 병합
세그먼트의 불변 특성으로 인해 update/delete 시 불용처리된 세그먼트들이 다수 존재.
⇒ 백그라운드에서 세그먼트 병합 처리를 한다.
불용처리된 세그먼트를 디스크에서 삭제
여러개의 작은 세그먼트들을 큰 세그먼크로 합침.
⇒ 검색 요청시 접근 파일의 수가 줄어, 적은 비용으로 빠른 응답을 줌
- 샤드에 분리 저장(논리) by. 해시 알고리즘
- 색인된 문서는 시스템의 메모리 버퍼 캐시에 저장됨 (검색 불가능)
- refresh 과정 후 (10장)
- 디스크에 세그먼트 단위로 문서가 저장 (검색가능)
: 인덱스 (1:N) 샤드 (1:N) 세그먼트
ElasticSearch 클러스터 서비스의 연속성, 안정성 유지를 위한 필수 작업!
curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_shards" : 5 }'
레플리카 샤드 개수는 운영중에도 변경 가능
curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_replicas" : 5 }'
0개로 하면, 존재하던거 모두 제거
검색성능에도 영향
매핑 : RDBMS의 스키마와 유사한 개념
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
}
}
},
...
}
}
}
}
}