'guide'에 해당되는 글 30건

  1. 2015.12.10 [Elasticsearch - The Definitive Guide] Relevance is Broken!
  2. 2015.12.10 [Elasticsearch - The Definitive Guide] The match Query
  3. 2015.12.09 [Elasticsearch - The Definitive Guide] Ranges
  4. 2015.12.09 [Elasticsearch - The Definitive Guide] Segment Merging
  5. 2015.12.09 [Elasticsearch - The Definitive Guide] Making Changes Persistent
  6. 2015.12.09 [Elasticsearch - The Definitive Guide] Dynamically Updatable Indices
  7. 2015.12.09 [Elasticsearch - The Definitive Guide] Customizing Dynamic Mapping
  8. 2015.12.03 [Elasticsearch - The Definitive Guide] Index Settings
  9. 2015.12.03 [Elasticsearch - The Definitive Guide] Relevance is Broken!
  10. 2015.11.30 [Elasticsearch - The Definitive Guide] What is Relevance?

[Elasticsearch - The Definitive Guide] Relevance is Broken!

Elastic/TheDefinitiveGuide 2015. 12. 10. 12:22

예전에 어느 분이 elasticsearch에서 score 관련 문의를 주셨었는데요.

IDF 값에 대한 global value 를 사용하는지 였습니다.

Elasticsearch에서는 default 설정이 사용하지 않는다 입니다.


서비스와 문서 특징에 따라 다를수는 있지만 저 역시 반드시 global idf 값을 써야 하나 하는 생각이 듭니다.

일단 각설 하고, The Definitive Guide 에 올라온 내용 기록 합니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/relevance-is-broken.html


원문 Snippet)

However, for performance reasons, Elasticsearch doesn’t calculate the IDF across all documents in the index. Instead, each shard calculates a local IDF for the documents contained in that shard.

...중략...

Don’t use dfs_query_then_fetch in production. It really isn’t required. Just having enough data will ensure that your term frequencies are well distributed. There is no reason to add this extra DFS step to every query that you run.


:

[Elasticsearch - The Definitive Guide] The match Query

Elastic/TheDefinitiveGuide 2015. 12. 10. 11:53

Match Query 와 Term Query 가 어떻게 다른지 간단하게 정리하는 차원에서 기록 합니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/match-query.html


Match Query Flow)

1. Check the field type

2. Analyze the query string (term query 로 재실행 됩니다.)

3. Find matching docs

4. Score each doc


Term Query Flow)

1. Find matching docs

2. Score each doc


보시면 아시겠지만 match query 보다 term  query가 수행 단계가 적습니다.

결국 match  query 를 실행 하더라도 term query 로 query rewrite 되기 때문에 검색 서비스 개발 시 잘 판단해서 사용하시면 좋을 듯 합니다.


보통은 front end 에서 smart query 또는 query preprocessing 이라고 해서 query stirng 에 대한 1차 가공 후 실제 검색엔진으로 질의시에는 term query  형태로 사용을 많이 합니다.

:

[Elasticsearch - The Definitive Guide] Ranges

Elastic/TheDefinitiveGuide 2015. 12. 9. 17:45

Date type의 field에 대한 range query example 입니다.

기억력 향상을 위해 기록해 봅니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/_ranges.html


원문 Snippet)

"range" : { "timestamp" : { "gt" : "2014-01-01 00:00:00", "lt" : "2014-01-07 00:00:00" } }


"range" : { "timestamp" : { "gt" : "now-1h" } }


"range" : { "timestamp" : { "gt" : "2014-01-01 00:00:00", "lt" : "2014-01-01 00:00:00||+1M" } }


:

[Elasticsearch - The Definitive Guide] Segment Merging

Elastic/TheDefinitiveGuide 2015. 12. 9. 17:25

알아 두면 매우 좋은 내용입니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/merge-process.html


원문 Snippet)

With the automatic refresh process creating a new segment every second, it doesn’t take long for the number of segments to explode.

...중략...

This is the moment when those old deleted documents are purged from the filesystem. Deleted documents (or old versions of updated documents) are not copied over to the new bigger segment.

...중략...

The merge process... does not interrupt indexing and searching.

...중략...

Once merging has finished, the old segments are deleted



