'2017/07'에 해당되는 글 12건

  1. 2017.07.31 [Lucene] SynonymFilter -> SynonymGraphFilter + FlattenGraphFilter
  2. 2017.07.31 [미미박스 검색이야기] 뷰티풀 솔루션 (Beautyfull Solution)
  3. 2017.07.28 [미미박스 검색이야기] Quick Search - 퀵서치
  4. 2017.07.25 [Arirang] compounds.dic 사전
  5. 2017.07.20 [한글유니코드] 한글자모와 호환용 한글자모 코드
  6. 2017.07.19 [Logstash] input file plugin 에 대해서 알아 봅니다.
  7. 2017.07.17 [esquery-proxy] Elasticsearch 용 RESTful API Gateway/Proxy
  8. 2017.07.17 [Elasticsearch] Multi Search API 사용
  9. 2017.07.13 [Elasticsearch] post_filter
  10. 2017.07.13 [Elasticsearch] doc, _source, stored_fields, script_fields 간단 정리

[Lucene] SynonymFilter -> SynonymGraphFilter + FlattenGraphFilter

ITWeb/검색일반 2017. 7. 31. 18:37

오늘 뭐 좀 보다가 그냥 공유해 봅니다.
https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-synonym-tokenfilter.html


lucene 6.6 에서는 SynonymFilter@Deprecated 되어 있습니다.

대체 filter 는 글에도 나와 있지만 SynonymGraphFilter 인데요.

재밌는건 이넘은 search time 에서 동작 하는 거라 index time 에는 여전히 SynonymFilter 또는 FlattenGraphFilter 를 사용해야 한다는 점입니다.

아직 깊게 분석해보지 않아서 ^^; 


간만에 lucene 코드 까서 이것 저것 테스트 해보니 재밌내요.

그냥 참고 하시라고 올려봤습니다.


:

[미미박스 검색이야기] 뷰티풀 솔루션 (Beautyfull Solution)

ITWeb/미미박스검색이야기 2017. 7. 31. 16:03

2017년 7월 31일.

고객의 고민 해결을 위한 서비스를 이커머스 회사에서 이렇게 해냅니다. ^^


물건을 팔기 위함이 목적이 아닌 고객의 고민을 해결해 드리기 위해 기획하고 만든 서비스 입니다.

아직 부족한 점이 많지만 고객님들의 고민이 해결 되는 그날까지 최선을 다 해보겠습니다.


경험해 보기)

https://m.search.memebox.com/memebox/solution/home


검색어 입력 방법)

일반적인 얼굴 부위에 대한 메이크업 고민, 피부 트러블에 대한 고민, 스킨케어에 대한 고민을 입력해 주시면 됩니다.


예)

"얼굴이 너무 커요"

"유분이 많아서 화장이 무너져요"



※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.


:

[미미박스 검색이야기] Quick Search - 퀵서치

ITWeb/미미박스검색이야기 2017. 7. 28. 16:35


기능 적용한지 좀 되었는데 이제야 홍보 합니다. ^^;


퀵서치라는 기능은 기본적으로 모바일 환경에서 검색어를 입력하지 않고 검색 필터 기능을 활용해서 쉽게 원하는 조건의 상품을 검색해서 볼 수 있도록 제공하기 위해 만들어 졌습니다.


더불어 해당 영역은 검색 이외 "바로가기" 기능이나 특정 페이지로 랜딩 시키기 위한 용도로도 활용이 가능 합니다.


구경하기)

http://m.search.memebox.com/





※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.


:

[Arirang] compounds.dic 사전

ITWeb/검색일반 2017. 7. 25. 12:16

또 기억이 나지 않아 기록 합니다.


arirang 에서 많이 사용하는 사전중에 복합명사 사전이 있습니다.

compounds.dic 이라는 사전 인데요.


구조는 이렇습니다.

분해전단어:분해후단어1,분해후단어2,...,분해후단어N:DBXX

분해전단어에 하여(다)동사, 되어(다)동사 가 붙을 수 있는지 확인 하셔야 합니다.


예)

객관화:객관,화:1100


이와 같이 된 이유는

객관화하다

객관화되다

가 되기 때문입니다.


참고)

http://krdic.naver.com/search.nhn?query=%EA%B0%9D%EA%B4%80%ED%99%94&kind=all


:

[한글유니코드] 한글자모와 호환용 한글자모 코드

ITWeb/개발일반 2017. 7. 20. 18:01

한글 유니코드를 이용해서 한글 자모 분리에 사용하게 됩니다.

일반 한글자모 코드와 호환용 한글자모 코드가 있는데요.


제가 기존에 구현했던건 호환용 코드였습니다.

그러다 보니 자모만 구성된 처리에 있어서 약간의 문제가 있었습니다.

이번에 한글자모 코드로 변경 하면서 혹시라도 필요 하신 분들이 계시거나 제가 기억 못할까봐 기록해 봅니다.


참고문서)

https://namu.wiki/w/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C

https://namu.wiki/w/%ED%95%9C%EA%B8%80%20%EC%9E%90%EB%AA%A8



한글자모 기반 유니코드)


  // {'ㄱ', 'ㄲ', 'ㄴ', 'ㄷ', 'ㄸ', 'ㄹ', 'ㅁ', 'ㅂ', 'ㅃ', 'ㅅ', 'ㅆ', 'ㅇ', 'ㅈ', 'ㅉ', 'ㅊ', 'ㅋ', 'ㅌ', 'ㅍ', 'ㅎ'}

  private final char[] CHOSUNG =

    {0x1100, 0x1101, 0x1102, 0x1103, 0x1104, 0x1105, 0x1106, 0x1107, 0x1108, 0x1109, 0x110A, 0x110B, 0x110C, 0x110D, 0x110E, 0x110F, 0x1110, 0x1111, 0x1112};


  // {'ㅏ', 'ㅐ', 'ㅑ', 'ㅒ', 'ㅓ', 'ㅔ', 'ㅕ', 'ㅖ', 'ㅗ', 'ㅘ', 'ㅙ', 'ㅚ', 'ㅛ', 'ㅜ', 'ㅝ', 'ㅞ', 'ㅟ', 'ㅠ', 'ㅡ', 'ㅢ', 'ㅣ'}

  private final char[] JUNGSUNG =

    {0x1161, 0x1162, 0x1163, 0x1164, 0x1165, 0x1166, 0x1167, 0x1168, 0x1169, 0x116A, 0x116B, 0x116C, 0x116D, 0x116E, 0x116F, 0x1170, 0x1171, 0x1172, 0x1173, 0x1174, 0x1175};


  // {' ', 'ㄱ', 'ㄲ', 'ㄳ', 'ㄴ', 'ㄵ', 'ㄶ', 'ㄷ', 'ㄹ', 'ㄺ', 'ㄻ', 'ㄼ', 'ㄽ', 'ㄾ', 'ㄿ', 'ㅀ', 'ㅁ', 'ㅂ', 'ㅄ', 'ㅅ', 'ㅆ', 'ㅇ', 'ㅈ', 'ㅊ', 'ㅋ', 'ㅌ', 'ㅍ', 'ㅎ'}

  private final char[] JONGSUNG =

    {0x0000, 0x11A8, 0x11A9, 0x11AA, 0x11AB, 0x11AC, 0x11AD, 0x11AE, 0x11AF, 0x11B0, 0x11B1, 0x11B2, 0x11B3, 0x11B4, 0x11B5, 0x11B6, 0x11B7, 0x11B8, 0x11B9, 0x11BA, 0x11BB, 0x11BC, 0x11BD, 0x11BE, 0x11BF, 0x11C0, 0x11C1, 0x11C2};



