Elasticsearch 아키텍처
왜 구조를 배워야 합니까?
Elasticsearch의 일부 구조 설계는 우리가 성능 개선, 고장 처리를 하는 데 매우 중요한 영향을 미친다.다음은 Elasticsearch의 실시간 인덱스 구현, 자동 발견,rounting,replica의 읽기와 쓰기 과정,shard의 allocate 제어
텍스트를 검색할 수 있습니까?
전통적인 데이터베이스에서는 한 필드에 값을 저장하지만 전체 텍스트 검색에 부족합니다.텍스트의 모든 단어를 검색할 수 있도록 하려면 데이터베이스에 여러 개의 값이 필요하다는 것을 의미한다.
한 필드의 여러 값을 지원하는 가장 좋은 데이터 구조는 역렬 인덱스입니다.역렬 인덱스는 모든 문서에 나타나는 유일한 값이나 단어의 시퀀스 테이블과 단어가 속한 문서 목록을 포함합니다.
전통적인 데이터베이스에서는 한 필드에 값을 저장하지만 전체 텍스트 검색에 부족합니다.텍스트의 모든 단어를 검색할 수 있도록 하려면 데이터베이스에 여러 개의 값이 필요하다는 것을 의미한다.
한 필드의 여러 값을 지원하는 가장 좋은 데이터 구조는 역렬 인덱스입니다.역렬 인덱스는 모든 문서에 나타나는 유일한 값이나 단어의 시퀀스 테이블과 단어가 속한 문서 목록을 포함합니다.
역렬 인덱스는 한term을 포함하는 문서 목록보다 많은 정보를 저장합니다. 한term의 문서 수량, 한term이 문서를 작성하는 빈도, 문서마다term의 순서, 문서마다의 길이, 모든 문서의 평균 길이 등을 포함할 수 있습니다.이러한 통계 정보는 Elasticsearch로 하여금 어떤 term이 더 중요하고, 어떤 문서가 더 중요한지, 즉 관련성을 알게 한다.
전문을 검색하기 전에 전체 문서 집합에 큰 색인을 만들고 디스크에 기록합니다.새 색인만 준비되면 낡은 배고픈 색인을 대체할 수 있습니다. 최근의 수정은 검색할 수 있습니다.
불가변성
디스크에 기록된 역렬 인덱스는 변경할 수 없습니다. 다음과 같은 장점이 있습니다.
- 자물쇠가 필요 없어요.만약 새로운 색인을 필요로 하지 않는다면, 여러 프로그램이 동시에 수정을 시도할 것을 걱정할 필요가 없다
- 인덱스가 파일 시스템의 캐시에 읽히면 변하지 않기 때문에 계속 거기에 있습니다.파일 시스템 캐시에 충분한 공간이 있다면, 대부분의 읽기는 디스크가 아닌 메모리에 직접 접근할 것이다.이것은 성능 향상에 도움이 된다..
- 인덱스의 선언 주기 내에 모든 다른 캐시를 사용할 수 있습니다.그들은 더 이상 데이터가 변할 때마다 재건할 필요가 없기 때문에 데이터는 변하지 않을 것이다
- 하나의 큰 역렬 인덱스를 작성하여 데이터를 압축하고 디스크 IO와 캐시 인덱스가 필요한 크기를 줄일 수 있습니다
물론 변하지 않는 색인은 단점이 있다. 우선 변하지 않는 색인이다.새 문서를 검색하려면 전체 인덱스를 재구성해야 합니다.이것은 색인이 설치할 수 있는 데이터를 제한할 뿐만 아니라, 색인이 업데이트될 수 있는 빈도도 제한합니다.
실시간 인덱스의 실현?
본고는 주로 Elasticsearch의 준실시간 인덱스의 실현을 소개하고 있으며, Lucene 기반의 역렬 인덱스는 여기서 소개하지 않습니다. 관심 있는 독자는 Lucene에 관한 글을 읽거나 등 책을 읽을 수 있습니다.다음은 Elasticsearch 인덱스 프로세스에서 발생하는 구체적인 조작을 소개할 것입니다. 그 중심은segment,buffer,translog 세 부분이 성능에 미치는 영향에 있습니다.
1. 동적 업데이트 Lucnee 인덱스
실시간과 새로운 조건에서 데이터의 사용과 신뢰성을 얻으려면 색인을 거꾸로 배열하는 토대에서 일련의 고급 처리를 해야 한다.Lucene의 처리 방법을 요약합니다. 새로 받은 데이터는 새 색인 파일에 기록됩니다.Lucene은 매번 생성되는 역렬 인덱스를 세그먼트(segment)라고 부른다.그리고 색인 내의 모든segment를 기록하는commit 파일을 따로 사용합니다.한편, segment를 생성하는 데이터 출처는 메모리에 있는buffer이다. 즉, 동적과 새로운 과정은 다음과 같다. 1) 현재 디스크에 세 개의 segement가 사용할 수 있고commit 파일이 현재의 segment2를 기록한다.) 새로 받은 데이터가 메모리에 들어가는데 인덱스 상태는 다음과 같다.3) 버퍼가 디스크에 브러시되어 새로운segment,commit 파일과 동기화되었습니다.이렇게 하면 새로운 것을 완성할 수 있고 몇 가지 문제가 발생한다. 1. 데이터가 있을 때마다 디스크로 갱신하면 디스크에 대한 조작이 증가한다. 2. 디스크로 갱신하는 시간이 많은 부분을 차지한다. 3. 갱신하는 과정에서 갱신이 실패하면 어떻게 제어해야 하나?
2、删除和更新
segment는 변경할 수 없기 때문에 문서는 낡은 단락에서 삭제할 수 없고, 낡은 단락도 문서의 최신 텍스트를 반영하기 위해 업데이트할 수 없습니다.반대로, 모든 제출점은 하나를 포함한다.del 파일은 한 문서가 삭제될 때 세그먼트에서 삭제된 문서를 포함하고 있습니다. 이것은 실제로만 있습니다.del 파일에 삭제 표시가 되어 있고 검색과 일치할 수도 있지만 최종적으로 되돌아오기 전에 결과에서 삭제됩니다.문서는 새 작업과 유사합니다. 문서가 업데이트되면 이전 버전의 문서는 삭제로 표시되고, 새 버전의 문서는 새 세그먼트에서 색인됩니다.이 문서의 다른 버전은 조회와 일치할 수 있지만, 오래된 버전은 결과에서 삭제됩니다.
3、利用磁盘缓存实现的准实时检索
디스크와 관련된 이상 피할 수 없는 문제가 있습니다. 디스크가 너무 느려요!우리가 요구하는 실시간성이 매우 높은 서비스에 대해 말하자면, 이런 처리는 아직 부족하다.따라서 방금 3단계의 처리에서 또 하나의 중간 상태가 있다. 1) 메모리 버퍼가 새로운segment를 생성하고 파일 시스템 캐시에 브러쉬하면 Lucene는 이 새로운segment를 검색할 수 있다. 인덱스 상태는 그림과 같다.2) 파일 시스템 캐시가 디스크,commit 파일과 새로 동기화됩니다.파일 시스템 캐시에 이 절차를 밟으면 Elasticsearch는 기본 1s의 시간 간격을 설정합니다. 이것은 실시간 검색에 해당합니다. Elasticsearch도 단독/_를 제공합니다reflush 인터페이스, 사용자가 1s 간격에 만족하지 않으면 검색을 볼 수 있도록 인터페이스를 주동적으로 호출할 수 있습니다.
POST /_refresh <1>POST /blogs/_refresh <2>
- <1> refresh 모든 인덱스
- <2> refresh 인덱스만요
blogs
일반적으로 우리는/_settings 인터페이스나 맞춤형 템플릿 방식,refresh_interval 매개 변수:
PUT /my_logs/_settings{ "refresh_interval": -1 } <1>PUT /my_logs/_settings{ "refresh_interval": "1s" } <2>
- <1> 모든 자동refresh를 비활성화합니다
- <2> 초당 자동refresh
4、translog提供的磁盘同步控制
refresh가 파일 시스템 캐시에 기록된 이상, 마지막 단계는 실제 디스크에 기록된 것은 무엇으로 제어됩니까?만약 이 기간에 호스트 오류, 하드디스크 고장 등 이상이 발생하면 데이터가 분실되지 않습니까?여기, 사실 Elasticsearch는 또 다른 메커니즘을 제공하여 제어한다.Elasticsearch도 메모리buffer에 데이터를 기록하는 동시에treanslog의 로그를 따로 기록합니다.즉, 메모리 데이터가 버퍼에 들어갈 때, 사실은translog 기록을 따로 기록합니다.