아래는 merge flow 요약 입니다.


1) merge 하기 위한 new segment 를 생성 합니다. (run optimize)

2) deleted mark 된 것들을 제외 하고 신규 segment 로 merge 대상 segment 들이 합쳐 집니다.)

3) 신규 commit point 를 생성 합니다. (merge 대상 segment 는 제거 하고, 신규 segment 와 아직 merge 가 안된 segment 정보만 기록 합니다.)

4) 검색 가능한 상태가 됩니다.

5) merge 가 완료된 segment는 삭제 됩니다.


※ 이 작업은 상당한 비용이(cpu, disk i/o) 발생 하기 때문에 사용시 주의하셔야 합니다.


:

[Elasticsearch - The Definitive Guide] Making Changes Persistent

Elastic/TheDefinitiveGuide 2015. 12. 9. 17:02

per-segment search works 와 더불어 알아 두면 좋을 것 같아 올려봅니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/translog.html


원문 Snippet)

Elasticsearch uses this commit point during startup or when reopening an index to decide which segments belong to the current shard.

...중략...

Elasticsearch added a translog, or transaction log, which records every operation in Elasticsearch as it happens.


아래는 원문에 나와 있는 Making Changes Persistent 에 대한 flow 정리 입니다.


1) write in-memory buffer & translog

2) write new segment file without fsync

3) flush in-memory buffer (run refresh and not yet flush)

4) write in-memory buffer & append translog 

5) write new segment file (run flush)

6) flush in-memory buffer

7) write commit point on disk

8) flush filesystem cache with fsync

9) delete old translog

10) create new translog


기본적으로 refresh 와 flush 는 간단하게 아래와 같이 이해 하시면 됩니다.


- refresh

검색 가능한 상태로 만들어 줍니다.


- flush

fsync 작업을 합니다. (commit point 기록 및 translog 제거)

:

[Elasticsearch - The Definitive Guide] Dynamically Updatable Indices

Elastic/TheDefinitiveGuide 2015. 12. 9. 16:25

Elasticsearch가 lucene 기반으로 만들어진 분산검색엔진 이라는 것은 이미 잘 알고 계실겁니다.

하지만 elasticsearch를 사용하시는 분들중 lucene을 잘 아시는 분들은 그렇게 많이 계시지는 않은것 같아 참고 할 만한 좋은 내용이 있어 올려 봅니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/dynamic-indices.html


원문 Snippet)

[Deletes and Updates]

Segments are immutable, so documents cannot be removed from older segments, nor can older segments be updated to reflect a newer version of a document. Instead, every commit point includes a .del file that lists which documents in which segments have been deleted.

When a document is “deleted,” it is actually just marked as deleted in the .del file. A document that has been marked as deleted can still match a query, but it is removed from the results list before the final query results are returned.

Document updates work in a similar way: when a document is updated, the old version of the document is marked as deleted, and the new version of the document is indexed in a new segment. Perhaps both versions of the document will match a query, but the older deleted version is removed before the query results are returned.


아래는 원문에 나와 있는 per-segment search works 간단 정리 입니다.

1) write in-memory buffer

2) write new segment file from in-memory buffer

3) write commit point (Refresh API on Elasticsearch)

4) flush in-memory buffer

5) searchable


※ 이 내용과 실제 elasticsearch 에서 primary shard 와 replica shard 간 데이터가 sync 되는 것과는 다른 내용입니다.

:

[Elasticsearch - The Definitive Guide] Customizing Dynamic Mapping

Elastic/TheDefinitiveGuide 2015. 12. 9. 15:17

별건 아니고 작은 팁 정도 입니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/dynamic-mapping.html

https://www.elastic.co/guide/en/elasticsearch/guide/current/custom-dynamic-mapping.html


[date_detection 설정]

PUT /my_index { "mappings": { "my_type": { "date_detection": false } } }


dynamic mapping 의 경우 아래 세 가지 옵션을 가집니다.


true
Add new fields dynamically—the default
false
Ignore new fields
strict
Throw an exception if an unknown field is encountered


date_detection 설정의 경우 문서에도 있지만 처음 들어온 데이터가 date type 으로 인식이 되면 이후 데이터가 string 이더라도 date 로 처리가 된다는 이야기 입니다. 그렇기 때문에 에러가 발생을 하게 될 것이구요.


저는 기본적으로 dynamic mapping 은 false 또는 strict 로 구성 하는 것을 추천 드립니다.

이유는 위와 같은 문제도 있고 하고자 하는 것에 대한 투명성을 보장하는게 좋지 않나 생각해서 입니다.

:

[Elasticsearch - The Definitive Guide] Index Settings

Elastic/TheDefinitiveGuide 2015. 12. 3. 17:24

아주 좋은 글 귀가 보여서 이건 기록을 안할래야.. ^^


원문링크)


원문 Snippet)

Elasticsearch comes with good defaults. Don’t twiddle these knobs until you understand what they do and why you should change them.


Elasticsearch는 잘 모르겠다 싶으시면 그냥 default 로 사용하시는게 제일 좋습니다. :)

:

[Elasticsearch - The Definitive Guide] Relevance is Broken!

Elastic/TheDefinitiveGuide 2015. 12. 3. 17:04

동의 하지 않으시는 분들도 있습니다.

하지만 저는 서비스 특성과 요건에 따라 각자 선택할 몫이라고 생각 합니다.


원문링크)


원문 Snippet)

Don’t use dfs_query_then_fetch in production. It really isn’t required. Just having enough data will ensure that your term frequencies are well distributed. There is no reason to add this extra DFS step to every query that you run.


위 글을 가볍게 정리해 보면 이렇습니다.

분산 환경에서 하나의 index를 여러개의 shard로 쪼갰을 때 idf 값에 따라 relevancy 가 달라 질 수 있다는 이야기 입니다.

즉, local idf 값을 사용할 것인지 global idf 값을 사용할 것인지 search_type 이라는 파라미터를 통해서 결정 할 수 있다는 것입니다.


원문 snippet 은 보시면 아시겠지만 dfs 를 쓰지 말라고 하고 있습니다.

이것 역시 trade off 가 있기 때문에 판단은 사용하시는 분이 판단 하시면 됩니다.

relevance 또는 rank 처리에 있어서 custom 하게 하실 경우 크게 중요하지 않을 수도 있구요.

relevance 와 rank 작업이 중요 할 경우 dfs 를 사용해야 할 필요도 있습니다.


이런 것들도 similarity 기법을 뭘 사용할 것인지에 따라 달라 질 수 있기때문에 반드시라기 보다 경우에 따라 잘 사용하시면 좋겠습니다.


저는 개인적으로 그냥 dfs 빼고 사용해도 크게 무리는 없지 않나 생각 합니다.

Elasticsearch에서도 default search_type 은 query_then_fetch 로 적용 되어 있습니다.


dfs를 사용했을 때와 사용하지 않았을 때 검색 질의에 대한 성능적 차이가 있습니다.

다만, 규모가 작은 경우 별 차이는 없습니다. ㅡ.ㅡ;;

:

[Elasticsearch - The Definitive Guide] What is Relevance?

Elastic/TheDefinitiveGuide 2015. 11. 30. 17:10

relevance 에 대한 이야기를 하려고 기록 하는 것은 아닙니다.

다만 debugging 파라미터 중 주의 해서 사용 하셔야 하는 내용이 있어 공유 차원에서 기록해 봅니다.


[원문링크]


[원문 Snippet]

Producing the explain output is expensive. It is a debugging tool only. Don’t leave it turned on in production.


[Track score & explain]

- track score 의 경우 sorting 시 _score 이외 field 를 이용해서 sort 하고자 할 때 문서에 대한 relevance와 함께 조합을 원한다면 이 옵션을 true 로 켜야 합니다. 다만, 이 설정의 경우 연산 비용이 높기 때문에 필요한 경우가 아니라면 주의해서 사용을 하셔야 합니다.

- explain 옵션의 경우 _score 에 대한 계산 결과가 어떻게 해서 나오게 되었는지 자세한 explain 을 넘겨 주는 기능으로 역시 debugging 용으로만 사용을 하시고, 운영 환경에서는 off 로 설정해서 사용 하셔야 합니다.


즉, 둘다 시스템 자원 소모가 크기 때문에 사용에 주의 해서 사용 하라는 이야기 입니다.

: