'Elastic/ElasticsearchReferences'에 해당되는 글 3건

  1. 2018.04.06 [Elasticsearch] Split Index 기능 맛보기
  2. 2017.12.13 [Elasticsearch] copy_to mapping 예제
  3. 2016.03.16 [Elasticsearch] index_options 알아보기.

[Elasticsearch] Split Index 기능 맛보기

Elastic/ElasticsearchReferences 2018. 4. 6. 14:24

Split index 기능에 대해서 공식 문서에 나와 있는 내용을 그대로 테스트 해봤습니다.

(Shrink 와 Split 은 모두 Resize Action 에 해당 합니다.)


Reference)

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-split-index.html


이 split index API 는 기존에 존재하는 또는 생성된 index 의 primary shard 를 신규 index 로 기존 primary shard 크기 보다 크게 split 해서 생성해 주는 역할을 합니다.


RESTful endpoint 는 _split 입니다.


근데 7.0 에서는 삭제 된다고 하니 제가 이걸 왜 쓰고 있는지 모르겠습니다.

하지만 늘 그렇듯이 Elasticsearch 에서는 기능이 없어지게 되면 대체 가능한 기능을 추가로 제공해 줍니다. :)


이 API 사용시 제일 중요한 부분은 IMPORTANT 에 잘 나와 있습니다.


The _split API requires the source index to be created with a specific number_of_routing_shards in order to be split in the future. This requirement has been removed in Elasticsearch 7.0.


※ Source index 를 생성 할때 설정을 해줘야 한다는 이야기 입니다.


그럼 문서에 나와 있는 데로 한번 돌려 보겠습니다.

하지 전에, elasticsearch 하나 띄워 놓으시고 kibana 도 띄워 놓으세요. 그래야 편하게 dev tool 이용해서 request 할 수 있겠죠.


Step 1) Preparing an index for splitting

Source index 를 생성 하는 과정이며 이 과정에서 반드시 routing shard 정보를 설정 하셔야 합니다.


PUT my_source_index

{

    "settings": {

        "index.number_of_shards" : 1,

        "index.number_of_replicas" : 0,

        "index.number_of_routing_shards" : 2

    }

}


Step 2) Set read-only mode

Split 하기 전에 반드시 읽기 전용으로 반드시 설정을 하셔야 합니다. 안하시면 에러 납니다.

그럼 왜 해야 할까요?

보통 DB 마이그레이션 작업 하실때 생각을 해보시면 됩니다. :)


PUT /my_source_index/_settings

{

  "settings": {

    "index.blocks.write": true 

  }

}


문서를 자세히 보기 전까지 저 설정이 block 단위로 write 할 수 있도록 해주는 설정인 줄 알았습니다. ^^;


Step 3) Splitting an idex

이제 primary shard 를 2 개로 늘려 보겠습니다.


POST my_source_index/_split/my_target_index

{

  "settings": {

    "index.number_of_shards": 2,

    "index.number_of_replicas" : 0

  }

}


이 단계 작업을 하면서 주의 할 점은 당연한 내용이지만, 

1. target index 가 없어야 겠죠.

2. source index 의 primary shard 보다 커야 겠죠.

3. factor 조건을 만족 해야 합니다.


routingNumShards % numTargetShards != 0 이면 안되구요.


if (sourceNumberOfShards < targetNumberOfShards) { // split

factor = targetNumberOfShards / sourceNumberOfShards;

if (factor * sourceNumberOfShards != targetNumberOfShards || factor <= 1) { 이면 안되구요. }

}


즉,

- 나눠서 나머지가 없어야 합니다.

- target shard 는 routing shard 보다 작거나 같아야 합니다.


아래는 factor 조건을 만족하지 않는 예시 입니다.


PUT my_source_index

{

    "settings": {

        "index.number_of_shards" : 1,

        "index.number_of_replicas" : 0,

        "index.number_of_routing_shards" : 4

    }

}


