|
|
Elastic/Elasticsearch 2016. 3. 16. 16:38
작업 하는 김에 버전 올렸습니다.
git branch)
루씬 한글 형태소 분석기인 arirang analyzer 버전 올렸습니다. Elasticsearch 2.2.0 Lucene 5.4.1 arirang.morph 1.0.3 $ mvn clean package $ bin/plugin install file:/git/elasticsearch-analysis-arirang/target/elasticsearch-analysis-arirang.zip "index": {
"analysis": {
"analyzer": {
"arirang_custom": {
"type": "arirang_analyzer",
"tokenizer": "arirang_tokenizer",
"filter": ["lowercase", "trim", "arirang_filter"]
}
}
}analyze 테스트 방법) $ curl -XGET http://localhost:9200/memebox_deal_idx/_analyze?pretty -d '{
"analyzer":"arirang_analyzer",
"text":"elasticsearch 한국 사용자 그룹입니다."
}'
{
"tokens" : [ {
"token" : "elasticsearch",
"start_offset" : 0,
"end_offset" : 13,
"type" : "word",
"position" : 0
}, {
"token" : "한국",
"start_offset" : 14,
"end_offset" : 16,
"type" : "korean",
"position" : 1
}, {
"token" : "사용자",
"start_offset" : 17,
"end_offset" : 20,
"type" : "korean",
"position" : 2
}, {
"token" : "그룹",
"start_offset" : 21,
"end_offset" : 23,
"type" : "korean",
"position" : 3
} ]
}
사전 reload 방법) $ curl -XGET http://localhost:9200/_arirang_dictionary_reload - 클러스터 재시작 없이 사전 데이터 수정 후 리로드 잘 됩니다. 단, 이미 색인 된 문서들은 재색인 해야 합니다.
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 입니다.
Elastic/Elasticsearch 2016. 3. 16. 10:33
Elasticsearch 2.x 대로 들어 오면서 field 구성 중 눈에 보이는 것들이 있어서 살짝 기록하고 갑니다.
기존에 있던 exists, missing 필드의 경우 _field_names 라는 필드로 대체 된 것 같습니다. 아래 내용 참고하세요.
원문링크)
원문 Snippet) The _field_names field indexes the names of every field in a document that contains any value other thannull. This field is used by the exists and missing queries to find documents that either have or don’t have any non-null value for a particular field.
그리고 추가된 것 중 token_count 라는 필드가 있는데 이건 analyzed field에 대해서 나름 활용이 되지 않을까 싶습니다. 해당 필드에 대해서 multi field를 이용해서 추출된 토큰 수를 기록 할 수 있습니다. 자세한 내용은 아래 참고하세요.
원문링크)
원문 Snippet) A field of type token_count is really an integer field which accepts string values, analyzes them, then indexes the number of tokens in the string.
Elastic/Elasticsearch 2016. 3. 11. 15:36
ElasticON '16에서 support engineer 가 발표한 자료로 보입니다. 여기서 Elasticsearch를 이용하면서 기억 하고 있어야 할 만한 내용들이 있어서 기록해 봅니다. 이미 아시는 분들도 있겠지만 아마도 잘 모르시는 분들이 더 많지 않을까 싶습니다. 개인적으로 예전 Deview 때 제가 발표했던 내용의 근거가 포함되어 있어 기분 좋내요. :)
발표제목) Stories from Support: Top Problems and Solutions
문서첨부)
 thursday-mark-w-chris-e-stories-from-support0problems-solutions-stage-c.pdf
