solrcloud 이모저모2

[SOLR] 역할 기반의 레플리카 배치

[출처] [SOLR] 역할 기반의 레플리카 배치|작성자 opti

Solr가 컬렉션에 노드 할당을 필요로 할 때, 자동적으로 할당되도록 할 수도 있고, 사용자가 레플리카를 생성할 특정 노드를 선택할 수도 있다. 매우 큰 규모의 클러스터에서는, 정확한 노드 이름을 특정하기 어려울 뿐만 아니라 샤드를 위해 선택하는 노드에 대해 정제된 제어권을 할당해주지도 않는다. 사용자는 어떤 노드가 각 컬렉션, 샤드, 레플리카에 할당되는지에 대해 제어할 수 있어야 한다. 이 기능은 클러스터 전반의 하드웨어 자원의 할당을 최적화하는 것을 도와준다.

역할 기반의 레플리카 할당은 클러스터의 레플리카 배치를 결정하는 규칙을 생성하는 것을 허용한다. 미래에는, 이 기능은 시스템 다운이 발생하거나 더 높은 스루풋이 요구될 때 레플리카를 자동적으로 더하거나 제거하는 것을 도울 것이다. 이는 클러스터의 관리에 대해 사용자가 신경을 안쓸 수 있도록 할 것이다.

이 기능은 아래 인스턴스에 사용된다

- 컬렉션 생성

- 샤드 생성

- 레플리카 생성

- 샤드 분할

일반적인 용례

이 기능이 사용될 만한 상황은 아주 다양하다. 그 중 몇몇의 규칙은 아래와 같다.

- 컬렉션에 있어 한 개의 호스트에 두 개 이상의 레플리카는 할당할 수 없다

- 디스크에 100기가바이트 이상의 가용공간이 있는 모든 레플리카를 노드에 할당하거나, 더 많은 디스크 가용공간이 있는 레플리카를 할당

- Overseer을 실행하기를 원하므로 어떠한 레플리카도 해당 호스트에 할당하지 말 것

- 랙의 각 샤드에 한 개의 레플리카만 할당할 것

- 5개 이하의 코어를 갖고있는 노드에 레플리카를 할당할 것

규칙 조건

규칙이란 레플리카 코어가 생성될 수 있기 전에 반드시 만족해야 하는 조건의 집합이다.

규칙 조건

3개의 조건이 있다.

- 샤드 : 샤드가 특정되지 않았다면, 규칙은 컬렉션 전반에 적용될 것

- 레플리카

- 태그 : 클러스터에 있어 규칙이 적용될 수 있는 노드의 속성(e.g. "freedisk", "cores", "rack", "dc", etc). 

[본 문서는 https://cwiki.apache.org/confluence/display/solr/Rule-based+Replica+Placement 의 번역문입니다]

[SOLR] 주요용어 정리

SolrCloud

- Collection: SolrCloud 클러스터의 완전한 논리적 인덱스. 설정집합으로 연관되어 있고 한 개 또는 그 이상의 샤드들로 구성되어 있다. 만약 샤드가 한 개 이상으로 구성되어 있다면, 그것은 분산 인덱스이다. 그러나 SolrCloud는 사용자가 컬렉션 이름으로 그것들을 가리키도록 할 것이며, 분산질의에 필요한 샤드 파라미터에 대해 걱정할 필요가 없도록 할 것이다.

- Config Set: core가 적절하게 작동되도록 하는 필수 설정파일의 집합. 각각의 config 집합은 이름을 가진다. solrconfig.xml과 schema.xml은 최소 구성요소이며, 이 두 파일의 내용에 따라 다른 파일들이 필요할 수 있다. 이들은 주키퍼에 저장된다. Config set은 upconfig command in the command-line utility 또는 bootstrap_confdir Solr startup parameter을 통해 업로드 되거나 업데이트 될 수 있다.

- Core: 아래의 Solr Core에서 기술되었다. SolrCloud와의 차이점 하나는, SolrCloud는 주키퍼를 이용하여 설정한다는 것이다. 기존의 Solr에서는, Core의 설정은 디스크의 conf 디렉토리에 저장될 것이다.

- Leader: 리더 선출에 의해 선택된 샤드 레플리카. 선거는 언제나 일어날 수 있으나, 일반적으로 Solr 인스턴스가 다운되었을 때 실행된다. document가 인덱스 된 후, Solrcloud는 그것들을 샤드의 리더에게 전달하고, 리더는 모든 샤드 레플리카에 이것을 분배할 것이다.

- Replica: 샤드의 한 복사본. 각각의 레플리카는 core로 Solr 내부에 존재한다. numShards=1이고 replicationFactor 가 2인 "test"라는 컬렉션은 두 개의 레플리카를 갖게 될 것이고, 각각의 다른 머신 상에 (또는 Solr 인스턴스에) 하나씩 총 두 개의 core로 존재하게 될 것이다. 하나는 test_shard1_replica1 로 이름지어질 것이고, 다른 하나는 test_shard1_replica2로 이름지어질 것이다. 그 중 하나가 리더로 선출될 것이다.

- Shard: 컬렉션의 논리적 조각. 각각의 샤드는 하나 또는 그 이상의 레플리카로 구성되어 있다. 어떤 레플리카가 리더일지 결정하는 선거가 실행될 것이다. 샤드의 SolrCloud 상 개념은 논리적 단위이다.

- Zookeeper: 클러스터의 다른 프로그램들이 기능을 잘 수행할 수 있도록 돕는 프로그램. SolrCloud는 Zookeeper를 필요로 한다. 이것은 리더 선거를 다룬다. Solr는 내장된 Zookeeper를 이용함에도 불구하고, Solr와 독립적으로 설치된 standalone로 운용되기를 추천한다. 견고한 앙상블을 위해 적어도 세 개의 호스트를 필요로 한다. Solr와 동일한 하드웨어에서 실행될 수 있고, 많은 사용자들이 동일한 하드웨어에서 Zookeeper를 실행한다.

General

- Auto-warming: Solr가 새로운 캐시를 열고, 캐시의 오래된 인스턴스에 있는 "top" 키들에 기반한 key/val 쌍들을 심을 때 하는 일들

- Constraint: 객체의 집합을 제한하는, 실행가능한 메서드

- Core: 아래의 Solr Core 를 참고

- Facet: "자원을 분류하는 방법"

- Field Collapsing: 결과 그룹핑의 특정 사용례. 그룹은 필드의 값에 좌우된다.

- Filter: 문맥에 따라 다른데, 아마도:

1. Constraint의 다른 표현

2. score에 영향을 주지 않는 질의로부터의 결과를 제한하는 "fq" 파라미터

3. 루씬 "Filter" 클래스를 참조하는 것을 특정

- NRT: Near Real Time: 검색 클라이언트가 Document의 갱신이 "즉각적"이기를 바라는 개념

- Request Handler: 요청을 처리하는 Solr 컴포넌트. 예를 들어, DisMaxRequestHandler은 DisMax 질의파서를 호출하는 검색질의를 처리한다. 게다가, Request Handler은 다른 함수들을 수행할 수 있다.

- QTime: 요청의 도착으로부터 (SolrQueryRequest 객체가 생성되었을 때 부터) 요청 핸들러의 종료 까지의 측정시간(밀리초 단위). 클라이언트로의 응답에 있어 formatting 또는 streaming 에 대한 시간은 포함하지 않는다.

- Query Parser: 제출된 검색 질의에서 파라미터와 검색 용어를 추출하는 Solr 컴포넌트

- Searcher: Solr 용어에 있어, "Searcher"라는 용어는 주로 SolrIndexSearcher 클래스의 인스턴스를 뜻한다. 이 클래스는 인덱스와, 관리되고 있는 여러 캐시들로부터 모든 질의를 수행하는것에 대한 책임을 가진다. 전형적으로 한 개의 SolrCore 당 한 개의 Searcher을 뜻하며, 이 Searcher은 SolrCore에서 담당한 모든 질의를 수행하는데 사용되나, Cache warming ("New Searcher"이 준비되기 까지 "Old Searcher"가 살아있으라는 요청)동안 추가적인 Searcher가 생성된다.

- Shard: 분산된 인덱스는 "Shards"에 쪼개어 들어간다. 각 Shard는 Solr core와 교신하며 인덱스에 있는 문서들의 독립적 부분을 포함한다.

- Slop: "phrase slop": 질의의 어구를 일치하기 위해서 두 개의 토큰이 이동해야 할 위치의 갯수

- Solr Core: 단지 "Core"라고 불리기도 함. 모든 Solr 설정과 함께하는 루씬 인덱스의 실행중인 인스턴스. 단일 Solr 어플리케이션은 isolation 아래에 0 또는 더 많은 코어를 가지지만, 각자가 필요에 따라 CoreContainer를 통해 커뮤니케이션을 할 수 있다. 전통적인 관점에서는: Solr는 최초에는 오직 하나의 인덱스만 지원했고, SolrCore클래스는 Solr 의 Core에서 로우레벨의 기능을 조정하기 위한 싱글턴이였다. 다중 코어를 생성하고 관리하는 기능이 지원되었을 때, 이 클래스는 더이상 싱글턴이 되지 않도록 리펙토링 되었으나, 이름은 변하지 않았다.

- Solr Home Dir: "Solr Home Directory" 또는 "Solr Home"라고 불리우는, Solr가 설정파일, 데이터, 그리고 플러그인을 찾을 주 디렉토리이다. 어떤 디렉토리를 Solr Home 로 사용할 것인지 안다는 것은, Solr가 Solr의 일반 설정파일의 메커니즘 일부를 통해 추정하거나 설정되어야 함을 뜻한다. 

[본 페이지는 https://wiki.apache.org/solr/SolrTerminology 를 를 번역한 것입니다]

[출처] [SOLR] 역할 기반의 레플리카 배치|작성자 opti