ES 인덱스의 과정은 상대적으로 Lucene의 인덱스 과정까지 분포식 데이터의 확장이 많은데 이 ES는 주로tranlog로 각 노드 간의 데이터 균형을 이룬다.그래서 색인 설정을 통해 첫 번째 최적화를 할 수 있습니다. "index.translog.flush_threshold_ops": "100000〃"index.refresh_interval":"-1〃, 이 두 매개 변수의 첫 번째는tranlog 데이터가 몇 개에 달하는지 균형을 잡는 것이다. 기본값은 5000이다. 이 과정은 상대적으로 시간과 자원을 낭비하는 것이다. 그래서 우리는 이 값을 좀 크게 조정할 수 있다. 아니면 -1로 닫아서 수동으로 tranlog 균형을 잡을 수 있다. 두 번째 매개 변수는 리셋 주파수이다. 기본값은 120s이다. 인덱스가 생명주기 내에 정해진 시간에 리셋하는 것을 말한다. 그러나 데이터가 들어오면 루틴에서commit처럼 리셋할 수 있다.우리는 데이터addDoucment가 커밋을 해야 데이터를 검색할 수 없다는 것을 알고 있기 때문에 그것을 닫을 수 있습니다. 최초 인덱스가 끝난 후에 수동으로 refresh를 한 다음에 인덱스 setting에 있는 index를 닫을 수 있습니다.refresh_interval 매개 변수는 수요에 따라 수정하여 색인 과정의 효율을 높일 수 있습니다.또한 ES 인덱스 과정에서 복사본이 존재하면 데이터도 즉시 복사본에 동기화됩니다.저는 개인적으로 색인 과정에서 복사본 수를 0으로 설정하고 색인이 완성된 후에 복사본 수를 수요량에 따라 바꾸는 것을 건의합니다. 이렇게 하면 색인 효율을 높일 수 있습니다."number_of_replicas": 0에서 색인 과정의 최적화를 이야기한 후에 검색 속도가 비교적 느린 문제를 다시 한 번 이야기합시다. 사실 검색 속도의 속도는 색인 품질과 매우 큰 관계가 있습니다.색인 품질의 좋고 나쁨은 많은 요소와 관련이 있다.1. 편수 편수, 검색 속도와 매우 관련된 지표로 편수가 너무 적거나 많으면 검색이 느릴 수 있다.분할 수가 너무 많으면 검색할 때 비교적 많은 파일을 열 수 있고 그 외에 여러 서버 간의 통신도 초래할 수 있다.반면 분할 수가 너무 적으면 단일 분할 인덱스로 유도하기 때문에 검색 속도가 느리다.분할 수를 확정하기 전에 단일 서비스 단일 인덱스 단일 분할 테스트를 해야 한다.예를 들어 제가 이전에 IBM-3650의 기계에서 색인을 만들었는데 이 색인은 하나의 조각만 있고 각각 다른 데이터 양의 상황에서 검색 속도 테스트를 했습니다.마지막으로 단일 조각의 내용은 20G로 측정되었다.그래서 인덱스 편수 = 데이터 총량/단편수 현재 우리의 데이터량은 4억여 개이고 인덱스 크기는 1.5T 정도에 가깝다.문서 데이터이기 때문에 단일 데이터가 8K 이전에 사용됩니다.현재 검색 속도는 100ms 이하입니다.특별한 상황은 500ms 이하, 20040080010001000+ 사용자의 장시간 병발 테스트를 할 때 최악은 750ms 이하이다.2. 던전수 던전수는 색인의 안정성과 비교적 큰 관계가 있다. 어떻게 보면 ES가 비정상적으로 끊기면 조각을 잃어버리는 경우가 많다. 이런 데이터의 완전성을 확보하기 위해 던전을 통해 이 문제를 해결할 수 있다.인덱스를 작성한 후 Optimize를 실행한 후 바로 복사본 수를 조정하는 것을 권장합니다.여러분은 자주 오류가 있는 던전이 많을수록 검색이 빨라진다. 이것은 옳지 않다. 던전은 검색 속도에 대해 다른 것은 줄고 늘지 않는 것을 제가 실현한 적이 있다. 던전의 수가 증가함에 따라 검색 속도가 미량으로 떨어질 수 있기 때문에 여러분은 던전의 수를 설정할 때 균형치를 찾아야 한다.또한 복사본을 설정한 후에 두 번의 같은 검색이 발생하고 다른 값이 나타날 수 있습니다. 여기는 Tranlog가 균형이 없거나 분할 루트의 문제로 통과할 수 있습니까?preference=_primary는 메인 섹션에서 검색을 진행합니다.3. 분사는 사실 분사가 색인에 미치는 영향은 크지만 작으니 스스로 파악해야 한다.모두들 어고가 많을수록 분사 효과가 좋고 색인의 질이 좋다고 생각할지도 모르지만, 사실은 그렇지 않다.분사에는 많은 알고리즘이 있는데 대부분 어표를 바탕으로 분사를 한다.즉, 어휘표의 크기가 색인 크기를 결정한다.그래서 분사와 색인 팽창률은 직접적인 연결이 있다.어휘표가 많아서는 안 되고 문서와 관련된 특징성이 강한 것은 된다.예를 들어 논문의 데이터는 색인을 만들고 단어를 나누는 어휘표와 논문의 특징이 비슷할수록 어휘표의 수량이 적기 때문에 전체 검사를 정확하게 하는 상황에서 색인의 크기를 많이 줄일 수 있다.색인 크기가 줄어들면 검색 속도도 높아진다.4. 색인 세그먼트 색인 세그먼트는 루틴의segments 개념이다. 우리는 ES 색인 과정에서refresh와tranlog가 있다는 것을 알고 있다. 즉, 우리가 색인 과정에서segmentsnumber는 하나도 없다.한편, segmentsnumber는 검색과 직접적인 관계를 가진다. segmentsnumber가 많을수록 검색이 느리고, segmentsnumbers가 가능한 경우 1로 보증하면 검색 속도의 절반 가까이를 언급할 수 있다. $curl -XPOST ‘ http://localhost:9200/twitter/_optimize? max_num_segments = 1′5, 문서 삭제 문서 삭제 Lucene에서 문서를 삭제하면 데이터가 바로 하드디스크에서 제거되지 않고 Lucene 인덱스에 들어가서 하나가 생성됩니다.del의 파일은 검색 과정에서 이 부분의 데이터도 검색에 참여하고 루틴은 검색 과정에서 삭제되었는지 여부를 판단합니다. 삭제되면 필터합니다.이렇게 하면 검색 효율도 떨어질 것이다.문서 삭제를 지울 수 있습니다. $curl -XPOST ‘ http://localhost:9200/twitter/_optimize? only_expunge_deletes =true
 
 
 