PUT /my_source_index/_settings

{

  "settings": {

    "index.blocks.write": true 

  }

}


POST my_source_index/_split/my_target_index

{

  "settings": {

    "index.number_of_shards": 3,

    "index.number_of_replicas" : 0

  }

}


조건 1) 

4 % 3 => 1 // 0 이 되어야 합니다.


조건 2) 

assert getRoutingFactor(3, 4) >= 0


if ( 3 < 4 ) {

    factor = 4 / 3; // factor = 1

    if ( factor * 3 != 4 || factor <= 1) {

        throw new IllegalArgumentException(.....);

    }

}



혹시라도 사용하셔야 하는 분들이 계시다면 참고 하시면 되겠습니다.

:

[Elasticsearch] copy_to mapping 예제

Elastic/ElasticsearchReferences 2017. 12. 13. 16:31

nested mapping 구조를 가지는 경우 copy_to 에 대한 동작 오류가 몇 건 보고 된게 있어서 코드 보다가 살짝 올려 봅니다.

공식문서는 아래 링크 참고하세요.

https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html


XContentBuilder mapping = jsonBuilder().startObject()
.startObject("type")
.startObject("properties")
.startObject("target")
.field("type", "long")
.field("doc_values", false)
.endObject()
.startObject("n1")
.field("type", "nested")
.startObject("properties")
.startObject("target")
.field("type", "long")
.field("doc_values", false)
.endObject()
.startObject("n2")
.field("type", "nested")
.startObject("properties")
.startObject("target")
.field("type", "long")
.field("doc_values", false)
.endObject()
.startObject("source")
.field("type", "long")
.field("doc_values", false)
.startArray("copy_to")
.value("target") // should go to the root doc
.value("n1.target") // should go to the parent doc
.value("n1.n2.target") // should go to the current doc
.endArray()
.endObject()
.endObject()
.endObject()
.endObject()
.endObject()
.endObject()
.endObject()
.endObject();


:

[Elasticsearch] index_options 알아보기.

Elastic/ElasticsearchReferences 2016. 3. 16. 11:03

Mapping parameters 중에 index_options에 대해서 알아보겠습니다.

(이전에 정리한게 없어서 복습 차원에서 기록 합니다.)


원본문서)


원본 Snippet)

docs

Only the doc number is indexed.
Can answer the question
 Does this term exist in this field?

freqs

Doc number and term frequencies are indexed.
Term frequencies are used to score repeated terms higher than single terms.

positions

Doc number, term frequencies, and term positions (or order) are indexed.
Positions can be used for
 proximity or phrase queries.

offsets

Doc number, term frequencies, positions, and start and end character offsets
(which map the term back to the original string) are indexed.
Offsets are used by the
 postings highlighter.

Analyzed string fields use positions as the default, and all other fields use docs as the default.

The text field will use the postings highlighter by default because offsets are indexed.


▶ 내용을 정리해 보면 이렇습니다.

index_options 는 기본 analyzed field에 대해서 구성 하는 것입니다. not_analyzed field는 아니라는 이야기죠.

그리고 이 옵션은 아래로 내려 갈수록 상위 옵션을 포함하게 됩니다.


docs는 말 그대로 document count만 색인 합니다.

freqs는 말 그대로 docs + term frequnce를 색인 합니다.

positions는 말 그대로 freqs + term position을 색인 합니다.

offsets는 말 그대로 positions + term offset을 색인 합니다.


positions를 설정 하게 되면 proximity 또는 phrase query를 사용 할 수 있습니다. 즉, 설정 하지 않으면 말짱 꽝!!

offsets를 설정 하게 되면 추가적으로 highlight 기능을 사용 할 수 있습니다. 강조를 사용해야 하는데 설정 하지 않으면 역시 말짱 꽝!!


analyzed field 의 기본 index_options는 positions 입니다. 그리고 강조 기능은 기본 posting hilighter 입니다.


: