'Elastic Search'에 해당되는 글 43건

  1. 2015/04/23 용비 02. Configuration
  2. 2015/04/23 용비 01. Installation
  3. 2015/04/23 용비 21. Conclusion
  4. 2015/04/23 용비 20. Exploring Your Data - Executing Aggregations
  5. 2015/04/22 용비 19. Exploring Your Data - Executing Filters

[Environment Variables]

Script , Elasticsearch JVM 시작될 넘겨지는 JAVA_OPTS 포함하고 있다. 그중 가장 중요한 설정은 프로세스의 maximum memory 다루는 -Xmx minimum memory 다루는 -Xms이다. (일반적으로 많은 메모리가 할당될 수록 좋다.)


대부분의 경우, JAVA_OPTS 기본값으로 남겨두는 것이 좋다. 그리고 JVM 설정이나 파라미터를 설정/변경하고자 하는 경우에는 ES_JAVA_OPTS 사용하라.


ES_HEAP_SIZE 환경 변수는 elasticsearch java process heap memory 설정에 사용한다. 별로 추천하고 싶지 않지만, ES_MIN_MEM (default : 256 MB), ES_MAX_MEM (default : 1 GB) 값을 명시적으로 설정할 있다. 하지만, ES_HEAP_SIZE 이용하면 min, max 모두 동일한 값을 가지게 된다.


Min, Max 값을 동일하게 설정하고, mlockall (http://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#setup-configuration-memory) 가능하도록 설정하는 것을 추천한다.


[System Configuration]

  • File Descriptors (FD)

Elasticsearch 실행하는 machine open files descriptors 숫자를 증가시켜라. 32k 64k 설정하는 것을 추천한다.

Process 얼마나 많은 file 오픈했는지 테스트하려면 -Des.max-open-files 값을 true 설정하고 시작하라. Process 시작 , 사용할 있는 open files 숫자를 표시할 것이다.

아니면, 각각의 node에서 다음과 같은 nodes Info API 사용하여 max_file_descriptors 값을 얻을 있다.


curl localhost:9200/_nodes/process?pretty


  • Virtual Memory

Elasticsearch index 저장하는데 hybrid mmapfs / niofs directory (http://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html#default_fs) 기본적으로 사용한다. OS mmap count 대한 제한값은 너무 작기 때문에 out of memory exception 발생한다. Linux에서는 root 계정으로 다음 command 실행하여 limit값을 증가시킬 있다.


sysctl -w vm.max_map_count=262144


값을 영구적으로 반영하기 위해서는 /etc/sysctl.conf vm.max_map_count 항목을 업데이트하라.


[NOTE]

패키지(.deb, rpm) 이용하여 Elasticsearch 설치했다면 자동으로 값이 변경되어 있을 것이다. 확인해 보려면 sysctl vm.max_map_count 실행해 보라.


  • Memory Settings

Linux Kernel file system cache 있으면 많은 메모리를 사용하고 사용하지 않은 application memory, Elasticsearch process 인해 swap memory 열심히 swap하려고 한다. Swapping 성능상, node 안정성 측면에서 아주 좋지 않으므로 피해야 한다.


3가지 옵션이 있다.

  • Disable swap

가장 간단한 옵션은 swap 사용할 없도록 하는 것이다. 일반적으로 Elasticsearch box (서버)안에서 실행되는 유일한 서비스다. 그리고 메모리 사용량은 ES_HEAP_SIZE 환경 변수로 제어할 있다. Swap 사용할 필요가 없다. Linux System에서 sudo swapoff -a 실행하여 일시적으로 swap 사용하지 않도록 있다. 영구적으로 적용하려면 /etc/fstab file 편집하여 swap 포함하고 있는 line들을 주석처리 하면 된다.


  • Configure swappiness

두번째 옵션은 sysctl vm.swappiness 값을 0으로 설정하는 것이다. 이것은 kernel swap하려고 하는 추세를 감소시키고, 일반적인 환경에서는 swap 하려고 하지 않는다. 하지만, 긴급상황에서는 여전히 전체 시스템을 swap하려고 것이다.


[NOTE]

Kernel version 3.5-rc1 윗버전부터 swappiness 0으로 하면 swapping 허용하는 대신에 OOM killer process 죽이려고 것이다. 긴급 상황에서 swapping 허용하려면 swappiness 1 설정할 필요가 있다.


  • mlockall

세번째 옵션은 Linux/Unix 시스템에서만 사용할 있는데, RAM process address space mlockall 사용해 Lock하는 것이다. 이것을 사용하면 Elasticsearch 어떤 메모리도 swap하는 것을 막을 있다. config/elasticsearch.yml 파일에 다음 라인을 추가하면 된다.


bootstrap.mlockall: true


Elasticsearch 시작할 이후, 다음 request 통해서 mlockall 값을 확인함으로써 성공적으로 적용되었는지를 확인할 있다.


curl http://localhost:9200/_nodes/process?pretty


만약 mlockall 값이 false라면 mlockall request 실패했음을 의미한다. 대부분의 경우에 memory lock 권한이 없는 user Elasticsearch 실행했을 경우에 발생한다. Elasticsearch 실행하기 전에 root 계정으로 ulimit -1 unlimited 실행하여 권한을 있다.


다른 가능성 있는 이유로는 temporary directory (일반적으로 /tmp) noexec 옵션으로 mount되었을 경우에 발생한다. 다음과 같이 Elasticsearch 실행하여 새로운 temp directory 지정함으로 해결할 있다.


./bin/elasticsearch -Djna.tmpdir=/path/to/new/dir


[WARNING]

mlockall 이용할 있는 이상의 메모리를 할당하려고 한다면 JVM이나 shell session에서 빠져나갈 것이다.


  • Elasticsearch Settings

Elasticsearch configuration file ES_HOME/config 폴더에 있다. 폴더에는 2개의 파일이 있는데, elasticsearch.yml Elasticsearch 다른 모듈에 대한 설정이, logging.yml에는 Elasticsearch logging 대한 설정이 있다.


Configuration format YAML (http://www.yaml.org/) 이다. 모든 네트워크 기반 모듈들이 바인딩하여 사용하는 주소를 변경하는 예제는 다음과 같다.


network :
   host
: 10.0.0.4


  • Paths

Production 경우, Data Log file Path 변경하고 싶을 것이다.


path:
  logs
: /var/log/elasticsearch
  data
: /var/data/elasticsearch


  • Cluster name

또한, 다른 node 자동으로 cluster 참여할 있도록 production cluster name 주는 것을 잊지 말라.


cluster:
  name
: <NAME OF YOUR CLUSTER>


  • Node name

각각의 node hostname 표시하는데 사용하는 Default node name 변경하고자 경우가 있다. 기본적으로 Elasticsearch node 시작될 , 3000개의 Marvel Character name 리스트 중에서 Random하게 사용한다.


node:
  name
: <NAME OF YOUR NODE>


Configuration styles

내부적으로 모든 설정들은 "namespaced" 설정으로 접근할 있다. 예를 들어, 위의 설정은 node.name으로 접근할 있다. 이것은 다른 형태의 configuration format-JSON 같은- 쉽게 지원할 있음을 의미한다. Configuration format으로 JSON 선호하면, 간단하게 elasticsearch.yml elasticsearch.json으로 변경하고 다음 내용을 추가하면 된다.


{
  
"network" : {
      
"host" : "10.0.0.4"
  
}
}


또한 다음과 같이 ES_JAVA_OPTS elasticsearch command parameter 이용하여 외부에서 설정을 쉽게 제공할 있다.


$ elasticsearch -Des.network.host=10.0.0.4


또다른 옵션은 es. Prefix 대신에 es.default. Prefix 사용하는 것이다. 이것은 configuration file내에 명시적인 설정이 없을 경우에만 default 설정을 사용함을 의미한다.


또다른 옵션은 ${..} notation configuration file안에 사용하는 것이다. 다음과 같이 환경 설정 변수를 사용할 있다.


{
  
"network" : {
      
"host" : "${ES_NET_HOST}"
  
}
}


Configuration file 위치는 system property 사용하여 외부에서 설정할 있다.


$ elasticsearch -Des.config=/path/to/config/file


  • Index Settings

Cluster 생성된 index들은 각자 설정을 가질 있다. 예를 들어, 다음은 기본적인 파일 시스템 기반 대신에 메모리 기반 index 생성한다. (포맷은 YAML / JSON 모두 가능하다.)


$ curl -XPUT http://localhost:9200/kimchy/ -d \
'
index :
   store:
       type: memory
'


Index level 설정은 elasticsearch.yml 파일내 다음과 같이 node level 설정될 있다.

index :
   store
:
       type
: memory


이것은 위에 언급된 configuration으로 시작된 특정 node에서 생성된 모든 index 분명하게 설정되지 않으면 메모리에 index 저장한다는 것을 의미한다. 다시 말하면, node configuration 설정된 것이 무엇이건 간에 index level 재정의가 가능하다는 것이다. 물론, 위의 경우에는 다음과 같은 "collapsed" 설정이 가능하다.


$ elasticsearch -Des.index.store.type=memory


Index level configuration 모든 것은 index module (http://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html) 있다.


  • Logging

Elasticsearch 내부의 logging abstraction 이용하여 log4j 설정을 적용한다. YAML 사용하여 log4j 설정을 간단하게 적용할 있다. (로그 설정 파일은 config/logging.yml 이다.) JSON properties 포맷 또한 지원된다. 자세한 내용은 log4j document (http://logging.apache.org/log4j/1.2/manual.html) 참조하라. 추가로 log4j-extras에서 제공하는 다른 Appender logging class 사용할 있다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/707

01. Installation

Elastic Search/02. Setup 2015/04/23 15:04 용비

섹션에는 elasticsearch 어떻게 설치하고 실행하는지에 대한 정보가 담겨 있다. 아직 다운로드 하지 않았으면, 다운로드 (http://www.elasticsearch.org/download) 하고 설치 문서 (http://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html#setup-installation) 확인하라.


[NOTE]

Elasticsearch apt yum 이용해서 우리의 Repository로부터 설치를 수도 있다. Repository (http://www.elastic.co/guide/en/elasticsearch/reference/current/setup-repositories.html) 섹션을 참고하라.


[Installation]

최종 버전을 다운로드하고 압축 해제 , Elasticsearch 다음 command 실행할 있다.


$ bin/elasticsearch


*nix 시스템 (Unix, Linux) 상에서는 foreground process로 실행된다. Background process 실행하려면 다음과 같이 -d switch 추가하면 된다.


$ bin/elasticsearch -d



*NIX

Elasticsearch shell script 사용하여 여러 features들을 추가할 있다. 첫번째는, 앞서 설명했듯이, foreground / background process 쉽게 실행할 있다.


또다른 특징으로 -X, -D, getopt long style configuration parameter script 직접 전달할 있다. JAVA_OPTS ES_JAVA_OPTS 사용하여 모든 설정을 재정의할 있다. 예를 들면 다음과 같다.


$ bin/elasticsearch -Xmx2g -Xms2g -Des.index.store.type=memory --node.name=my-node


[Java (JVM) version]

Elasticsearch Java 사용하여 빌드 되었다. 실행하기 위해서는 최소한 Java 7 필요하다. 단지 Oracle Java OpenJDK 지원된다. 모든 Elasticsearch node client에는 동일한 버전의 JVM 설치되어 있어야 한다.


Java 8 update 20 이상이나 Java 7 update 55 이상 버전을 설치하기를 권장한다. 이전 버전의 Java 7에서는 index corruption data loss 대한 bug 있다. Elasticsearch java 1.5.0으로 알려진 잘못된 버전으로 실행하면 실행되지 않을 것이다.


사용하는 Java 버전은 JAVA_HOME 환경 변수로 설정할 있다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/706

Elasticsearch 단순하기도 하고 복잡하기도 제품이다. 기본적인 개념이 무엇인지, 내부가 어떻게 생겼는지, REST API 통해서 어떻게 작업을 수행하는지를 공부했다. tutorial 통해서 여러분이 Elasticsearch 무엇인지를 이해하고, 중요하게, 나머지 다른 굉장한 기능들을 통해 많은 시험을 있는 영감을 있기를 바란다.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/705

[Executing Aggregations]

Aggregations 데이터를 group하고 통계를 추출하는 기능을 제공한다. Aggregation 대해서는 SQL GROUP BY SQL aggregate function 거의 같다고 생각하는 것이 가장 쉽다. Elasticsearch에서는 하나의 response 안에 hit 리턴하는 검색과 hit별로 분리된 aggregated result 동시에 실행하는 기능이 있다. 이것은 굉장히 강력하고 효율적인 기능이다. 여러분은 query multiple aggregation 실행하여 간결하고 간단한 API 통해서 네트워크의 빈번한 호출을 피하고, 한번에 두개 혹은 하나의 결과를 받아볼 있다.


다음 에제는 상태별로 모든 account group하고, count 내림차순 정렬된 결과 중에서 top 10개의 state 리턴하는 것을 보여준다.


curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
  "size": 0,
  "aggs": {
   "group_by_state": {
     "terms": {
       "field": "state"
     }
   }
  }
}'


SQL에서는 위의 aggregation 예제는 다음 개념과 유사하다.


SELECT COUNT(*) from bank GROUP BY state ORDER BY COUNT(*) DESC


응답 결과의 부분적인 내용은 다음과 같다.


  "hits" : {
  
"total" : 1000,
  
"max_score" : 0.0,
  
"hits" : [ ]
 
},
 
"aggregations" : {
  
"group_by_state" : {
    
"buckets" : [ {
      
"key" : "al",
      
"doc_count" : 21
    
}, {
      
"key" : "tx",
      
"doc_count" : 17
    
}, {
      
"key" : "id",
      
"doc_count" : 15
    
}, {
      
"key" : "ma",
      
"doc_count" : 15
    
}, {
      
"key" : "md",
      
"doc_count" : 15
    
}, {
      
"key" : "pa",
      
"doc_count" : 15
    
}, {
      
"key" : "dc",
      
"doc_count" : 14
    
}, {
      
"key" : "me",
      
"doc_count" : 14
    
}, {
      
"key" : "mo",
      
"doc_count" : 14
    
}, {
      
"key" : "nd",
      
"doc_count" : 14
    
} ]
  
}
 
}
}


위에서 AL(abama) 21개의 account, 다음으로 TX 17개의 account, ID 15 등등이 있음을 있다. size=0으로 설정하면 response에서 aggregation 결과만 보고 싶은 경우이기 때문에 search hit 보여주지 않는다.


다음 예제는 state별로 account balance 평균을 계산하는 것을 보여준다.

(역시, 내림차순 정렬하여 top 10개만 출력한다.)


curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
  "size": 0,
  "aggs": {
   "group_by_state": {
     "terms": {
       "field": "state"
     },
     "aggs": {
       "average_balance": {
         "avg": {
           "field": "balance"
         }
       }
     }
   }
  }
}'


어떻게 group_by_state aggregation내에 average_balance aggregation 연결했는지 주목하라. 모든 aggregation 이와 같은 공통된 pattern 가지고 있다. 여러분이 데이터로부터 구하고자 하는 독자적인 요약 정보를 추출하는 aggregation내에 연결된 aggregation 가질 있다. 앞에서 수행한 aggregation에서 내림차순으로 average balance 정렬해 보자.


curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
  "size": 0,
  "aggs": {
   "group_by_state": {
     "terms": {
       "field": "state",
       "order": {
         "average_balance": "desc"
       }
     },
     "aggs": {
       "average_balance": {
         "avg": {
           "field": "balance"
         }
       }
     }
   }
  }
}'


다음 예제는 어떻게 우리가 연령대별로, 성별에 따라 group 있는지, 마지막으로 어떻게 연령대별, 성별에 따른 average account balance 구할 있는지를 보여준다.


curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
  "size": 0,
  "aggs": {
   "group_by_age": {
     "range": {
       "field": "age",
       "ranges": [
         {
           "from": 20,
           "to": 30
         },
         {
           "from": 30,
           "to": 40
         },
         {
           "from": 40,
           "to": 50
         }
       ]
     },
     "aggs": {
       "group_by_gender": {
         "terms": {
           "field": "gender"
         },
         "aggs": {
           "average_balance": {
             "avg": {
               "field": "balance"
             }
           }
         }
       }
     }
   }
  }
}'


여기에서 우리가 상세히 다루지 않은 다른 많은 aggregation 기능이 있다. Aggregation reference guide (http://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html) 통해서 많은 내용을 있다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/704

[Executing Filters]

섹션에서 document score (검색 결과의 _score 필드) 대해서는 자세히 다루지 않고 넘어 갔었다. Score 우리가 검색하고자 query document 얼마나 match하는지를 측정한 숫자 값이다. Score 높을수록 적합한 document이고, Score 낮을수록 적합한 document이다.


Elasticsearch 모든 query 적합성 score (점수) 계산을 수행한다. 적합성 점수 (relevance score) 불필요한 경우에 Elasticsearch query-dsl-filter, filter 형태의 다른 기능을 제공한다. Filter 2가지 중요한 이유 때문에, 개념적으로 query 빠르게 수행하도록 최적화 하는 것과 같다.

  • Filter score 계산을 하지 않기 때문에 query보다 빠르다.
  • Filter 반복되는 검색 결과를 memory cache할 수 있기 때문에 query보다 빠르다.

Filter 이해하기 위해서는, query filter 조합한 filtered Query (http://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-filtered-query.html) 대해서 먼저 아는 것이 좋다.


예를 들어, range filter 소개하자면, 값의 range 따라 document filter 있다. 일반적으로 숫자나 날짜별로 filter 적용하여 사용한다.


다음 예제는 20000 30000 사이의 balance 가지는 모든 account 리턴하는 filtered query 사용한 것이다. 다른 말로 하자면, 20000 이상 30000 이하의 balance 가진 account 찾고 싶은 것이다.


curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
  "query": {
   "filtered": {
     "query": { "match_all": {} },
     "filter": {
       "range": {
         "balance": {
           "gte": 20000,
           "lte": 30000
         }
       }
     }
   }
  }
}'


내용을 분석해 보면, filtered query query part match_all query filter part range filter 포함하고 있다. 다른 query query part 대체할 있고, 다른 filter filter part 대체할 있다. 위의 경우에 range filter 모든 document들이 range안에 동일하게 들어오기 때문에 완벽하다. , 모든 document 동일하다.


일반적으로 어떤 filter query 원하는지 결정하는 가장 쉬운 방법은 relevance score (적합성 점수) 신경 쓰는지 스스로에게 물어보는 것이다. Relevance score (적합성 점수) 중요하지 않다면 filter 사용하고, 중요하다면 query 사용하라. SQL 배경지식이 있다면, query filter SELECT WHERE 개념과 유사하다. 비록 filter query보다 조금 유사하지만.


게다가, match_all, match, bool, filtered, range query 이외에도 다른 많은 이용할 있는 query/filter들이 있다. 여기서는 깊이 다루지 않을 것이다. 어떻게 동작하는지에 대한 기본적인 이해를 하고 있기 때문에, 다른 query/filter 배우고 시험하면서 이런 지식을 활용하는데 어렵지는 않을 것이다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/703