서비스 출시를 위한 초기 데이터 세팅이나 마이그레이션, reindex 를 통한 인덱스 재생성 등 대량 색인이 필요할 때가 있습니다. 이런 경우에는 색인 도중 데이터를 조회할 필요가 없다. 따라서 다음과 같은 설정을 통해 색인 속도를 높일 수 있습니다. PUT my_index/_settings { "refresh_interval" : "-1", "number_of_replicas" : 0 } refresh를 끄고 복제본 샤드 개수를 0으로 지정해서 복제본 생성을 중지하는 설정이다. 작업이 끝나면 원래 설정으로 복구하는 것을 잊지 않아야 한다.

개요 Elasticsearch 와 같은 분산형 시스템을 다룰 때 동시성 때문에 문제가 생길수 있습니다. Elasticsearch는 어떻게 동시성 문제를 제어하는지에 대해 알아볼겁니다. 그 이전에 동시성 문제가 무엇인지 알아야합니다. 동시성 제어는 여러 클라이언트나 요청이 동시에 Elasticsearch 클러스터에 접근하거나 쓰기 작업을 수행할 때 데이터 무결성을 유지하고 성능을 최적화하기 위해 사용되는 중요한 개념입니다. 인덱스 동시성 - 여러 클라이언트가 동시에 같은 인덱스에 데이터를 쓰려고 할때, Elasticsearch 는 쓰기 작업을 조정하여 데이터 무결성을 보장합니다. 검색 동시성 - 많은 클라이언트가 동시에 검색을 실행할 때, Elasticsearch 는 검색 요청을 효율적으로 처리하기 위해 ..

ES Version : 7.12 kibana : 7.12 요건 : 핫 노드에서 웜 노드로 하루 주기 설정하여 이동 및 read_only 설정했을때와 안했을때의 차이점 현재 핫 노드에서 한달 주기로 저장된 인덱스를 웜 노드로 이동시키고 있습니다. 단지 테스트를 위해서 하루 주기로 변경하였습니다. 대략 한달 된 인덱스 xxxx_2023.08 의 데이터는 하루 대략 2천만건 씩 쌓여서 한달에 대략 6억건 정도가 쌓입니다. 용량으로는 7기가에서 8기가 사이 정도가 됩니다. 요구사항 : 처음 핫웜 아키텍쳐를 도입할때, 고객사에서 한달이 지난 데이터 즉, 웜노드에서도 드물게 읽기 및 검색 외에 업데이트를 원하였습니다. index.lifeCycle management 에서 read_only를 기본설정으로 해놓았기때문..