elastic search basic concept
elasticsearch의 기본 개념에 대한 발 번역이네요. 수정요청 주시면 더욱 감사합니다.(__)
기본 컨셉
elasticsearch의 몇몇 주요 개념에 대해 살펴보자.
시작부터 이런 개념들을 이해하는 것은 배우는 과정에서 어마무시하게 도움이 될 것인다.
거의 실시간(NRT)
elasticsearch는 실시간에 가까운 검색 플랫폼이다. 이것이 의미하는 것은 당신이 인덱스한 문서
가 검색가능하게 될 때까지 약간의 시간이(일반적으로 1초) 걸린다는 것이다.
클러스터
클러스터는 하나 또는 그 이상의 노드(서버)들의 집합이다. 이런 서버들은 당신의 전체 데이터를
합치고 전체 노드를 인덱싱하고 검색가능하게 한다. 클러스터는 유일한 이름으로서 식별된다.(기본적
으로는 “elasticsearch”라는 이름을 가진다. 이러한 이름들은 중요하다.왜냐하면 노드들이 만약
클러스터에 이름으로 join하기 위해 구성된다면 한개의 클러스터의 부분이 될 수 있기 때문이다.(??)
다른 환경에서 동일한 이름의 클러스터가 재사용 되는 지 확인해라. 그렇지 않다면 당신은 잘못된
노드에 join 시킬 수 있다. 이를테면 당신은 개발, 스테이징, 프로덕트 클러스터의 이름으로 logging-dev
,logging-stage , logging-prod 로 할 수 있다.
클러스터에 하나의 노드를 구성하는 것은 유효하며 굉장히 좋다는 것을 기억해라.
###노드
하나의 노드는 하나의 서버이며 클러스터로 구성될 수 있고, 데이터를 저장하고 클러스터의 인덱싱과
검색 기능으로 참여시킬 수 있다. 클러스터와 동일하게 노드 역시 이름으로 구분 되며, 기본적으로
무작위의 Mavel 캐릭터의 이름 기동시에 할당 된다. 몰론 당신은 기본 이름이 아닌 당신 원하는 이름으로
도 정의할 수 있다. 이름은 당신의 elasticseach 클러스터 내에서 노드에 대응되는 서버를 식별하기 원하는
관리 목적으로 중요하다(??)(This name is important for administration purposes where you want to
identify which servers in your network correspond to which nodes in your Elasticsearch cluster.)
하나의 노드는 하나의 특정 클러스터로 클러스터명을 이용해 join이 구성될 수 있다.기본적으로 각 노드
는 elasticsearch 라는 이름의 클러스터로 join되는데, 만약 네트워크 상에 다수의 노드를 기동시키고,
각각 발견된다고 가정할 때 그들은 자동적으로 elasticsearch 라는 이름의 단일 클러스터에 합류될 것이.
단일 클러스터 내에서 당신은 원하는 만큼의 많은 수의 노드를 가질 수 있다.더 나아가 만일 네트워크 상
에 현재 가동 중인 elasticsearch 노드가 없다면 기본적으로 elasticsearch라는 이름의 단일 노드가 구성
되고 시작될 것이다.
index
인덱스는 다소 유사한 특성을 가지는 문서의 집합이다. 예를 들어 고객, 상품 카타로그, 주문의 인덱스를
가질 수 있다. 인덱스는 이름으로서 식별되어 지며, 이러한 인덱스는 문서를 인덱스에 인덱싱, 검색, 수정,
삭제 작업들을 할 때 참조로서 사용되어질 것이다.
단일 클러스터 내에서 당신은 원하는 만큼의 다수의 인덱스를 정의 할 수 있다.
Type
인덱스 내에서 하나 또는 그 이상의 타입을 정의할 수 있다. 타입은 인덱스의 논리적인 카탈로그/구획이다.
의미는 당신에게 달려있다.(?) 일반적으로 타입은 공통 필드 집합을 가지는 문서를 위해 정의 된다.
예를들어 당신이 블로깅 플랫폼을 돌린다고 가정해 보자. 또한 모든 데이터는 단일 인덱스에 넣는다. 이
인덱스에서 당신은 사용자 데이터를 위한 타입, 블로그 데이터를 위한 또 다른 타입, 코멘트 데이틑 위한 또
다른 타입을 정의 할 것이다.
Document
문서는 인덱스 될 수 있는 정보의 기본 유닛이다. 예를 들어 당신은 단일 사용자를 위한 문서를 가질 수 있고,
단일 제품을 위한 또 다른 문서, 단일 주문을 위한 또 다른 문서를 가질 수 있다. 이러한 문서는 인터넷 데이터
교환 형태로서 어디서 볼 수 있는 JSON으로 표현된다.
Shards & Replicas
하나의 인덱스는 잠재적으로 하나의 서버의 용량 제한을 뛰어넘는 매우 큰 양의 데이터가 저장될 수도 있다.
예를 들어 1테라를 가지는 문서가 10억개인 단일 인덱스는 하나의 서버에는 맞지도 않을 것이며, 하나의 노드
혼자서 검색 서비스를 한다고 하면 매우 느릴 것이다.
이러한 문제를 풀기위해 elasticsearch는 당신의 인덱스를 샤드라고 불리우는 여러개의 조각으로 나누는 기능을
가지고 있다. 인덱스 생성 시 당신은 간단하게 원하는 만큼의 샤드를 생성할 수 있다. 각각의 샤드는 fully-functional
하고, 클러스터 상의 어떤 노드 상에서 호스트 될 수 있는 인덱스와 독립적이다.(??)
샤딩은 다음 두개지 이유로 중요하다.
* 당신의 콘텐츠를 평면적으로 분리/확장이 가능하다.
* 처리량과 성능향상을 위한 샤드간의 분배, 병행 처리가 가능하다.
샤드의 분배 메커니즘과 검색 요청에서의 문서가 어떻게 집계되는 가는 완벽하게 elasticsearch에 의해 관리되고, 사용자에게
투명하다.
네트워크/클라우드 상에서 실패가 예측되는 어떤 때에, 어떤 이유에서든 샤드/노드 케이스 상의 패일오버 메카니즘은 매우
유용하고, 굉장히 권장된다.(?) 이것을 위해, elasticsearch는 하나 또는 그 이상 인덱스의 샤드의 복제를 만들 수 있다.
(레플리카 샤드 또는 레플리카 요약(?)이라고 한다.;(역주)레플리케이션 같은 개념 인듯(?))
레플리케이션은 두가지 이유로서 중요하다.
* 샤드/노드 실패 상황에서 고가용성을 제공한다. 이러한 이유로, 복제된 원본/프라이머리 샤드로 부터 동일 노드 상에 복제 샤드가 절대로 할당되지 않게 하는 것은 중요하다.
* 검색은 모든 레플리카 상에서 병행으로 실행되게 확장이 가능하다.
요약하면 각 인덱스는 다수의 샤드로 나우어져 있고, 하나의 인덱스는 여러 번 복제될 수도 있다.(복제 안 될 수도 있다.)
한번 복제되면 각 인덱스는 프라이머리 샤드(원본 샤드)와 복제샤드를 가진다. 만은 샤드와 레플리카스는 인덱스가 생성될 때
마다 인덱스 별로 정의될 수 있다. 인덱스 생성 후 어떠한 때라도 동적으로 레플리카스의 수를 변경할 수 있지만,추후 샤드 수는 변경 할 수 없다.(??)( After the index is created, you may change the number of replicas dynamically anytime but you cannot change the number shards after-the-fact.)
기본적으로 elasticsearch 상의 각 인덱스는 5개의 프라이머리 샤드와 하나의 레플리카로 할당된다.(하나의 노드 케이스) 클러스터에 최소한 두개의 노드를 가질 때,인덱스는 5개의 프라이머리 샤드와 5개의 레플리카 샤드(1 완료 레플리카)를 가진다. 즉, 인덱스 당 10개의 샤드를 가지게 된다.
Note 각 elasticsearch 샤드는 루씬 인덱스이다. 하나의 루씬 인덱스가 가질수 있는 최대 문서수가 있다. LUCENE-5843에 따르면
2,147,483,519( = Integer.MAX_VALUE - 128) 만큼의 문서 수 제한을 가진다. 당신은 _cat/shards Api를 통해 샤드의 수를 모니터
할 수 있다.
자, 이제 좀 더 재미있는 부분을 해보도록 하자!!!