$ curl -XPOST 'http://localhost:9200/twitter/_optimize'

 

인덱스 최적화 관리

optimize API는 API를 통해 하나 이상의 인덱스를 최적화할 수 있습니다.최적화 과정의 조작은 기본적으로 최적화된 색인 검색 속도가 더 빠르다. (Lucene 색인에 저장된 조각의 단수와 관련된다.)최적화 작업은 감소된 단수를 허용하고 그것들을 합친다.
 

$ curl -XPOST 'http://localhost:9200/twitter/_optimize'

 
 
 
 
 
이름 설명
max_num_segments
단수 최적화.색인을 전면적으로 최적화하려면 이것을 로 설정하십시오1 .기본 설정은 통합을 실행해야 하는지 확인하기만 하면 됩니다. 만약 그렇다면, 그것을 실행합니다.[테스트를 거칠수록 속도가 빨라진다.]
only_expunge_deletes
최적화 과정에서 세그먼트 삭제만 지워야 합니다.Lucene에서 삭제되지 않는 파일은 세그먼트에서 삭제로 표시됩니다.지부는 합병 과정에서 삭제되지 않은 새로운 지부를 만듭니다.이 로고는 세그먼트 삭제만 허용합니다.기본값은false .[true docs로 설정해야 통합됩니다.]
refresh
새로 고침 후 최적화하면기본값은true .
flush
씻은 후에 최적화하면기본값은true .
wait_for_merge
신청은 합병이 끝날 때까지 기다려야 한다.기본값은true .합병은 매우 복잡한 작업일 수 있으므로 의미 있게 실행될 수 있습니다 .[false로 설정하면 기본true 요청이 끝날 때까지 그곳에 막힙니다.]
API 호출을 최적화하여 여러 인덱스 또는 모든 인덱스에 적용 가능
 
 

$ curl -XPOST 'http://localhost:9200/kimchy,elasticsearch/_optimize'

$ curl -XPOST 'http://localhost:9200/_optimize'

매개변수 사용 방법:http://localhost:9200/indexName/_optimize?only_expunge_deletes=true&wait_for_merge=false
 
 
 
1. 다중 스레드 프로그램 삽입, 서버 상황에 따라 다중 스레드 index 속도 n배 증가, n>=22.만약 여러 대의 기계가 있다면, 한 대당 n개의shards를 설정하는 방식으로, 업무 상황에 따라repliascurl-XPUT를 취소하는 것을 고려할 수 있습니다http://10.1.*.*:9200/dw-search/'-d'{'settings': {'number_of_shards': 20,'number_of_replicas': 0}'shards 20개를 설정하여 0으로 복사합니다. replicas가 필요하면 index를 완성한 후 replicas>=1로 수정할 수 있습니다.http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index.html 3. ES 점용 메모리의 적당한 크기를 향상시키기 위해 초기에는 256M, 최대 1G, 크기를 조정한 후 최소와 최대로 GC를 피하고 기계 상황에 따라 메모리 크기를 설정합니다. $bin/elasticsearch-f-Xmx4g-Xms4g -Des.index.storage.type=memory 원문:http://www.elasticsearch.org/guide/reference/setup/installation.html 4. shard 새로 고침 간격 줄이기curl-XPUT 'http://10.1.*.*:9200/dw-search/_settings'-d'{'index': {'refresh_interval':'-1'}'bulk 삽입을 완료한 후 초기값curl-XPUT로 수정합니다.http://10.1.*.*:9200/dw-search/_settings' -d '{     "index": {         "refresh_interval": "1s"     } }' 5. shard의 세그먼트 최대 수를 설정하면 세그먼트 파일 수를 줄이고 조회 속도를 높일 수 있습니다curl-XPOST'http://10.1.*.*:9200/dw-search/_optimize?max_num_segments=5'주의: 원문을 여러 번 실행해야 할 때가 있습니다.http://www.elasticsearch.org/guide/reference/api/admin-indices-update-settings.html원문:http://www.elasticsearch.org/guide/reference/index-modules/merge.html 6. 맵핑 제거 중_all 도메인 Index에서 기본적으로 _all의 영역, 이것은 조회에 편리함을 가져다 주지만, 색인 시간과 색인 크기를 증가시킵니다. "_all": {"enabled":false}원문:http://www.elasticsearch.org/guide/reference/mapping/all-field.html curl -XPOST 'http://10.1.*.*:9200/dw-search/pt_normal/_mapping' --data-binary @pt_normal_properties.mapping 7. 소스를 압축 모드나disable compress=true로 설정하면 index의 사이즈를 크게 줄일 수 있습니다.disable는 직접 없습니다_소스 도메인 8.병합 증가.policy.merge_factor 수 설정merge.policy.merge_factor에서 30, 처음에는 10입니다. 이 수를 늘리려면 더 많은 메모리가 필요합니다. bulk index는 이 값을 조정할 수 있습니다.인스턴트 인덱스의 경우 이 값을 원문에서 줄여야 합니다.http://www.elasticsearch.org/guide/reference/index-modules/merge.html