내용 Snippet) Doc Value Caveats • Analyzed strings do not currently support doc_values,which means that you must avoid using such fields for sorting, aggregating, and scripting • Analyzed strings are generally tokenized into multiple terms, which means that there is an array of values • With few exceptions (e.g.,significant terms),aggregating against analyzed strings is not doing what you want • Unless you want the individual tokens,scripting is largely not useful • Big improvement coming in ES2.3 (“keyword” field)
Do You Know Where Your Shards Are At Night • Elasticsearch 1.X defaults to 5 primary, 1 replica • Elasticsearch 2.0 defaults to 2 primary, 1 replica • Increase primaries for higher write throughput and to spread load • 50GB is the rule of thumb max size for a primary shard. More for recovery than performance • Replicas are not backups. Rarely see a benefit with more than 1
Queries • Deeppagination • ES 2.0 has a soft limiton 10K hits per request. Linearly more expensive per shard • Use scan and/or scrollAPI • Leading wildcards • Equivalent to a full table scan(bad) • Scripting • Without parameters • Dynamically(inline) • Unnecessary filter caching (e.g.,exact date ranges down to the millisecond)
Aggregations • Cardinality • Setting the threshold to 40K (or higher) is memory intensive and generally unnecessary • Using in place of search • Searching will be faster • Enormous sizes • Requesting large shard sizes (relative to actual size) • Linearly more expensive per shard touched • Generally unnecessary • Returning hits when you don’t want them
Indexing • Too many shards • If your shards are small (define:small as<5GB) and they outnumber your nodes, then you have too many • Refreshing too fast • This controls “near real time” search • Merge throttling • Disable it on SSDs • Make single threaded on HDDs(see node sizing link) • Not using bulk processing
Elastic/Curator 2016. 3. 8. 11:49
curator를 이용해서 elasticsearch의 index를 관리 할 수 있다는 것은 잘 알려진 내용입니다. 오래된 index를 close 하기 위해 curator를 이용해 보겠습니다.
참고 문서)
원문 예제)
일반적으로 아래와 같은 패턴으로 많이 사용을 하게 됩니다.
$ curator --host localhost --port 9200 close indices --time-unit days --older-than 7 --timestring %Y.%m.%d
이 명령어의 의미는 time series 패턴을 이용해서 7일이 지난 index들을 모두 close 하라는 의미 입니다. 이와 같은 패턴을 사용하기 위해서는 당연히 index name rule이 아래와 같아야 합니다.
# INDEXNAME-YYYY.MM.DD # logstash-2016.03.08
하지만 꼭 이런 패턴으로 index를 생성하지 않을 수도 있기 때문에 다른 방법도 필요해 보입니다. 그럼 어떻게 할 수 있을까요? 아래 flags를 잘 참고하셔서 사용하면 됩니다.
참고 문서)
여기서 prefix 를 이용해서 close 하는 예를 살펴 보겠습니다.
indices name) 아래와 같이 YYYYMMDDHHMI 로 되어 있다고 가정 합니다. logstash-201603081100 logstash-201603081105 logstash-201603081110 logstash-201603081115 logstash-201603081120 logstash-201603081125
명령어) $ curator --host localhost --port 9200 close indices --prefix logstash-20160308110
이와 같이 실행을 하면 11시 00분 부터 11시 09분까지의 인덱스는 모두 close 됩니다. 이외 다른 옵션들도 많으니 잘 참고해서 활용하시길 바랍니다.
Elastic/Curator 2016. 3. 3. 11:20
elasticsearch의 index를 관리하기 위한 매우 유용한 도구 입니다. 저 같은 경우 맥북을 개발장비로 사용하기 때문에 맥에 설치 하는 방법을 기록해 봅니다. 기본적으로는 elastic에서 제공하는 문서를 보고 설치 하시면 됩니다.
참고문서)
Step 1) get-pip.py 다운로드
Step 2) get-pip.py 설치 Collecting pip Downloading pip-8.0.3-py2.py3-none-any.whl (1.2MB) 100% |████████████████████████████████| 1.2MB 372kB/s Collecting wheel Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB) 100% |████████████████████████████████| 69kB 5.4MB/s Installing collected packages: pip, wheel Successfully installed pip-8.0.3 wheel-0.29.0
Step 3) curator 설치 $ sudo pip install elasticsearch-curator==3.4.1
Collecting elasticsearch-curator==3.4.1 Downloading elasticsearch_curator-3.4.1-py2.py3-none-any.whl (44kB) 100% |████████████████████████████████| 45kB 201kB/s Collecting click>=3.3 (from elasticsearch-curator==3.4.1) Downloading click-6.3-py2.py3-none-any.whl (70kB) 100% |████████████████████████████████| 73kB 141kB/s Collecting elasticsearch<2.4.0,>=1.8.0 (from elasticsearch-curator==3.4.1) Downloading elasticsearch-2.3.0-py2.py3-none-any.whl (51kB) 100% |████████████████████████████████| 53kB 163kB/s Collecting urllib3<2.0,>=1.8 (from elasticsearch<2.4.0,>=1.8.0->elasticsearch-curator==3.4.1) Downloading urllib3-1.14-py2.py3-none-any.whl (89kB) 100% |████████████████████████████████| 90kB 232kB/s Installing collected packages: click, urllib3, elasticsearch, elasticsearch-curator Successfully installed click-6.3 elasticsearch-2.3.0 elasticsearch-curator-3.4.1 urllib3-1.14
※ Version Python 2.7.10
Elastic/Elasticsearch 2016. 3. 2. 12:30
그냥 복습 하는 차원에서 기록 합니다.
$ curl -XPUT "http://localhost:9200/INDEX_NAME" -d' { "settings": { ...설정할 정보를 넣으세요... }, "mapping": { ...설정할 정보를 넣으세요... } }
별 내용 없습니다. 그냥 rest api를 이용해서 index 생성 할 때 필요한 설정 정보를 작성하는 틀 정도 입니다. type 정보는 mappings 안에 넣으시면 됩니다. 기본적으로 해당 설정은 지정한 INDEX_NAME 에 한해서 적용되는 것입니다. 별도의 global 설정을 하고 싶으시다면 template 기능을 활용하시기 바랍니다.
참고링크)
Elastic/Elasticsearch 2016. 2. 26. 15:00
synonym 은 아주 유용한 기능 입니다. 하지만 이 기능을 사용하기에 앞서 index time 시 장단점과 search time 시 장단점을 잘 이해하고 사용하시길 추천 드립니다. 관련 내용은 elastic.co에 "The Definitive Guide" 에서 가져왔습니다.
[원문 링크]
[원문 Snippet] Simple ExpansioneditWith simple expansion, any of the listed synonyms is expanded into all of the listed synonyms: "jump,hop,leap" Expansion can be applied either at index time or at query time.
Each has advantages (⬆)︎ and disadvantages (⬇)︎.
When to use which comes down to performance versus flexibility. Simple contraction maps a group of synonyms on the left side to a single value on the right side: "leap,hop => jump" It must be applied both at index time and at query time, to ensure that query terms are mapped to the same single value that exists in the index. This approach has some advantages and some disadvantages compared to the simple expansion approach: - Index size
- ⬆︎ The index size is normal, as only a single term is indexed.
- Relevance
- ⬇︎ The IDF for all terms is the same, so you can’t distinguish between more commonly used words and less commonly used words.
- Performance
- ⬆︎ A query needs to find only the single term that appears in the index.
- Flexibility
⬆︎ New synonyms can be added to the left side of the rule and applied at query time.
For instance, imagine that we wanted to add the word bound to the rule specified previously.
The following rule would work for queries that contain bound or for newly added documents that contain bound: "leap,hop,bound => jump" But we could expand the effect to also take into account existing documents that contain bound by writing the rule as follows: "leap,hop,bound => jump,bound" When you reindex your documents, you could revert to the previous rule to gain the performance benefit of querying only a single term.
Genre expansion is quite different from simple contraction or expansion.
Instead of treating all synonyms as equal, genre expansion widens the meaning of a term to be more generic. Take these rules, for example: "cat => cat,pet",
"kitten => kitten,cat,pet",
"dog => dog,pet"
"puppy => puppy,dog,pet" By applying genre expansion at index time: - A query for
kitten would find just documents about kittens. - A query for
cat would find documents abouts kittens and cats. - A query for
pet would find documents about kittens, cats, puppies, dogs, or pets.
Alternatively, by applying genre expansion at query time,
a query for kitten would be expanded to return documents that mention kittens, cats, or pets specifically. 문서에서 보시면 index time 보다 search time 에 적용하는게 더 이점이 있는 것으로 나옵니다. 그런데 simple expansion 과 contraction 을 적절히 사용한다고 하면 검색 성능이나 품질을 풍성하게 할 수 있지 않을까 생각 합니다.
Elastic/Elasticsearch 2016. 2. 26. 14:48
synonym 구성을 어떻게 하는지 궁금해 하시는 분들이 있을 것 같아 정리해 봅니다.내용은 elastic.co 의 "The Definitive Guide"에서 가져왔습니다.
[원문 링크]
[원문 Snippet] In their simplest form, synonyms are listed as comma-separated values: "jump,leap,hop" If any of these terms is encountered, it is replaced by all of the listed synonyms. For instance: Original terms: Replaced by:
────────────────────────────────
jump → (jump,leap,hop)
leap → (jump,leap,hop)
hop → (jump,leap,hop) Alternatively, with the => syntax, it is possible to specify a list of terms to match (on the left side),
and a list of one or more replacements (on the right side): "u s a,united states,united states of america => usa"
"g b,gb,great britain => britain,england,scotland,wales" Original terms: Replaced by:
────────────────────────────────
u s a → (usa)
united states → (usa)
great britain → (britain,england,scotland,wales) If multiple rules for the same synonyms are specified, they are merged together.
The order of rules is not respected. Instead, the longest matching rule wins.
Take the following rules as an example: "united states => usa",
"united states of america => usa" If these rules conflicted, Elasticsearch would turn United States of America into the terms (usa),(of),
(america). Instead, the longest sequence wins, and we end up with just the term (usa).
두 가지 방법으로 설정 하는 예제가 나와 있습니다.
Case 1) "jump,leap,hop" 과 같이 double quotation 으로 묶는 방법 색인 시 jump 라는 term 이 발생 하게 되면 leap, hop 두 개의 term 이 추가 되어서 색인이 되게 됩니다. 그렇기 때문에 색인 크기가 증가 되는 이슈가 있을 수 있습니다.
Case 2) => 기호를 사용한 양자택일 방법 이 방법은 왼쪽에 있는 term을 오른쪽에 있는 term으로 replacement 하게 됩니다.
Elastic/Elasticsearch 2016. 2. 26. 14:30
synonym 기능을 사용하기 위해서 해당 사전 파일을 엔진에 위치 시켜야 하는데요. 관련해서 경로가 어떻게 되는지 궁금해 하시는 분들도 있을 것 같아 기록해 봅니다.
[원문 링크]
[원문 Snippet] The above configures a synonym filter, with a path of analysis/synonym.txt (relative to the configlocation).
The synonym analyzer is then configured with the filter.
Additional settings are: ignore_case(defaults to false), and expand (defaults to true).
내용 보셔서 아시겠지만, 상대 경로 입니다. elasticsearch 압축 푸시면 config 폴더 경로 아래 analysis 폴더 만들고 그 아래로 synonym.txt 파일이 위치해 있으면 됩니다.
|
