Search Results for 'Computer/Elasticsearch'

7 POSTS

  1. 2015.05.28 cache(indices.cache.filter.size)
  2. 2015.05.07 elasticsearch thread pool
  3. 2015.05.06 doc values
  4. 2015.05.06 eager, eager global ordinals (1)
  5. 2015.05.06 Field data
  6. 2015.03.09 shard 상태 확인
  7. 2015.02.09 Elasticsearch Korea User Group

cache(indices.cache.filter.size)

Posted 2015. 5. 28. 10:58

Cache 

https://www.elastic.co/guide/en/elasticsearch/reference/1.5/index-modules-cache.html


Filter Evictions과 관련해서 indices.cache.filter.size 기본 설정 값 확인 중

cache에 대한 공식 문서를 정리해 놓습니다.


index와 관련된 다른 caching inner modules 있다.

그것은 filter와 다른 것들을 포함한다.


Filter Cache


filter cache는 filter의 결과에 대한 caching에 책임이 있다.

filter cache의 기본 구현은 node filter cache type이다.


node filter cache


node filter cache는 전체 메모리의 %(퍼센트)나 특정한 메모리 양으로 설정된다.

node의 모든 shards는 single node cache를 공유한다.

cache는 LRU eviction policy를 사용하고, cache가 가득차면 가장 최근에 사용된 데이터는 새로운 데이터를 위해 evicted 된다. 


indices.cache.filter.size는 기본값이 10%이다.

이 설정은 index level setting이 아니라, node level setting이다.


indices.cache.filter.size를 세팅하려면 elasticsearch.yml에 설정해야 한다는 이야기다.

ex) indices.cache.filter.size: 30%



'Computer > Elasticsearch' 카테고리의 다른 글

cache(indices.cache.filter.size)  (0) 2015.05.28
elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Write your message and submit

elasticsearch thread pool

Posted 2015. 5. 7. 16:28

http://www.elastic.co/guide/en/elasticsearch/reference/1.x/modules-threadpool.html


node는 thread memory consumption의 관리를 위해 several thread pools을 가진다.

이 pool들은 queues를 가지고, request를 폐기하는대신 대기할 수 있다.


index : fixed # of available processors, queue_size of 200

search : fixed 3x # of available processors, queue_size of 1000

suggest :  fixed # of available processors, queue_size of 1000

get : fixed # of available processors, queue_size of 1000

bulk : fixed # of available processors, queue_size of 50

precolate : fixed # of available processors, queue_size of 1000

snapshot : scaling, keep-alive 5m with a size of (# of available processors)/2

warmer : scaling with a 5m keep-alive

refresh : scaling with a 5m keep-alive

listener : (# of available processors)/2, max at 10


* cluster update settings를 통해 thread pool의 값들을 변경할 수 있음


thread pool types


cache : unbounded thread pool, 요청에 따라 pending 됨


threadpool:

    index:

        type: cached


fixed : fixed size, handle thre request with a queue


threadpool:

    index:

        type: fixed

        size: 30

        queue_size: 1000


개인 목적으로 공식 문서를 번역했습니다.

틀린 부분이 있을수도 있습니다.

'Computer > Elasticsearch' 카테고리의 다른 글

cache(indices.cache.filter.size)  (0) 2015.05.28
elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Write your message and submit

doc values

Posted 2015. 5. 6. 15:46

http://www.elastic.co/guide/en/elasticsearch/guide/current/doc-values.html


인덱스 시점에 disk에 in-memory fielddata를 저장하는 방법

doc value는 in-memory fielddata에 비해 10~25% 느리다.

하지만, 2가지 장점이 있다.

1) heap memory 대신 disk에 있다.

   더 적은 heap을 사용할 수 있고, gc의 속도를 향상 시킬 수 있고, 일관성과 노드의 안정성을 향상 시킬 수 있다.

2) doc values는 index time에 빌드된다.


trade-off는 larger index size와 약간 느려진 fielddata access이다.

doc values는 상당히 효율적이다. 그래서 많은 queries에서 약간 늦어진 것을 못 알아차릴수도 있다. 

더 빠른 gc와의 결합과 향상된 초기화 시간의 결합은 더 빨라진 것으로 느낄수도 있다.


더 많은 filesystem cache space를 너는 사용할 수 있다면, 더 나은 성능을 가질 수 있다.

만약 파일들이 docs values를 filesystem cache에 상주시킨다면, file 접근은 RAM으로부터 읽는 것과 거의 동일하다.

그리고, filesystem cache는 JVM대신 kernal에 의해 관리된다.


Enabling Doc Values


Doc values는 numeric, date, Boolean, binary, and geo-point fields, and for not_analyzed string fields에 enable할 수 있다.

analyze string fields에서는 작동하지 않는다.

Doc values는 각 field마다 enable할 수 있다. 이것은 in-memory fielddata와 doc values를 결합할 수 있다는 의미이다.


PUT /music/_mapping/song

{

  "properties" : {

    "tag": {

      "type":       "string",

      "index" :     "not_analyzed",

      "doc_values": true 

    }

  }

}


'Computer > Elasticsearch' 카테고리의 다른 글

cache(indices.cache.filter.size)  (0) 2015.05.28
elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Write your message and submit

eager, eager global ordinals

Posted 2015. 5. 6. 15:26

http://www.elastic.co/guide/en/elasticsearch/guide/current/preload-fielddata.html


ES는 기본적으로 fielddata를 lazily load 한다.

ES는 particular field에 fielddata가 필요한 query가 생기면, 전체 field를 각 index의 segement에 대해 메모리로 load한다.


작은 segments에서는 이 시간이 별로 안 걸리지만, 5GB segments는 10GB fielddata를 메모리로 올려야 한다. 이 과정은 수십초가 걸린다.


지연에 대비할 수 있는 3가지 방법이 있다.

1) Eagerly load fielddata

2) Eagerly load global ordinals

3) Prepopulate caches with warmers



1) Eagerly load fielddata

eager loading이 설정된 field는 검색이 가능하기전 각 segement에 미리 로딩된다.


PUT /music/_mapping/_song

{

  "price_usd": {

    "type": "integer",

    "fielddata": {

      "loading" : "eager" 

    }

  }

}


2) Eagerly load global ordinals


fielddata에 사용될 메모리 사용량을 줄일 수 있는 방법은 ordinals를 사용하는 것이다.


만약, 10억개의 문서들에 status field가 있다고 해보자. 

3가지 상태(status_pending, status_published, status_deleted)가 있다고 할 때,

우리는 각 문서에 전체 문자열을 저장한다면 14 ~ 16 bytes가 필요하고, 전체크기는 15GB가 필요하다.


그 대신, 우리는 세가지 unique strings을 사용할 수 있다. 0, 1, 2


Ordinal | Term

-------------------

0       | status_deleted

1       | status_pending

2       | status_published


원래 문자열은 ordinals list에 한번만 저장되고, 각 문서는 오직 ordinal을 가리키는 숫자를 사용한다.


Doc     | Ordinal

-------------------------

0       | 1  # pending

1       | 1  # pending

2       | 2  # published

3       | 0  # deleted


그러나 여기에 문제가 있다. fielddata caches는 segment 단위로 저장된다.

만약 segment가 오직 2가지 상태를 포함한다면 status_deleted, status_published

그러면 ordinals는 3가지 상태를 가진 segment의 ordinal과 다르다.


만약 우리가 status field에 대해 term aggregation을 하려고 한다면, 우리는 실제 문자열 값이 필요하다.

이것은 모든 segments에 대해 같은 값을 구별할 필요가 있다는 것을 의미한다.


global ordinals 구조를 사용하면 모든 segments에 대해 ordinals를 저장한다.


Building global ordinals


global ordinals는 fielddata와 doc values 메모리 위에 빌드되어 있다.

실제로, doc values가 그것처럼 주요한 이유다.


fielddata loading과 같은 방식으로 global ordinals 가 lazily하게 빌드된다.

refresh, flush, merge 후에 rebuilt된다.


PUT /music/_mapping/_song

{

  "song_title": {

    "type": "string",

    "fielddata": {

      "loading" : "eager_global_ordinals" 

    }

  }

}


Ordinals는 오직 strings에 대해서만 빌드된다.

숫자 데이터는 그 자체로 oridinal mapping 된다.


doc values를 사용한 예제


PUT /music/_mapping/_song

{

  "song_title": {

    "type":       "string",

    "doc_values": true,

    "fielddata": {

      "loading" : "eager_global_ordinals" 

    }

  }

}


이렇게 하면, fielddata는 filesystem cache에 로드된다.


fielddata preloading과는 다르게, global ordinals의 eager building은 데이터의 real-time에 영향을 받는다.

매우 높은 cardinality fields에 대해서는 refresh에 수초가 딜레이 될 수 있다. 그래서, refresh 또는 query시에 building할지 선택해야 한다.

만약 인덱스가 query가 빈번하지 않다면, refresh보다 query시에 build 하는 것이 더 낫다.


* elastic.co에 있는 문서를 번역한 내용입니다.

필요에 따라 생략한 부분도 있습니다.

'Computer > Elasticsearch' 카테고리의 다른 글

elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Elasticsearch Korea User Group  (0) 2015.02.09
  1. 천천히올라가자

    | 2021.02.07 22:39 신고 | PERMALINK | EDIT | REPLY |

    감사드립니다.

Write your message and submit

Field data

Posted 2015. 5. 6. 14:22

Field data: http://www.elastic.co/guide/en/elasticsearch/reference/1.4/index-modules-fielddata.html


field data cache는 주로 field에 대해 sorting 또는 faceting에 사용된다.

그것은 value에  문서기반으로 빨리 접근할 수 있도록 field values은 메모리로 읽는다.

field data cache는 비용이 많이 들 수 있다. 그래서 충분한 메모리를 사용할 수 있을 때 있을 때 추천되고, 그것은 load를 유지한다.


field data cache에서 사용할 메모리 크기는 indices.fielddata.cache.size에서 설정할 수 있다.

참고로, cache가 적절하지 않다면 field data를 다시 읽어와야 하고, 그 값은 비싸고, 매우 느리게 수행된다.


indices.fielddata.cache.size는 %, GB으로 설정할 수 있으며, 기본 값은 unbounded이다.

indices.fielddata.cache.expire는 시간을 기반으로 expire를 설정할 수 있다. 기본값은 -1이고, 5m 처럼 설정할 수 있다.


Field data Circuit Breaker의 기본값은 JVM Heap size의 60%이다.


indices.breaker.fielddata.limit: 기본값 60%

indices.breaker.fielddata.overhead: 기본값 1.03


field data statistics는 아래 처럼 확인할 수 있다.

http://www.elastic.co/guide/en/elasticsearch/reference/1.4/cluster-nodes-stats.html


# Node Stats

curl -XGET 'http://localhost:9200/_nodes/stats/indices/?fields=field1,field2&pretty'


# Indices Stat

curl -XGET 'http://localhost:9200/_stats/fielddata/?fields=field1,field2&pretty'


# You can use wildcards for field names

curl -XGET 'http://localhost:9200/_stats/fielddata/?fields=field*&pretty'

curl -XGET 'http://localhost:9200/_nodes/stats/indices/?fields=field*&pretty'


elastics.co에 있는 문서를 번역한 내용입니다.
개인 참고용으로 작성했습니다.


'Computer > Elasticsearch' 카테고리의 다른 글

elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Elasticsearch Korea User Group  (0) 2015.02.09
Write your message and submit

shard 상태 확인

Posted 2015. 3. 9. 16:48

ES에서 shard의 상태를 확인하고자 한다면...

다음과 같이 확인할 수 있다.


curl -XGET "http://localhost:9200/_cat/shards"


이렇게 하면, 어떤 샤드가 어떤 노드에 할당되어 있는지, 

혹은 할당되지 않은 샤드를 확인할 수 있다.





'Computer > Elasticsearch' 카테고리의 다른 글

elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Elasticsearch Korea User Group  (0) 2015.02.09
Write your message and submit

Elasticsearch Korea User Group

Posted 2015. 2. 9. 07:00

요즘 Elasticsearch(이하 ES)를 이용해서 무언가를 만들고 있다.

(무언가를 구성하고 있다...가 더 올바른 표현인 것 같다.)


ES를 이용해서 구성할 때, 가장 어려웠던 점은

ES에서 제공하는 기능이 뭔지 알아내는데 상당한 시간이 필요하고,

ES의 최적화를 위해서 여러 방법을 생각해보지만, 그 방법이 맞는지 너무너무 헷갈린다는 점이다.


이제, 내가 고민했던 내용들과 이해했던 내용들을 정리하려고 한다.

ES를 사용하려는 사용자들에게 조금이나마 도움이 되면 좋겠다.


먼저, 한국 엘라스틱서치 사용자 그룹 URL을 공유한다.


https://www.facebook.com/groups/elasticsearch.kr/

'Computer > Elasticsearch' 카테고리의 다른 글

elasticsearch thread pool  (0) 2015.05.07
doc values  (0) 2015.05.06
eager, eager global ordinals  (1) 2015.05.06
Field data  (0) 2015.05.06
shard 상태 확인  (0) 2015.03.09
Elasticsearch Korea User Group  (0) 2015.02.09
Write your message and submit