호환용 한글자모 기반 유니코드)


  // {'ㄱ', 'ㄲ', 'ㄴ', 'ㄷ', 'ㄸ', 'ㄹ', 'ㅁ', 'ㅂ', 'ㅃ', 'ㅅ', 'ㅆ', 'ㅇ', 'ㅈ', 'ㅉ', 'ㅊ', 'ㅋ', 'ㅌ', 'ㅍ', 'ㅎ'}

  private final char[] CHOSUNG =

    {0x3131, 0x3132, 0x3134, 0x3137, 0x3138, 0x3139, 0x3141, 0x3142, 0x3143, 0x3145, 0x3146, 0x3147, 0x3148, 0x3149, 0x314a, 0x314b, 0x314c, 0x314d, 0x314e};


  // {'ㅏ', 'ㅐ', 'ㅑ', 'ㅒ', 'ㅓ', 'ㅔ', 'ㅕ', 'ㅖ', 'ㅗ', 'ㅘ', 'ㅙ', 'ㅚ', 'ㅛ', 'ㅜ', 'ㅝ', 'ㅞ', 'ㅟ', 'ㅠ', 'ㅡ', 'ㅢ', 'ㅣ'}

  private final char[] JUNGSUNG =

    {0x314f, 0x3150, 0x3151, 0x3152, 0x3153, 0x3154, 0x3155, 0x3156, 0x3157, 0x3158, 0x3159, 0x315a, 0x315b, 0x315c, 0x315d, 0x315e, 0x315f, 0x3160, 0x3161, 0x3162, 0x3163};


  // {' ', 'ㄱ', 'ㄲ', 'ㄳ', 'ㄴ', 'ㄵ', 'ㄶ', 'ㄷ', 'ㄹ', 'ㄺ', 'ㄻ', 'ㄼ', 'ㄽ', 'ㄾ', 'ㄿ', 'ㅀ', 'ㅁ', 'ㅂ', 'ㅄ', 'ㅅ', 'ㅆ', 'ㅇ', 'ㅈ', 'ㅊ', 'ㅋ', 'ㅌ', 'ㅍ', 'ㅎ'}

  private final char[] JONGSUNG =

    {0x0000, 0x3131, 0x3132, 0x3133, 0x3134, 0x3135, 0x3136, 0x3137, 0x3139, 0x313a, 0x313b, 0x313c, 0x313d, 0x313e, 0x313f, 0x3140, 0x3141, 0x3142, 0x3144, 0x3145, 0x3146, 0x3147, 0x3148, 0x314a, 0x314b, 0x314c, 0x314d, 0x314e};


※ Java 로 코드 변환 시 낱자로 사용하게 되면 한글자모 기반 유니코드가 아닌 호환용 한글자모 기반 유니코드를 사용하게 됩니다.

:

[Logstash] input file plugin 에 대해서 알아 봅니다.

Elastic/Logstash 2017. 7. 19. 13:25

가장 많이 사용하고 있는 logstash input plugin 중에 하나라고 생각 합니다.

저 역시 현업에서 제일 많이 사용하고 있는 plugin 이기도 합니다.


elastic reference 문서를 보시면 설명이 잘 나와 있습니다.

하지만 신뢰 할 수 없는 기억력으로 인해서 한번 작성해 봅니다.


이미 많은 분들이 input file plugin 에 대해서 많은 자료들을 공유해 주셨기 때문에 구글링 몇 번 해보시면 좋은 정보를 얻으실 수 있습니다.


참고문서)
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html


logstash input file 기본 동작은 ruby-filewatch를 이용한 tail 입니다. 


주요 설정 정보)

1. start_position

이 설정은 logstash 실행 시 읽기 작업에 대한 수행 정보를 정의 합니다.

beginning 과 end 설정은 2번 sincedb 파일이 있고 없고에 따라 동작이 다르다고 생각 하시면 됩니다.

즉, sincedb 에 offset 정보가 있으면 해당 offset 부터 읽게 되고 없으면 beginning, end 설정 동작 방식으로 동작 합니다.

beginning 은 처음(이전) 부터 읽어 들이고, end 는 가장 최근 부터 읽어 들이게 됩니다.


결국, 데이터의 유실 없이 데이터를 읽기 위해서는 beginning 으로 설정 하셔야 합니다.

default value 는 end 입니다.


2. sincedb

이건 설정은 아니고 sincedb 파일에 대한 내용입니다.

logstash input file 을 사용하게 되면 sincedb 파일에 어디까지 읽었는지 정보를 기록하게 됩니다.

reference 문서를 보시면 sincedb 에 기록하는 정보에 대해서 설명이 자세히 나와 있습니다.


Sincedb files are text files with four columns:


The inode number (or equivalent).

The major device number of the file system (or equivalent).

The minor device number of the file system (or equivalent).

The current byte offset within the file.


$ cat .sincedb_8d6238d5255f464e564ecdb307fe0c0c

7341423 0 51713 67247655


sincedb_path 를 설정 하지 않을 셨을 경우는 user home directory 를 확인해 보시거나,

~/logstash-5.5.0/data/plugins/inputs/file/ 을 확인해 보시면 됩니다.


#pick SINCEDB_DIR if available, otherwise use HOME

sincedb_dir = ENV["SINCEDB_DIR"] || ENV["HOME"]

※ .sincedb 작성 시 overwrite 인지 append 인지 확인 후 공유 드리겠습니다. ㅡ.ㅡ;

미쳐 확인을 못했내요.

->

input file 을 여러개 등록 하면 sincedb 가 여러개 생성이 됩니다.

참고 파일은 filewatch 소스코드를 보시면 되시겠습니다.

($ ~elastic/logstash-5.5.0/vendor/bundle/jruby/1.9/gems/filewatch-0.9.0/lib/filewatch)


input file 을 여러개 등록 하면 sincedb 에 inode 가 다른게 여러게 생성 됩니다.

즉, overwrite(update) 이라고 보시면 되겠습니다.

위에 잘못 설명한 부분은 확인 없이 그냥 동작 하고 있는 것만 가지고 작성을 하다 보니 놓친 부분 입니다. 죄송합니다.

기존에 logstash 가 처리 하고 있는 log file 자체의 변경이 발생 하였을 경우 기 생성된 sincedb 에 row가 추가 되면서 변경된 log file 의 inode 값과 offset 정보가 추가 되게 됩니다.

- 파일이 삭제 된 후 다시 생성 된 경우가 대표적인 예가 되겠습니다.


189699226 -rw-r--r--  1 henry  staff  105  7 20 15:03 file.log

$ rm -f file.log

189766986 -rw-r--r--  1 henry  staff  120  7 20 15:04 file.log


$ cat .sincedb_27eb92c828fb885f9741fac9e538c0e1

189699226 1 4 285

189766986 1 4 150


3. sincedb_write_interval

이 설정은 logstash 가 열심히 일을 하고 어디까지 일을 했는지 주기적으로 기록하도록 하는 주기를 작성 하게 됩니다.

설정 주기가 너무 길게 되면 logstash가 비정상 종료 후 재 실행 되었을 때 데이터가 중복으로 입력 될 수도 있으니 적절한 주기를 찾아서 설정 하는게 중요 합니다.


현재 inode 파일의 읽어 들인 offset 정보를 sincedb 에 기록 하게 됩니다.

default value 는 15초로 되어 있습니다.


4. stat_interval

이 설정은 logstash 가 읽어야 하는 로그 파일에 새로운 로그가 추가 되었는지 확인하기 위한 주기를 설정 하게 됩니다.

reference 문서에서는 아래와 같이 설명 하고 있습니다.

How often (in seconds) we stat files to see if they have been modified. Increasing this interval will decrease the number of system calls we make, but increase the time to detect new log lines.


system call 을 줄일 것인지 빠르게 신규 로그 감지 할 것인지 결정을 하셔야 합니다.

default value 는 1초 입니다.


5. discover_interval

이 설정은 filename pattern 을 이용해서 신규 로그 파일이 추가 되었는지 확인 하기 위한 주기를 설정 하게 됩니다.

 default value 는 15초 입니다.


여기까지 알아 두면 좋은 설정들은 이렇습니다.

이를 기반으로 샘플 설정을 작성해 보면 아래와 같습니다.


input {

  file {

    path => "/XXXX/logs/test-file.log"

    start_position => "beginning"

  }

}


결국 기본 설정으로 돌려도 크게 무리는 없습니다.

다만, 생성되는 로그 파일의 크기와 worker, queue 설정 크기에 따라 값들을 최적화 하시면 됩니다.

왜냐면 사용하시는 환경 마다 다 다르기 때문이고, 환경에 맞춰서 튜닝을 할 수 밖에 없기 때문 입니다.


3, 4, 5 번에 대한 테스트는

3번은 설정 변경 하시면서 sincedb 값이 바뀌는 걸 보시면 됩니다.

4번은 설정 변경 하시면서 output  으로 언제 전달 되는지 보시면 됩니다.

5번은 설정 변경 하시면서 log file을 rotate 해보시면 됩니다.


여기서는 그냥 4번 초간단 테스트 예제만 보여 드리겠습니다.


1. log file 을 생성하고 해당 파일에 log를 기록 합니다.

while true;
do

DATE=$(date '+%Y%m%d%H%M%S');

echo $DATE >> /XXXX/logs/test-file.log;

cat test-file.log;

sleep 2;

done

코드 보셔서 아시겠지만 2초 마다 datetime  을 file.log 에 기록하는 스크립트 입니다.


2. logstash 를 실행 시킵니다.

[file.config]

input {

  file {

    path => "/XXXX/logs/test-file.log"

    start_position => "beginning"

    stat_interval => 30

  }

}


output {

  stdout {

    codec => "rubydebug"

  }

}


$ bin/logstash -f ./config/file.conf --config.reload.automatic


이렇게 하시면 30초 마다 file.log 에 기록된 정보를 읽어 오게 됩니다.

참 쉽죠잉.


여기까지 logstash input file 에 대한 설명이였는데요.

도움이 되셨다면 좋겠습니다.


:

[esquery-proxy] Elasticsearch 용 RESTful API Gateway/Proxy

ITWeb/검색일반 2017. 7. 17. 19:01

Elasticsearch 를 서비스 용도로 많은 분들이 사용하고 계시는 것으로 압니다.

저 처럼 Java API를 사용하고 계신 분들도 계실 테고 RESTful API 를 사용하고 계신 분들도 계실 것으로 압니다.

그냥 버전 업그레이도 해야 하고 해서 재미 삼아 가볍게 만들어 보았습니다.

관련해서 

- 단순 기능 동작 유무만 확인했습니다. (잘 됩니다.)

- 성능 테스트 하지 않았습니다.

- 안정성 테스트 하지 않았습니다.

그래서 가져다 막 고쳐서 사용하시면 좋겠습니다. 


일단 만들게 된 동기는

- Search 와 Aggregation 에 대해서 사용할 목적으로 만들었습니다.

- Elasticsearch JAVA API 버전 관리에 대한 유지보수 비용을 절감 해야 했습니다.

- Elasticsearch Cluster 에 대한 Version Upgrade 도 수행 해야 했습니다.

- Multi Cluster 에 대한 Concurrent 처리가 가능 해야 했습니다.


프로젝트 코드를 보시면 아시겠지만 매우 간단 합니다.


사용한 Framework)

- SpringMVC + Maven Project

- pom.xml  내 dependency 참고 하시면 됩니다.


지원 가능한 API)

- Elasticsearch에서 제공하는 거의 모든 RESTful API 를 제공 합니다.

- HTTP POST 만 구현해 놨기 때문에 POST 를 지원하지 않는 API 는 동작 하지 않습니다.

- 조만간 시간 나는데로 추가해 보겠습니다.

- Single Request 뿐만 아니라 Multi Request 도 지원 합니다.

- Single Cluster 뿐만 아니라 Multi Cluster 로 Request 를 보낼 수 있습니다.

-  서로 다른 Version 의 Cluster 라도 상관 없습니다.


Single Request Example)

[WAS Endpoint]

http://localhost:8080/query


[Method]

POST RAW


[Request Body]

{

  "target":"http://{YOUR-CLUSTER}/{YOUR-INDEX}/_search",

  "query":{}

}

- target

-  요청할 Elasticsearch Cluster 의 RESTful Endpoint 를 작성 하시면 됩니다.

- {YOUR-INDEX} 는 alias, single index, multi index  모두 사용 가능 합니다.

- query

- 기존에 사용하시던 QueryDSL 문을 그대로 넣어 주시면 됩니다.

- match_all  query 가 실행 됩니다.


Multi Request Example)

[WAS Endpoint]

http://localhost:8080/mquery


[Method]

POST RAW


[Request Body]

[

{

  "target":"http://{YOUR-CLUSTER1}/{YOUR-INDEX1}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER1}/{YOUR-INDEX2}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER2}/{YOUR-INDEX1}/_search",

  "query":{}

},

{

  "target":"http://{YOUR-CLUSTER2}/{YOUR-INDEX2}/_search",

  "query":{}

}

]


 Multi Request 의 경우 _msearch API 와 비슷 하게 동작은 합니다.

다만, _msearch의 경우 서로 다른 클러스터간에 통신은 지원 하지 않습니다.



추가 Parameters)

- routing

이 기능은 특정 key 를 가지고 문서를 저장 하기 위한 대상 shard 를 지정 하기 위해 사용 합니다.

문서 저장 시 해당 key 에 대한 Grouping 이나 Classify 를 위해 사용 합니다.

자세한 내용은 Elastic 사의 Reference 문서를 참고하세요. (클릭)

- preference

이 기능은 검색 질의 시 아주 유용하게 활용이 가능 합니다.

특정 shard 를 지정 할 수도 있고 질의 하고 싶은 node 를 선택 할 수도 있습니다.

자세한 내용은 Elastic 사의 Reference 문서를 참고하세요. (클릭)


Github Repository)

https://github.com/HowookJeong/esquery-proxy

:

[Elasticsearch] Multi Search API 사용

Elastic/Elasticsearch 2017. 7. 17. 12:48

2.X 랑 5.X 랑 크게 바뀐 부분은 없습니다.

다만 5.X 에서는 template 지원도 함께 됩니다.


참고문서)

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-multi-search.html


Multi Search API를 얼마나 많은 분들이 사용하고 계신지는 잘 모르겠습니다.

이 API 를 한 줄로 정의 하면 "통합 검색 API" 라고 할 수 있습니다.

뭐 동의 하지 않으시는 분들이 계시다면 어쩔수 없구요.


설명을 풀어서 하면, 서로 다른 query 를 하나의 index 에 질의 하거나 하나의 query 를 서로 다른 index 로 질의 할 때 사용 하시면 유용 합니다.


Case 1)

Single Query + Multi Index


Case 2)

Multi Query + Single Index


Case 3)

Multi Query + Multi Index


위 참고문서 에서는 Request 에 대한 내용은 나와 있지만 실제 Response 에 대한 예시는 나와 있지 않아 실제 실행 보지 않고서는 어떻게 결과가 나올지 모르실 수도 있습니다.

(사실 상상은 되실거예요.)


아래는 제가 테스트로 하나의 클러스터에 "Case 3" 으로 실행한 결과 입니다.


Request API)

Endpoint : http://xxxx/_msearch

Method : POST (raw)


Request Query)

{"index":"service_product"}

{"query":{"match_all":{}},"from":0,"size":1}

{"index":"service_item"}

{"query":{"term":{"title":{"value":"틴트"}}},"from":0,"size":1}


Response Data)

{

    "responses": [

        {

            "took": 1,

            "timed_out": false,

            "_shards": {

                "total": 1,

                "successful": 1,

                "failed": 0

            },

            "hits": {

                "total": xxxxxx,

                "max_score": 1,

                "hits": [

                    {

                        "_index": "service_product_201707171215",

                        "_type": "deal",

                        "_id": "7510",

                        "_score": 1,

                        "_source": {

                        ... 생략 ...

                        }

                    }

                ]

            }

        },

        {

            "took": 1,

            "timed_out": false,

            "_shards": {

                "total": 1,

                "successful": 1,

                "failed": 0

            },

            "hits": {

                "total": xxxxxx,

                "max_score": 7.0183215,

                "hits": [

                    {

                        "_index": "service_item_201707171215",

                        "_type": "item",

                        "_id": "1170617",

                        "_score": 7.0183215,

                        "_source": {

                            ... 중략 ...

                            "title": "라네즈 투톤틴트바 No.3 2g 틴트민트",

                            ... 중략 ...

                        }

                    }

                ]

            }

        }

    ]

}


결과적으로 보면, 검색엔진에서 해당 연산과 실행을 하실지 아니면 별도 API Gateway 같은 WAS 에서 연산과 실행을 하실지에 대한 문제로 트래픽과 용량을 잘 산정 하셔서 사용하시면 매우 유용하리라 생각 합니다.

(너무 오래 전에 비슷한 내용을 올린 것 같아 5.5 릴리즈 기념으로 한번 더 복습해 봤습니다.)


:

[Elasticsearch] post_filter

Elastic/Elasticsearch 2017. 7. 13. 15:08

§ Elasticsearch Reference 5.5


https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-post-filter.html


한 줄 요약)

모든 action 완료 후 결과 내 재검색 수행 후 결과를 리턴 합니다.


이전 글 참고)

[Elasticsearch] aggregations 사용 시 filter 의 차이점.


:

[Elasticsearch] doc, _source, stored_fields, script_fields 간단 정리

Elastic/Elasticsearch 2017. 7. 13. 14:42

§ Elasticsearch Reference 5.5.0


https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-source-filtering.html


1. doc

가장 빠름

한번 읽힌 정보는 memory에 cache 됨

single term field 또는 not analyzed field 에 대해서 


2. _source

매우 느림

매번 파싱하고 읽어 들임


3. stored_fields

field mapping 시 stored 설정이 된 field만 사용이 가능 함

역시 느림

추천 하지 않음


4. script_fields

: