세상의 모든 Software 지식을 정리

이유는 디스크 용량이 5%이하인 경우 자동으로 false처리하게 된다. 그러므로 두가지 방법이 있는데 첫 번째, elasticsearch.yml파일 안에 cluster.routing.allocation.disk.threshold_enabled: false 처리한다. 해당 인덱스 정보를 확인한 결과 GET activitylog-index/_settings read_only_allow_delete : true인 것을 볼 수 있다. 이를 해결하려면, PUT activitylog-index/_settings {   "index": {     "blocks" : {       "read_only_allow_delete": "false"     }   } }

앨리어스가 하나의 색인을 가리키고 있을 경우, 라우팅과 함께 사용한다면 쿼리 요청이나 색인 시점에 자동으로 라우팅 값을 적용시키는 효과를 얻을 수도 있다. 예) POST /_aliases {   "actions" : [     {       "add" : {         "index" : "get-together",         "alias" : "denver-events",         "filter" : {           "term" : {             "name" : "denver"           }         },         "routing" : "denver"       }     }   ] } * denver-events 앨리어스를 사용하여 모든 문서를 조회 POST /denver-events/_search?pretty {   "query" : {     "match_all" : {}   },   "fields" : [     "name"   ] }

search shards API를 통해 검색 요청이 어느 샤드에서 수행될지 확인할 수 있다. 예) GET get-together/_search_shards?pretty GET get-together/_search_shards?pretty&routing=denver 위와같이 routing값이 denver인 녀석만 조회할 경우 특정 샤드에서만 수행하게 된다 이처럼, 한 색이네 두개의 샤드가 존재하고, 라우팅 값으로 denver를 입력한 경우, 샤드 1에서만 검색은 수행되는 것을 알 수 있다. 즉, 검색이 수행되어야 할 대상이 되는 데이터를 절반으로 줄인것이라고 볼 수 있다. 라우팅은 샤드 수가 많은 색인을 다룰 떄 유용하다. 하지만 라우팅이 항상 필요한 것은 아니다. 떄로는 이를 통해 더 효과적으로 확장성을 활용할 수 있다고 생각할 수 있으며 언제나 테스트를 통해 검증해보아야 한다.

자식 문서가 부모 문서와 같은 샤드에 있는 것이, 다른 샤드에 있을 때 보다 검색 성능이 더 좋을 것이다. 라우팅이란 이처럼 문서를 특정 샤드에 위치시킬 수 있는 역할을 한다. 보통 색인시 문서의 ID값을 해싱하여 해당 문서를 샤드에 색인하게 된다. 하지만 라우팅 값을 이용하면 해당 routing값을 해싱하여 샤드에 색인하게 된다. 1. 왜 라우팅을 사용해야 하는가? 라우팅을 사용하지 않을 경우, 엘라스틱서치는 문서를 여러 샤드들에 균등하게 분포시킬 것이다. 그렇다면 왜 라우팅을 사용해야 할까? 그 이유는 커스텀 라우팅은 같은 라우팅 값을 공유하는 문서들을 한 샤드에 저장할 수 있도록 하기 때문이다. 이 문서들이 같은 색인에 존재할 경우, 쿼리에 라우팅 값을 지정하여 요청이 색인의 특정 샤드들에 대해서만 수행되도록 할 수 있다. 1-1. 라우팅 전략 라우팅은 두 가지 영역에서의 고민이 필요하다. 먼저 문서를 색인하는 시점에 좋은 적절한 라우팅 값을 선택해야 하고, 쿼리 시점에 이를 재활용 할 수 있어야 한다. 만약 적은 분포를 가지는 다른 값을 라우팅 값으로 선택하고자 했다면, 색인 내의 샤드 간에 불균등한 분포를 이루게 될수 있다. 만약 라우팅 값의 경우의 수가 세 가지뿐이라면, 모든 문서들은 최대 세개의 샤드에 걸쳐 분포하게 될 것이다. 색인 내의 여러 샤드에 걸쳐 데이터를 분포 시키기 위해서는 충분히 많은 카디널리티를 가지는 값을 라우팅 필드로 선택하는 것이 상당히 중요하다고 볼 수 있다. 예) POST get-together/group/10?routing=denver {   "name" : "Denver Ruby",   "description" : "The Denver Ruby Meetup" } POST get-together/group/11?routing...

기존 filtered의 쿼리 작동은  {   "query" : {     "filtered" : {       "filter" : {         "term" : {           "location" : "denver"         }       }     }   } } 위 쿼리 조회를 위한 또 다른 방식은  {   "post_filter" : {     "term" : {       "location" : "denver"     }   } } 성능 : Post Filter는 query수행 후 실행된다. 먼저 쿼리는 모든 도큐먼트에 대해 실행되고 일치된 녀석들이 Post Filter가 적용된다. 전체적인 request 선응은 filterd 쿼리보다 느릴것이다. Document set processed by aggregations : 만약 Post filter 가 적용되지 않으면 aggregations적용된 결과가 나타날 것이다.

In some cases, however, scoring can be more resource-intensive: Scoring with a script runs a script to calculate the score for each document in the index Doing a  phrase  query searches for words within a certain distance from each other, with a large slop To address this, elasticsearch use rescoring POST get-together/_search?pretty {   "query" : {     "match" : {       "title" : "elasticsearch"     }   },   "rescore" : {     "window_size" : 20,     "query" : {       "rescore_query" : {         "match" : {           "title" : {             "type" : "phrase",             "query" : "elasticsearch hadoop",             "slop" : 5           }         }     ...

1. 필드 매핑에서 유사도 파라미터 수정 { "mappings" : { "get-together" : { "properties" : { "title" : { "type" : "string", "similarity" : "BM25" //BM25로 변경 } } } } } 2. 필드 매핑에 추가 점수 방법을 사용하는 방법 <BM25 유사도 고급설정> curl -XPOST 'localhost:9200/myIndex' { "settings" : { "index" : { "analysis" : {...}, "similarity" : { "my_custom_similarity" : { "type" : "BM25", "k1" : 1.2, "b" : 0.75, "discount_overlaps" : false //k1, b 유사도 변수 설정 그리고 중복 토큰을 계산하지 않도록 설정 } } } }, "mappings" : { "mytype" : { "properties" : { "title" : { "type" : "text", "similarity" : ""my_custom_similarity ...

1. Ngram Ngram은 토큰의 각 단어 부분을 다중 서브 토큰으로 분해하는 방식이다. Ngram과 Edge ngram둘다 min_gram과 max_gram설정이 필요하다. 이들 설정은 단어로부터 분해된 토큰의 크기를 제어한다. 예를들어, Ngram 분석길로 "spaghetti"단어를 분석한다고 가정해보자. 가장 단순한 1-grams(unigram)부터 시작하자. 1-1. 1-gram "spaghetti"의 1-gram은 s, p, a, g, h, e, t, t, i 가 된다. ngram의 크기에 따라 문자열을 작은 토큰으로 분해한다. 1-1. Bigram bigram(크기가 2인 문자열)로 분해한다면 sp, pa, ag, gh, he, et, tt, ti와 같은 작은 토큰을 얻을 것이다. 1-3. Trigram spa, pag, agh, ghe, het, ett, tti토큰을 얻을 것이다. 2. min_gram과 max_gram의 설정 이 분석기를 이용할 때 두 개의 서로 다른 크기를 설정해야 한다. 하나는 생성하려는 가장 작은 ngram(min_gram설정), 다른하나는 가장 긴 ngram을 지정한다. 앞의 예제 "spaghetti"에서 min_gram을 2,  max_gram을 3으로 설정하면 다음과 같다. sp, spa, pa, pag, ag, agh, gh, ghe, he, het, et, ett, tt, tti, ti 이 런 방식으로 텍스트를 분석 하는 것에 흥미를 끌 만한 점이 있는데, 텍스트를 쿼리할 떄 텍스트를 동일한 방식으로 분해할 텐데, 그래서 철자가 틀린 "spaghety"단어도 찾을수 있는 것이다. 이를 검색하는 한가지 방법은 일치를 확인하기 위해 단어의 편집거리를 지정하는 퍼지(fuzzy)쿼리를 실행하는 것이다. "spag...

생각해둔 분석기가 있어서 어떻게 텍스트를 다루는지 확인하고 싶다면, 분석기의 이름을 analyzer파라미터로 설정하면 된다. elasticsearch.yml 파일에 분석기를 설정한다면, analyzer파라미터에 있는 names로 이를 지정할 수 있다. POST get-together/_analyze?analyzer=myCustomAnalyzer 'share your experiance' 가끔은 내장 분석기만 사용하고 싶지 않을 떄도 있다. 그 대신 토크나이저와 토큰 필터의 조합으로 시도를 해보고 싶을 것이다. 예를들어, 공백으로 텍스트를 분해하기 위해 화이트스페이스 토크나이저와 그 후에 소문자화 및 역토큰 필터(reverse token filter)를 사용하고 싶다면 다음과 같이하면 된다. POST get-together/_analyze?tokenizer=whitespace?filters=lowercase, reverse 'share your experience * 텀 벡터 API를 사용하여 색인된 텀 실행하기 curl 'localhost:9200/get-together/_doc/1/_termvector?pretty=true'

엘라스틱 서치는 도큐먼트가 색인에 추가되기 전에 모든 분석된 필드를 위해 다음과 같은 단계를 거친다. 문자 필터링 - 문자 필터를 이용해서 문자들을 변환한다. 텍스트를 토큰으로 분해 - 텍스트를 한 개 이상의 토큰의 집합으로 분해한다. 토큰 필터링 - 토큰 필터를 사용해서 개별 토큰을 변환한다. 토큰 색인 - 토큰을 색인에 저장한다. 1.  문자 필터링 "share your experiance with NoSql & big data technologies" 여기서  & => and로 변환한다. "share your experiance with NoSql and big data technologies" 2. 토큰으로 분해하기 루씬 자체는 데이터의 큰 문자열에 작용하지 않는대신 토큰으로 알려져 있는 것에 작동한다. 예를들어, 영문에서 사용하는 일반적인 토크나이저는 표준 토크나이저인데, 공백과 개행같은 화이트스페이스 뿐만 아니라 대시(dash)같은 문자를 기반으로 텍스트를 토큰으로 분해한다. share, your, experiance, with, NoSql, and, big, data, technologies, 3. 토큰 필터링 4. 토큰 색인 * 색인 생성시 분석기 추가하기 색인을 위한 주 샤드와 레플리카 샤드 개수를 위한 settings는 다음과 같다. POST get-together { "settings" : { "number_of_shards" : 2, "number_of_replica" : 1 }, "mappings" : { .... } } 사용자 지정 분석키를 추가하는 것은 index키 아래에 있는 settings 설정에 별도의 맵으로 지정한다. 이...

bool쿼리 * must (query1 AND query2 AND query3)가 반드시 일치해야함 * should (query1 OR query2 OR query3)가 반드시 일치해야함 * must_not 반드시 일치하지 않아야함 GET get-together/_search { "query" : { "bool" : { "must" : [ { "term" : { "attendees" :"david" } } ], "should" : [ { "term" : { "attendees" : "client" } }, { "term" : { "attendees" : "andy" } } ], "must_not" : [ { "range" : { "date" : { "lt" : "2013-06-30T00:00" } } } ], "minimum_should_match" : 1 } } }

1. MATCH_ALL 쿼리 모든 도큐먼트를 일치하게 된다. 쿼리 대신 필터 사용이 필요할 때, match_all쿼리가 상당히 유용하다 (점수에 관해 신경쓰지 않을 떄) 또는 검색하는 색인과 타입 사이에서 모든 도큐먼트를 반환하고 싶을 때 유용하다. 예) GET get-together/_search { "query" : { "match_all" : {} } } 검색에 쿼리 부분대신 필터를 사용하면 쿼리는 이와 같다. GET get-together/_search { "query" : { "match_all" : {} }, "filter" : { .... } } 2. QUERY_STRING 쿼리 다른 대체제로 하는 것을 추천 3. 텀 쿼리와 텀 필터 텀 쿼리와 필터는 실행 가능한 가장 단순한 쿼리인데, 필드와 텀을 지정해서 도큐먼트 내에서 검색할 수 있다. 검색한 텀이 분석되지 않았기 때문에 완전히 일치하는 도큐먼트 결과만 찾는다는 것을 알아두자. 예) GET get-together/_search { "query" : { "term" : { "tags" : "elasticsearch" } }, "_source" : ["name", "tags"] } 결과값 { "hits" : [ { "_id" : "3", "_index" : "get-together", "_score"...

* filtered query는 5.0버전부터 deprecated 되었습니다. 일반적으로 query는 일치하는 도큐먼트와 얼마나 근접한지 점수를 반환한다. 반면에 filter는 단순히 도큐먼트가 일치하는지 예, 아니오만 판단한다. 다음과 같다.               텀 필터 :             tags=lucene    도큐먼트는 tags=lucene를 가지는가? 1 . Yes : 캐시 일치 - >도큐먼트 반환. 2. No : 캐시 불일치 -> 도큐먼트 제외          텀 쿼리:       tags=lucene    도큐먼트는 tags=lucene를 가지는가? 1. Yes : 점수 계산 -> 도큐먼트 반환 2. No : 다음 도큐먼트로 이동하므로 신경쓰지말자. filtered : query + filter 필터드 쿼리는 쿼리와 필터 둘다 포함한다. 예는 다음과 같다. GET get-together/_search { "query" : { "filtered" : { "query" : { "match" : { "title" : "hadoop" } }, "filter" : { "term" : { "host" : "andy" } } } } } GET get-together/_search { "query" : { "bool" : { "must" : { "match" : { "title" : "hadoop" } }, "...

엘라스틱 서치는 일치한 도큐먼트를 _score값의 내림차순으로 정렬해서 가장 적합성이 높은 도큐먼트 순서로 반환한다. 오름차순 또는 내림차순으로 필드를 정렬하려면 필드를 나열한 배열 대신 다음처럼 맵을 가진 배열을 지정한다. GET get-together/_search { "query" : { "match_all" : {} }, "sort" : [ {"created_on" : "asc"}, {"name" : "desc"}, "_score" ] }

검색 요청의 일부분을 차지하는 또 다른 요소는 엘라스틱 서치로 하여금 일치하는 개별 도큐먼트에서 반환할 필드 목록을 어떻게 지정하는가인데, 검색요청에 _source 구성 요소에서 이를 지정하면 된다. 요청에 _source를 지정하지 않는다면, 엘라스틱서치는 기본적으로 도큐먼트의 _source 전체를 반환하거나 저장된 _source가 없다면 일치하는 _id, _type, _index, _score와 같은 도큐먼트에 관한 메타데이터만 반환한다. 일치하는 각 그룹의 name과 date필드를 반환하는 쿼리는 다음과 같다. GET get-together/_search { "query" : { "match_all" : {} }, "_source" : ["name", "date"] } _SOURCE로 반환한 필드에서 와일드 카드 필드목록을 각각 지정해서 반환하는 것 외에도 와일드 카드를 사용할 수 있다. 예를들어, "name" , "nation"필드 둘다 반환하려면 "_source" : "na*"를 지정한다. _source["name.*", "address.*"] 와 같이 와일드 카드 문자열을 배열처럼 사용해서 다수개 와일드 카드를 지정할 수 있다. 어떤 필드를 포함할지 지정할 수 있을 뿐만아니라 반환하지 않을 필드도 제외시킬 수 있다. 예) GET get-together/_search { "query" : { "match_all" : {} }, "_source" : { "include" :["location.*", "date"], "exclude...

_source는 모든 것을 저장하고, _all은 모든것을 색인한다. _all로 검색할 때, 엘라스틱 서치는 어떤 필드가 일치하는지와 무관하게 검색결과를 반환한다. 이는 사용자가 보려는 것이 어디에 있는지 몰라도 그저 무언가를 찾을 때 유용하다. 항상 특정 필드만 검색하려면 _all의 enable옵션으로 false를 설정해서 비활성화 할 수 있다. 이렇게 하면 색인 전체 크기가 줄어들고 더 빠르게 색인을 만든다.. 기본적으로 _all은 include_in_all옵션 값으로 true를 가진 개별 필드를 암묵적으로 포함한다.  include_in_all옵션을 사용해서 _all은 무엇이 포함되고 무엇이 그렇지 않을지 제어할 수도 있다.

_source는 원본 도큐먼트를 저장할지 또는 그렇지 않을지를 true 또는 false로 지정할 수 있다. 기본값은 true인데 대부분의 경우 그대로 사용하는 것이 좋다. 왜냐하면 변경 API를 이용한다던지 하이라이트 (Highlighting)구현 역시 _source가필요하다 원본 도큐먼트의 특정 필드만 반환하기 GET get-together/_doc/1?pretty?fields=name fields파라미터로 제공할 수 있다. _source를 저장할 떄, 엘라스틱 서치는 여기에서 필수 필드를 가져온다. Store옵션을 yes로 설정한 개별필드만 저장할 수 있다. 예를들어 name필드만 저장하려면 매핑은 다음과 같다. _source전제를 조회해서 특정 필드를 추출하는 것보다 단일 저장 필드를 조회하는 것이 더 빠르므로, 특히 큰 도큐먼트를 갖고 있을 때, 엘라스틱서치에게 특정 필드만 요청하는 것이 더 유용할 수 있다. * _source의 기능을 false할 시 문제점 update, update_by_query그리고 reindex API를 사용할 수 없다. highlighting 기능을 사용할 수 없음 reindex및 mapping, analysis 바꾸기 불가, major버전으로 인덱스 업그레이드 불가 쿼리 또는 aggregation의 디버그 불가 만약 디스크 공간이 문제라면 _source를 false하기 보다는 compression level을 고려해보자

일반적으로, 사전 정의된 필드는 사용자가 정의하지 않고 일래스틱 서치가 제공한다. 도큐멘트를 색인할 때 날짜를 기록하는 _timestamp 필드를 사용할 수 있다. 사전 정의된 필드는 필드에 따라 특수 기능을 갖고 있다. 예를들어, ttl필드는 일래스틱서치에 의해 특정 시간 이후에 도큐멘트를 자동 삭제하는 기능을 갖고 있다. 사전 정의된 필드 이름은 모두 언더스코어(_)로 시작한다. 이들 필드가 도큐먼트에 새 메타데이터를 추가하면, 원본 도큐먼트에 새 메타데이터를 추가하면, 원본 도큐먼트를 저장하는 것에서부터 자동 만료를 위해 타임스탬프를 저장하는 것에 이르기 까지 일래스틱서치는 이 메타데이터를 다양한 기능에 사용한다. 도큐먼트를 어떻게 저장하고 검색하는지에 관한 제어 : _source는 색인할 때 원래의 Json도큐먼트를 저장하도록한다. _all은 모든 필드를 색인한다. 도큐먼트의 아이덴티티(Identity) : 도큐먼트가 색인된 곳에 관한 데이터가 포함된 _uid, _id, _type, _index가 있다. 도큐먼트에 새 속성 추가 : _size로 원본 JSON크기 값을 색인 할 수 있다. 같은 방법으로 _timestamp를 이용해서 색인 시점의 시간값을 별도로 색인 할 수 있으며, _ttl을 이용해서 특정 시간 이후에 자동으로 삭제되도록 할수 있따.

첫번쨰는 tags필드에 ["first", "second"]가 들어간 경우이고 두번째는 tags필드에 "third four"가 들어가있다. 이때, default조건에 의해 둘다 analyzed되어 있지만, 다른 조건인 not_analyzed를 걸고 싶다면 다음과 같이한다. { "properties" : { "tags" : { "type" : "text", "index" : "analyzed", "fields" : { "verbatim" : { "type" : "text", "index" : "not_analyzed" } } } } } 그저 아무 문자열을 실행하면 태그필드의 analyzed버전에서 검색한다. 그러나 원래의 태그에서 정확하게 일치하는 것을 가져오기 위해 not_analyzed버전에서 검색하려면 tags.verbatim이라는 전체 경로를 지정해서 검색한다.

다음과 같이 new-events 타입을 인덱스한다고 해보자 PUT get-together/_mapping/new-events {   "properties" : {     "name" : {       "type" : "text",        "index" : "analyzed"      }    } } index의 기본값은 analyzed인데, 만약 해당 필드에 있는 값이 "Last night with ElasticSearch"라고 하면 analyzed인 경우는 해당 문장을 단일 텀으로 변경하여 색인 한다. 즉, "last" , "night", "with", "elastisearch"이다. 만약 not_analyzed인 경우는 단일 텀으로 만들지 않고, 전체 문자열을 단일 텀으로 색인한다. 태그 검색 처럼 정확히 일치하는 경우 사용한다. 예를 들어, "big data"인 경우는 "big data"자체가 색인된다. 만약 index 가 no인 경우는 색인을 생략하고 어떠한 텀도 만들지 않아서 특정 필드의 검색이 불가능 할 것이다. 검색할 필요가 없는 경우는 이 옵션을 사용하면 공간의 절약과 색인 및 검색에 필요한 시간도 절약할 수 있을 것이다. 예를들어, 이벤트의 리뷰를 저장한다고 하자. 비록 이 리뷰를 저장하고 보여주는 것이 가치가 있어도 검색할 필요까지는 없을 것이다. 이 경우 그 필드의 색인을 비활성화 함으로써 색인 과정을 더 빠르게 만들고 저장 공간도 절약할 것이다.