You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
여기선 주로 사용하는 1번과 2번에 관련된 내용만 정리할 예정이며 나머지는 참고 항목의 Webinar 에서 자세히 알아볼 수 있음
1. Searchable Snapshots & Data tiers
Searchable Snapshots?
7.10 이전엔 S3, HDFS 등과 같은 저장소에 클러스터 Snapshot를 백업해놓고 있다가,
다시 검색에 적용하려면 해당 Snapshot 으로부터 인덱스를 클러스터로 다시 복구해야 함.
7.10 에선 스냅샷에 쿼리를 날릴 수 있는 Searchable Snapshots 기능을 지원함 (Beta)
이 때 Searchable Snapshots 기능을 사용하면 오래된 데이터를 다시 노드로 복구할 필요 없이 바로 스냅샷에 쿼리를 날릴 수 있음
Data tiers
일반적으로 저장기간 등의 기준에 따라 Hot / Warm / Cold / Frozen (예정) 과 같은 Tier 로 나누어 데이터를 관리하며,
오래된 데이터일수록 ES 노드에 색인 상태로 두기 보다는 HDFS 와 같은 저장소로 옮겨서 저장해놓는 경우가 많음.
Hot: 데이터 색인과 검색이 빈번히 이뤄짐. 고성능 필요
주로 SSD 사용
Primary, Replica shards 모두 클러스터 내 저장됨
Warm: 데이터 색인은 없으나 검색은 종종 실행됨. Hot 에 비해 상대적으로 저성능도 가능
HDD 를 사용하는 경우가 많음
Primary, Replica shards 모두 클러스터 내 저장됨
Cold: 데이터 색인이 없고 검색이 아주 가끔 있음
Primary shards 는 클러스터에 저장
Replica shards 는 S3 같은 곳에 Snapshot으로 저장한 뒤 필요시 불러와서 사용하는 구조
Frozen (예정): 데이터 색인이 없으며 검색도 거의 없음
Shards 가 클러스터에 있는것이 아닌 모두 S3 등에 Snapshot 으로 저장되며, 필요시 불러와 사용하는 구조
ILM (Index Lifecycle Management) phase 가 동작할 때 7.10 이전에는 elasticsearch.yml 파일 내 node.attr 에 명시한 값을 참조해서 사용했음.
그러나 7.10 부터는 data_hot, data_warm, data_cold, data_frozen (예정) 과 같은 새로운 노드 역할이 직접 정해지며, ILM phase 에서도 자동으로 매칭되는 역할의 노드로 allocate 됨.
ex) Warm phase 의 데이터는 자동으로 data_warm 노드로 배치
Searchable Snapshots 이 적용되는 경우
위에서 언급한대로 Cold tier 인 경우 Primary shards 만 Cluster 에 보관하고, Replica shards 는 S3 와 같은곳에 Snapshot 을 보관함.
그런데 이 때 Primary shards 에 문제가 생기면 일반적인 복구 케이스처럼 Replica 로 부터 데이터를 복구한 뒤 검색이 이뤄지는 것이 아닌, Replica shards 자체에 검색을 수행하게 되는 Searchable Snapshots 기능이 동작함.
이렇게 동작할 수 있는 이유는 바로 클러스터에 Replica shards 를 일부 캐싱해두고, 필요한 경우 비동기적으로 Snapshot 과 sync 를 맞추기 때문에 검색이 가능한 것이며, 이 작업들은 스냅샷 전체를 복구하는 것 보다 훨씬 빠르게 이뤄짐.
2. Elastic Stack 의 새로운 기능
Kibana 7.10
UI 가 직관적으로 변경 및 탐색 간소화
Kibana navigation 기능 도입
검색창에 필요한 메뉴, 대시보드 이름 등을 검색하여 바로 접근 가능
Kibana Lens 가 GA (General Available) 로 출시
Lens 는 Drag & Drop 만으로 간단하게 다양한 visualize 를 생성할 수 있는 기능
Dashboard 저장 시 패널별로 Description 을 추가로 적을 수 있게 됨
URL Drilldowns (Beta)
대시보드에서 다른 대시보드 또는 URL 로 현재 Context (설정값, 필터 등) 를 유지한 채 드릴다운 가능
Maps
latitude, longitude 가 자동으로 추가됨
위치 기반으로 alert 가능 (Beta)
Alerting
Jira, IBM Resilient connector 추가
Roll based access control 적용
Connector 테스트 기능 추가
UI 개선
Security: 안전하지 않은 클러스터인 경우 Warning 팝업 활성화
Saved Object 관리
Space 별 개체 관리가 가능하여 개체간 충돌 방지
Machine Learning: UI 개선
Stack Management UI
UI / UX 개선
작성 가능한 템플릿 미리보기 기능 추가
Ingest pipeline 관리 UI 도입. 파이프라인 생성 편리
Index Management 에 Data Streams 탭 추가
Elasticsearch 7.10
데이터타입 추가
Unsigned 64 bit integer: 정말 큰 범위의 정수로 OS 레지스트리에 유용
Version
SemVer 에 따른 오름/내림 차순 유지. ex) 2.0.0-alpha < 2.0.0 < 2.1.0 < 2.11.1
version 에 따라 Range 필터 가능. ex) v.2.0.1 부터 v.7.4.3 사이의 document
Rate aggregation 추가
date_histogram 내부에서만 사용 가능
기간별 수량 계산에 용이
ex) 일별 근무시간을 기록하고 있을 때, 월 별로 근무시간을 알고 싶은 경우
Histogram 필드 형식에 Min / Max 추가
Histogram datatype 은 7.6 에 도입
Sum, value count, avg 는 7.8 에 도입
Histogram agg 는 7.9 에 도입
Min, Max 는 7.10 에 도입
개선된 엔지니어링을 통한 TCO 절감
7.7
정렬된 인덱스의 composite aggs 성능 개선
GeoTile Grid agg 성능 개선
7.8
512개 이상 샤드의 클러스터에서 aggs 메모리 소모량 감소 (집계 결과 직렬 확장)
7.9
Bucket aggs 의 확장성 개선으로 search.max_buckets 의 디폴트값이 10000 -> 65535 로 증가
Bucket aggs 에 대한 메모리 사용량 계산의 정확도 향상
다중 Bucket aggs 의 메모리 소비 및 성능 향상
7.10
Cardinality agg 의 성능 및 메모리 트래킹 향상
Coordinate node 에서의 aggs 성능 및 메모리 트래킹 향상
date_histogram aggs 향상 (벤치마크 기준 최대 50% 까지)
Bucket aggs 성능 향상
case insensitive 검색
Term, Wildcard, Prefix query 등의 연관된 모든 데이터 형식에 지원됨
예를들어 zip, zIp, zIP, Zip, ZIp, ZiP, ZIp 과 같은 데이터를 검색하는 경우
Elastic 7.10 새로운 기능 살펴보기
여기선 주로 사용하는 1번과 2번에 관련된 내용만 정리할 예정이며 나머지는 참고 항목의 Webinar 에서 자세히 알아볼 수 있음
1. Searchable Snapshots & Data tiers
Searchable Snapshots?
7.10 이전엔 S3, HDFS 등과 같은 저장소에 클러스터 Snapshot를 백업해놓고 있다가,
다시 검색에 적용하려면 해당 Snapshot 으로부터 인덱스를 클러스터로 다시 복구해야 함.
7.10 에선 스냅샷에 쿼리를 날릴 수 있는 Searchable Snapshots 기능을 지원함 (Beta)
이 때 Searchable Snapshots 기능을 사용하면 오래된 데이터를 다시 노드로 복구할 필요 없이 바로 스냅샷에 쿼리를 날릴 수 있음
Data tiers
일반적으로 저장기간 등의 기준에 따라
Hot
/Warm
/Cold
/Frozen (예정)
과 같은 Tier 로 나누어 데이터를 관리하며,오래된 데이터일수록 ES 노드에 색인 상태로 두기 보다는 HDFS 와 같은 저장소로 옮겨서 저장해놓는 경우가 많음.
ILM (Index Lifecycle Management) phase 가 동작할 때 7.10 이전에는
elasticsearch.yml
파일 내node.attr
에 명시한 값을 참조해서 사용했음.그러나 7.10 부터는
data_hot
,data_warm
,data_cold
,data_frozen (예정)
과 같은 새로운 노드 역할이 직접 정해지며, ILM phase 에서도 자동으로 매칭되는 역할의 노드로 allocate 됨.ex) Warm phase 의 데이터는 자동으로
data_warm
노드로 배치Searchable Snapshots 이 적용되는 경우
위에서 언급한대로 Cold tier 인 경우 Primary shards 만 Cluster 에 보관하고, Replica shards 는 S3 와 같은곳에 Snapshot 을 보관함.
그런데 이 때 Primary shards 에 문제가 생기면 일반적인 복구 케이스처럼 Replica 로 부터 데이터를 복구한 뒤 검색이 이뤄지는 것이 아닌, Replica shards 자체에 검색을 수행하게 되는 Searchable Snapshots 기능이 동작함.
이렇게 동작할 수 있는 이유는 바로 클러스터에 Replica shards 를 일부 캐싱해두고, 필요한 경우 비동기적으로 Snapshot 과 sync 를 맞추기 때문에 검색이 가능한 것이며, 이 작업들은 스냅샷 전체를 복구하는 것 보다 훨씬 빠르게 이뤄짐.
2. Elastic Stack 의 새로운 기능
Kibana 7.10
Elasticsearch 7.10
2.0.0-alpha
<2.0.0
<2.1.0
<2.11.1
v.2.0.1
부터v.7.4.3
사이의 documentsearch.max_buckets
의 디폴트값이 10000 -> 65535 로 증가zip, zIp, zIP, Zip, ZIp, ZiP, ZIp
과 같은 데이터를 검색하는 경우ids
,_source
가 있음Data Analysis
참고
The text was updated successfully, but these errors were encountered: