Elasticsearch 검색 최적화 가이드
본고는 주로 설정(인덱스 차원, 집단 차원 등 포함)을 통해 ES의 조회 성능을 최적화하는 방법을 주목한다.
색인 구성
ES는 기본적으로 각 인덱스에 주 분할 5개와 사본 분할 1개를 할당합니다.이러한 배치는 모든 업무 장면에 적합하지 않기 때문에 우리는 실제 상황에 따라 배치해야 한다.
물리적 제한 사항
조각의 크기가 조회 효율에 미치는 영향은 매우 크다.만약 색인에 매우 작은 섹션이 많다면, 이 섹션의segment는 너무 빨리 증가하여 결국 제한을 초과하기 쉽다.또한 대량의 작은 분할도 조회의 흡수량에 영향을 줄 수 있다. 왜냐하면 하나의 조회는 모든 분할에서 데이터를 얻기 때문이다.
다른 한편, 너무 큰 조각도 검색 성능에 영향을 주고 복구에 실패할 때 시간이 더 오래 걸린다.ES 공식 권장 단일 분할 크기는 20GB~40GB입니다.예를 들어, 만약 당신이 인덱스가 대략 300GB의 데이터량이라고 평가한다면, 9~15개의 메인 섹션을 나누는 것은 좋은 생각입니다.만약 당신의 집단이 10개의 노드가 있다면, 10개의 분편을 분배하는 것을 고려할 수 있다. 이렇게 하면 주요 분편이 각 노드에 고르게 분포할 수 있다.
지속적인 데이터 흐름
만약 데이터가 끊임없이 기록된다면, 시간 차원의 인덱스 (예를 들어 매일 하나의 인덱스) 를 사용하는 것은 좋은 생각이다.이렇게 하면 일정 시간에 쓴 토출량에 변화가 있으면 우리는 특정한 시간 차원의 색인을 쉽게 단독으로 설정할 수 있다.
만약 시간 차원으로 색인을 만든다면, 검색할 때 어떻게 여러 색인에서 데이터를 검색합니까?답은 색인 별명을 사용하는 것입니다.우리는 별명으로 여러 시간 차원의 색인을 연결한 다음 검색할 때 이 별명을 사용하여 검색할 수 있다.그러나 별명이 너무 많은 색인을 연결하면 성능에 영향을 미칠 수 있기 때문에 성능 문제에 주의해야 한다.예를 들어 집단 설정이 허용된 상황에서 월 단위의 색인을 만들 수 있다면 주 단위의 색인을 만들지 마라.
색인 정렬
일종의 응용 장면은 최근에 발생한 일만 주목하는 것이다.ES에는 이러한 장면을 지원하는 메커니즘이 있습니다.문서는segment 안에 질서가 있습니다. 우리는 전부가 아니라 앞의 일부 문서에만 관심을 갖습니다.ES는
track_total_hits
라는 속성이 있는데 false로 설정하여 ES가 관련성 조회를 할 때 최근의 일부 문서에만 관심을 가지게 함으로써 연합 조회 장면의 효율을 높일 수 있다.분할 최적화
분할은 분포식 디자인 구조를 채택하여 수평 확장을 지원한다.두 가지 유형의 필름이 있는데 하나는 메인 필름이 읽기와 쓰기를 책임지는 것이다. 예를 들어 index,reindex,delete 등 조작이다.또 하나는 부본 분할인데 높은 가용성과 읽기 삼키는 능력을 향상시키는 역할을 한다.
조각의 크기,segment 크기와 한 노드에 몇 개의 효과적인 조각을 저장해야 하는지는 조각 최적화에 고려해야 할 문제이다.
사본 분할은 검색 능력을 향상시키는 데 매우 중요하며, 사본 분할의 수량도 주목해야 할 문제이다.일반적으로 슬라이스 총량은 노드 수의 1.5 ~ 3배를 권장합니다.일반적으로 노드의 분할이 적을수록 파일 시스템 캐시는 노드 사이에서 우위를 발휘할 수 있다.
데이터 손실을 원하는 사람이 없기 때문에 먼저 고장이 발생한 최대 노드 수를 계산해야 한다.그리고 색인의 주 분할 수와 노드 수에 따라 복사본 분할 수의 유효한 분포를 계산하여 비교적 큰 흡수량을 얻는다.
ES 구성
ES 클러스터에서 가장 중요한 구성 중 하나는 최소 절반의 물리적 메모리를 파일 시스템 캐시에 남겨 두는 것입니다. 이것은 ES 핫스팟 인덱스의 저장 위치입니다.
사용 가능한 메모리 더미도 고려해야 합니다. ES는 메모리 더미에 최대 20분/GB를 추천합니다.예를 들어 30GB 메모리의 노드는 최대 600개의 조각만 포함하여 ES가 비교적 건강한 상태를 유지하도록 해야 한다.
그러면 사용된 디스크 공간의 계산 공식은 다음과 같습니다.
20 * (Heap Size per GB) * (Size of Shard in GB)
일반적으로 단일 슬라이스 크기는 20~40GB이므로 16G 더미 메모리 하나로 최대 12TB의 디스크 공간을 지원할 수 있습니다.
이러한 제한에 주목하면 우리는 더욱 좋은 디자인 집단과 미래를 기획할 수 있다.
Dynamic Settings
동적 설정
시간 기반 인덱스를 사용하여 데이터를 관리하는 것이 좋습니다. 일부 시간이 비교적 긴 인덱스는 쓰기 수요가 없으면 읽기 전용으로 설정하여 성능을 향상시킬 수 있습니다.
읽기 전용 인덱스는
force merge
인덱스의segment 수량을 줄여 검색 성능을 향상시킬 수 있습니다.그러나 업데이트가 필요한 인덱스에서 이 동작을 사용하지 마십시오. 그렇지 않으면 큰 segment를 만들 수 있습니다.그리고 force merge
이 작업은 업무 저절정기에 진행해야 한다. 왜냐하면 이것은 매우 많은 시간을 소모하기 때문이다. (주로 I/O)캐시도 가능합니다. 캐시는 최종 사용자의 사용 사례에 사용할 수 있습니다.The preference setting can be used to optimize the usage of the caches since it will allow analyzing a narrower subset of the index.
설정
bootstrap.memory_lock=true
을 통해 메모리 교환을 금지할 수 있습니다.메모리 교환은 쓰레기 회수가 비교적 느릴 수 있다.(설명: 이 설정의 의미는. 물리적 메모리 주소를 잠그고 es메모리가 교환되는 것을 방지합니다. 즉, es가 swap 교환 구역을 사용하지 않도록 하는 것입니다. 빈번한 교환은 IOPS를 높일 수 있습니다)활발한 색인에서 리셋 간격은 계속 증가합니다.활발한 색인은 데이터가 계속 기록되고 있다는 것을 의미한다.기본 리셋 시간은 1초입니다. 즉, ES는 1초마다segment를 생성합니다.서로 다른 업무 장면에 따라 이 값을 조정할지 여부를 결정할 수 있다. 조정은 비교적 큰segment가 생성되는 것을 의미하기 때문에merge의 압력을 줄일 수 있다.
index.merge.scheduler.max_thread_count
의 기본 설정은Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))
이 값은 병렬된merge 스레드 수를 제어합니다. 만약 저장소가 병렬 성능이 좋은 SSD라면 시스템의 기본 설정을 사용할 수 있습니다. 일반 디스크는 1입니다.
ES는 때때로 집단의 노드 사이에서 조각을 다시 균형 있게 하는데 이 조작은 조회의 성능에 영향을 줄 수 있다.
cluster.routing.rebalance.enable
을none
로 설정하여 이 기능을 닫을 수 있습니다.시간 범위를 바탕으로 하는 조회는 현재 시간을 매개 변수로 해서는 안 된다. 왜냐하면 현재 시간은 계속 변화하기 때문에 ES는 이 조회 결과를 캐시할 수 없기 때문에 조회 성능을 향상시킬 수 없다.
초기 설정
자주 조회하는 일부 필드는
copy-to
기능을 사용하여 이 필드를 한데 조합하여 조회 성능을 향상시킬 수 있다.예를 들어 자동차의 상표 명칭, 엔진 버전, 모델, 색깔을 한데 조합할 수 있다.대부분의 상황에서 집단 중의 노드에 있는 분할의 분배는 같지만 때때로 일부 노드 하드웨어의 성능이 비교적 좋아서 분할의 무게를 높여야 한다.기본 가중치는 0.45f입니다.
cluster.routing.allocation.balance.shard
를 통해 이 권한을 설정할 수 있습니다.(Elasticsearch는 Allocation Decider를 위반하지 않는 한 클러스터 각 노드의 조각 수가 비슷할 수 있도록 합니다.)
검색 자체도 응답의 지연 시간에 영향을 줄 수 있다.(예를 들어 조회한 데이터가 너무 많음) ES는 용단 메커니즘이 있습니다. 매개 변수
indices.breaker.total.limit
를 통해 제어합니다. 이 값은 조회가 JVM 메모리의 백분율을 얼마나 차지하는지 결정합니다. 기본값은 70%입니다.ES 기본값은 주요 응용 장면이 검색이라고 가정합니다.병발 능력을 높이기 위해 검색된 스레드 탱크 설정은 향상되어야 하고, 쓴 스레드 탱크는 낮출 수 있다.물론 노드의 CPU 코어 수를 참조해야 합니다.
우리는 순환 방식 (round-robin) 을 대체하기 위해 데이터 복사본에 요청을 보낼 수 있는 적응 복사본 선택을 사용할 수 있습니다. 이것은 조정 노드가 다음과 같은 표준을 바탕으로'최적'으로 여겨지는 복사본에 요청을 보낼 수 있도록 합니다.
1. 노드와 데이터 사본을 포함하는 노드 사이의 과거 요청 응답 시간을 조정한다
2. 과거의 검색 요청은 데이터가 포함된 노드에서 실행되어야 한다
3. 데이터가 포함된 노드의 검색 스레드 탱크의 대기열 크기
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Embulk를 사용하여 ElasticCloud로 보내기Embulk에서 ElasticCloud에 보낼 수 있을까라고 생각비망록도 겸해 기술을 남깁니다 Embulk 설치 ElasticCloud (14 일 체험판) brew라면 아래 명령 입력 파일 만들기 파일 내용 seed...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.