|
|
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 파일이 위치해 있으면 됩니다.
Elastic/Elasticsearch 2016. 2. 23. 16:31
2.X 올라가면서 전체 API를 살펴 보지 못했는데 형분기 관련 구성을 하다가 눈에 확 들어 오는게 있어서 기록해 봅니다.
원문링크)
원문스크랩) Named delimited_payload_filter. Splits tokens into tokens and payload whenever a delimiter character is found.
Example: "the|1 quick|2 fox|3" is split by default into tokens the, quick, and fox with payloads 1, 2, and 3 respectively.
Parameters:
delimiter Character used for splitting the tokens. Default is |. encoding The type of the payload. int for integer, float for float and identity for characters. Default is float.
예전에 문서가 가지는 별도의 rankin, boostin, keyword score 등등 검색 로그를 기반으로 문서 가중치, 랭킹, 추천 데이터를 생성해서 문서에 반영해서 질의 시점에 사용을 했었는데요. 이 token filter 가 초기 0.90 사용할때 없어서 별도로 script plugin을 만들어서 사용했었습니다. 그렇다 보니 string 연산을 script 내부에서 하니까 성능적으로 문제가 있었는데요. 이 기능을 사용하면 성능 이슈 없이 쉽게 구현할 수 있을 것 같습니다.
1.3 부터 들어온 API 인것 같은데 그 동안 왜 몰랐나 싶내요. 한번 실험해 보고 결과도 공유 하도록 하겠습니다.
Elastic/Beats 2016. 2. 12. 11:08
beats 1.1.0 이 릴리즈 되면서 공지된 내용입니다.
원본링크)
내용요약) [ASIS] Beats -> Logstash -> Redis -> Logstash -> Elasticsearch
[TOBE] Beats -> Redis/Kafka -> Logstash -> Elasticsearch
beats 랑 logstash는 매우 비슷한 기능을 제공하고 있습니다. 아마도 elastic 내부에서도 고민이 될 것 같기도 한데요. beats 와 logstash 를 다 사용해본 개인적 입장에서는 각각의 특성에 맞춰 사용하면 되지 싶습니다. 단순하게 비교하면 성능은 beats 가 좋은것 같고 다양성과 활용도 측면에서는 logstash가 좋은것 같습니다.
|
