jjeong

http://jjeong.tistory.com/957

글에 이은 루씬 한국어 형태소 분석기 플러그인 입니다.

일단 잘되내요.. ^^;

형태소 분석기 플러그인 만드는 방법은 아래 글 참고하세요.

http://jjeong.tistory.com/818

https://github.com/HowookJeong/elasticsearch-analysis-arirang

elasticsearch 에 한글형태소 분석기로 arirang 을 적용해 보려고 합니다.

그 전에 먼저 arirang 을 받아서 빌드 테스트를 해보고 lucene 4.7.2 로 빌드가 잘 되면 elasticsearch 1.1.1 용 플러그인으로 만들것입니다.

자세한 내용은 카페에서 확인하세요.

http://cafe.naver.com/korlucene

- SVN

- Build 조건

저는 그냥 

https://lucenekorean.svn.sourceforge.net/svnroot/lucenekorean/arirang.lucene-analyzer-4.6

받아서 4.7.2 로 수정해서 빌드 했습니다.

@수명님이 주의 사항을 카페에 올려 두신게 있는데요 arirang.morph 먼저 빌드 하신 후 analyzer 를 빌드 하셔야 합니다.

이건 pom.xml 열어 보시면 아실듯.. 

일단 4.7.2 로 빌드 잘 되내요.

플러그인 적용 방법은 따로 공유 드리겠습니다.

다 아시는 분들에게는 별로 도움도 안되겠내요.. ^^;;

운영하다 보면 저절로 정상적이던 shard 가 unassigned 로 상태가 변경되어 있는 경험을 하시는 분들이 꽤 되시는 것 같습니다.

그래서 초간단 팁을 공유 합니다.

elasticsearch 는 대량의 데이터를 분산 처리 하기 위한 구조로 설계가 되어 있습니다.

그래서 clustering, sharding, replication, recovery 등등의 기능들이 들어 있는 것일 겁니다.

shard 가 unassigned 되었을 때 강제로 reroute 시키는 방법은 이전 글에 공유를 하였습니다.

http://jjeong.tistory.com/909

http://jjeong.tistory.com/905

우선 elasticsearch 의 설정을 살펴 봐야 합니다.

elasticsearch.yml 에 보시면 recovery 세션에 아래 와 같은 내용이 있습니다.

보시면 아시겠지만 이건 node 가 추가 되거나 제거 되었을 때 shard 를 rebalancing 하는 것입니다.

이유는 잘 아시겠죠?

이 설정 또한 성능에 영향을 주는 부분이니 참고 하시면 좋을 것 같습니다.

그리고 cluster.routing 설정에 보시면 shard allocation 에 대한 정보가 있습니다.

allocation 에 대한 정책을 설정 하는 것인데요.

이 설정을 해보신 분이라면 아마 운영 중에 발생 하는 unassigned shard 를 어떻게 예방할지를요.. 

물론 아래 설정은 1.0.0.RC1 부터 추가되었습니다.

일반적인 내용으로 정리를 하면,

- shard allocation 은 왜 발생 하는가?

- shard allocation 을 방지 할 수는 없는가?

- unassigned shard 는 왜 발생 하는가?

shard allocation 에 대한 정책이 궁금하신 분은 아래 패키지 소스들을 보시면 되겠습니다.

org.elasticsearch.cluster.routing.allocation.allocator

org.elasticsearch.cluster.routing.allocation.decider

검색엔진을 사용하다 보면 문서에 대한 부분 업데이트가 필요할 때가 있습니다.

루씬을 이용하낟고 하면 보통 아래와 같은 flow 로 진행을 하게 되는데요.

검색엔진 특성상 색인된 문서를 가져와서 수정이 필요한 필드의 데이터를 변경한 후 다시 색인을 할 수 밖에 없습니다.

elasticsearch 에서도 좀 예전 버전에는 partial update 기능이 없었는데요.

저도 정확히는 기억이 안나지만, 어쨌던 0.19.x 이후 부터는 포함이 되어 있습니다.

레퍼런스 문서)

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-update.html

플러그인)

https://github.com/medcl/elasticsearch-partialupdate

사용방법은 update api 에 mvel 문법을 이용해서 script 로 작성 하시면 됩니다.

작성 방법 및 예제는 레퍼런스 문서에 아주 잘 나와 있습니다.

주의사항)

- elasticsearch 는 lucene 기반이죠. 그렇기 때문에 partial update 라고 하더라도 내부적으로는 그냥 reindexing 하는 거와 같습니다.

- index mappings 정보 설정 시 _source enable 로 설정 하셔야 합니다.

뭐 default true 라서 꼭 설정할 필요는 없지만 명시적으로 하는걸 좋아 하다 보니.. ^^; 

레퍼런스 문서)

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-source-field.html#mapping-source-field

※ _source field 에 대한 설명은 따로 하지 않겠습니다.

활용편에 소개 할 내용중 하나 인데 오늘 살짝 맛보기만 조금 던져 볼까 합니다.

elasticsearch 를 가지고 like join 같은 기능을 구현 하고 싶으신 분들이 많이 있습니다.

그래서 예전에도 조금 언급은 했었는데요.

elasticsearch 로 비슷하게 구현 가능한 방법은 parent/child 와 nested 구조를 이용하는 것입니다.

오늘은 parent/child 만 알아 볼께요.

우선 레퍼런스 문서는...

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-parent-field.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-query.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-query.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-filter.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-child-filter.html

elasticsearch blog 글) 필독!!

http://www.elasticsearch.org/blog/managing-relations-inside-elasticsearch/

참고 하시기 바랍니다.

1. parent/child 정의 하기.

위 설정에서 보시는 것 처럼 parent type 과 child type 을 정의 하고 child type 에 parent type 을 지정하면 됩니다.

이 예제는 등록된 글에서 키워드를 추출해서 child 로 저장하는 것입니다.

RDBMS 관점으로 설명을 하자면, 

child_type 이라는 테이블에서 질의를 하고 거기서 나온 결과 값을 가지고 parent_child 테이블에 inner join 하는 구조 입니다.

2. has_child 질의 하기

위 query 를 보면 child_type 에서 elasticsearch 라는 키워드가 있는 문서를 찾고 그 문서의 parent document 를 return 해 주게 됩니다.

ㅋ 결과를 안보여 드리니까.. 감이 잘 안오신다구요... 

그럼 아래 글 보고 돌려 보시면 되겠습니다. :)

이건 웹상에 잘 정리가 된게 있어서 그냥 링크만 공유 합니다.

http://joelabrahamsson.com/grouping-in-elasticsearch-using-child-documents/

[parent/child 사용시 주의 점]

1. 검색 결과로 child 문서의 field 는 return 되지 않습니다.

2. memory 사용을 많이 합니다.

3. 아직 까지는 nested 보다 느립니다.

4. cross index 지원을 하지 않습니다. (즉, 하나의 index 에 type 으로만 지원 합니다.)

드디어 종이책이 출간 되었습니다.

예스24, 알라딘, 교보, 인터파크에서 구매 할수 있다고 합니다.

가격은 13,200원 입니다.

http://www.yes24.com/24/Goods/12679909?Acode=101

Original Link : http://blog.qbox.io/elasticsesarch-percolator

Our Qbox team has been asked about the Percolate API, and we’re glad to share here an introduction on that very popular Elasticsearch feature. But before we get started a small amount of setup is involved. To make sure we’re working with the same environment, we’ll start with installing v1.0.1 of Elasticsearch.

Install and Start Elasticsearch v1.0.1

http://www.elasticsearch.org/download/

Distributed Percolation is a feature of the v1.x series of Elasticsearch. We’ll be using the current version of the v1.x series,  v1.0.1 . If you’ve never Installed Elasticsearch, take a moment to watch or read our Elasticsearch Tutorial Ep.1 for detailed instructions.

Mapping and Data

http://sense.qbox.io/gist/28ff2f1031e6d4a5904604d24d26b0bad6238720

For this introduction we've provided a sense gist with runnable code examples in the link above. Once v1.0.1 of Elasticsearch is running locally, you may map your documents, and begin using the Percolate API examples below. 

Percolate

The Percolate API is a commonly used utility in Elasticsearch for alerting and monitoring documents. “Search in reverse” is a good way to conceptualize what Percolation does. Searching with Elasticsearch is usually done by querying a set of documents for relevance to the search. Percolate works in the opposite way, however, Percolating your documents against registered queries (percolators) for matches.

v1.0.0 of Elasticsearch brought a major change to how the Percolate API distributes its registered queries. Percolator 0.90.x and previous versions have a single shard index restriction.With a single shard, performance continues to degrade as the number of registered queries grows.

To get around this bottleneck, queries could be partitioned against multiple single shard indices, or you could manipulate Percolate queries to reduce the execution time. Using these methods, however, still caused fundamental scaling limits for any Percolator index shard. Having to “get around” this bottleneck was a concern for the Elasticsearch team who wanted to make the Percolator distributed. v1.0.0 Distributed Percolation put these issues to bed, dropping the previous _percolator index shard restriction for a .percolator type in an index.

Distributed Percolation

A .percolator type gives users a distributed Percolator API environment for full shard distribution, and you can now configure the number of shards necessary for your Percolator queries, changing from a restricted single shard execution to a parallelized execution between all shards within that index. Multiple shards means support for routing and preference, just like the other Search APIs (except the Explain API).

Dropping the old _percolator index shard restriction does create breaking backwards compatibility with the 0.90.x Percolator, but breaking changes in Percolation are a great reason to make renovations and features.

Structure of a Percolator in v1.x

Registering a .percolator has changed little from a Percolator of the 0.90.x series. A more substantial change mentioned earlier is the .percolator is now a type in an index, as shown in the example below. In this Percolator we register a match query for the “sport” field containing “baseball.”

curl -XPUT 'localhost:9200/sports/.percolator/1' -d '{
   "query" : { 
       "match" : {
           "sport" : "baseball"
       }
   }
}'

Default mapping for a .percolator type is a query field type of object, with “enabled” set to false. (Enabled allows disabling of parsing and indexing on a named object.) It is worth noting that this new index type could exist on a dedicated Percolator index. Remember when using a dedicated Percolator index to include the mapping of the documents you _percolate. Without the correct mapping for the documents you _percolate, .percolator queries can be (and probably will be) parsed incorrectly.

Request:

curl -XGET "http://localhost:9200/sports/_mapping"

Response:

{
  "sports" : {
    "mappings" : {
      ".percolator" : {
        "_id" : {
        "index" : "not_analyzed"
      },
      "properties" : {
        "query" : {
          "type" : "object",
          "enabled" : false
        }
      }
    }
  }
}

Percolate

Running _percolate through this .percolator below will return a match if it meets a .percolator relevance. There are a few ways we can run our documents against our Percolator. First, we will use the very standard “doc” body to execute the _percolator API. Usually you would use this method on documents that do not already exist.

Percolator:

curl -XPUT 'localhost:9200/sports/.percolator/1' -d '{
   "query" : {
       "match" : {
           "sport" : "baseball"
       }
   }
}'

Percolating on a “doc” body:

curl -XPOST "http://localhost:9200/sports/athlete/_percolate/" -d '{
  "doc": {
     "name": "Jeff",
     "birthdate": "1990-4-1",
     "sport": "Baseball",
     "rating": 2,
     "location": "46.12,-68.55"
  }
}'

This sports index has a single .percolator with “_id”:”1” that our document matches. You can see in the response below that it took 1ms, 5 out of 5 shards were successful, and we matched one Percolator in the sports index with “_id”: “1”.

Response:

{
  "took": 1,
  "_shards": {
     "total": 5,
     "successful": 5,
     "failed": 0
  },
  "total": 1,
  "matches": [
     {
        "_index": "sports",
        "_id": "1"
     }
  ]
}

Bulk Percolating documents can be achieved with the multi-Percolate API (similar to the bulk API). Format for the multi-Percolate API begins with a header specifying your index, type, and id. Followed after the header is your JSON document body itself. No JSON document is required when Percolating an existing document; only a reference to the “_id” of the document is required.

Request:

curl -XGET 'localhost:9200/sports/athlete/_mpercolate' --data-binary @multi-percolate.txt; echo

Multi-percolate.text:

{"percolate" : {"index" :”sport", "type" : "athlete"}}
{"doc" : {"name":"Michael", "birthdate":"1989-10-1", "sport":"Baseball", "rating": ["5", "4"],  "location":"46.22,-68.45"}}
{"percolate" : {"index" : twitter", "type" : "tweet", "id" : "1"}}
{}

To _percolate a single an existing document, simply mention the “_id” of the document to Percolate on

curl -XGET 'localhost:9200/sports/athlete/1/_percolate'

Another format for the standard _percolate response is count, which only responds with the total number of matches.

curl -XPOST "http://localhost:9200/sports/athlete/_percolate/count" -d '{
  "doc": {
     "name": "Jeff",
     "birthdate": "1990-4-1",
     "sport": "Baseball",
     "rating": 2,
     "location": "46.12,-68.55"
  }
}'

Response:

{
  "took": 3,
  "_shards": {
     "total": 5,
     "successful": 5,
     "failed": 0
  },
  "total": 1
}

A way to specifically Percolate athletes with the sport baseball would be a filter. We could then create a  .percolator on another field about which we are curious, say, a specific birthdate.

curl -XPOST "http://localhost:9200/sports/athlete/_percolate/" -d '{
  "doc": {
     "name": "Jeff",
     "birthdate": "1990-4-1",
     "sport": "Baseball",
     "rating": 2,
     "location": "46.12,-68.55"
  },
  "filter": {
     "term": {
        "sport": "baseball"
     }
  }
}'

curl -XPUT "http://localhost:9200/sports/.percolator/2" -d '{
   "query":{
       "match": {
          "birthdate": "1990-4-1"
       }
   }
}'

Other supported query string options for _percolate include size, track_scores, sort, facets, aggs, and highlight. Query and filter options only differ by query’s score being computed. The computed score can then be used to show the documents score, which is based on the query’s match to the Percolate query’s metadata. You can also use highlight, facets, or aggregations on these request bodies. Using size to specify the number of matches to return ( defaults to unlimited).  

Distributed Percolation can be the solution for some of the most active databases in production today. Fascinating data and analytics can be gained from your real-time _percolate. With distribution, the Percolate API will only grow into more interesting use cases and ideas for Elasticsearch.

If you enjoyed this post, you’ll want to check out some of our other tutorials like An Introduction to Elasticsearch Aggregations for more.

You can use Elasticsearch v1.0.1 and 0.90.12 on Qbox today to try out Percolation on a dedicated cluster of your choosing. If you have any questions, feel free to leave a comment below or contact us. Runnable code of all the examples used in this tutorial can be found at thissense-gist.

es 를 다루면서 기본이 되는 내용인데 잘못 이해 하고 계시는 분들을 위해서 글 올려 봅니다.

제 책에도 언급이 되어 있습니다. ^^;

http://www.hanbit.co.kr/ebook/look.html?isbn=9788968486913

replica 는 말 그대로 index 에 대한 복제를 의미 합니다.

이 복제에 대한 의미를 active, standby 로 표현 하는 것은 잘 못된 표현 입니다.

replica 는 물리적인 index 의 shard 를 복제 하여 분산처리를 가능하게 해주고 SPOF(single point of failure) 에 대한 failover 개념으로 사용 되는 것입니다.

replica 와 shard 에 대해서는 인터넷 검색해 보시면 그림을 잘 그려 주신 분들이 너무나 많습니다.

그리고 slideshare 나 elasticsearch.org 에 들어가 보시면 많은 문서들이 있기 때문에 보시면 될 것 같습니다.

replica 는 기본적으로 primary 를 기반으로 복제를 하게 됩니다.

shard 에는 primary shard 와 replica shard 이렇게 두 가지가 존재 합니다.

모든 색인은 기본 primary shard 에서 이루어 지고 이것을 가지고 복제를 하게 되는 것이구요.

또한 검색 시 이 shard d 들은 성능에 많은 영향을 주게 됩니다.

0.90.x 제 기억으로는 0.90.5 까지만 해도 3가지 type 만 있었는데 1.x 또는 제가 확인 안한 0.90.5 이상 부터.. 

아래 유형들이 추가 되었습니다.

이 옵션들은 검색 요청 시 성능 또는 기능 요구사항에 따라 다양하게 활용을 할 수 있습니다.

기본 설정 값은 random 입니다.

이전까지 유효했던 설정은 _local, _primary 였구요. 위에 있는 옵션들은 추가 된건데 기능이 동작 하는지은 테스트 해보지는 않았습니다.

정리 하면, 

replica)

primary shard 에 대한 복제 기능 설정을 하는 것이다.

replica shard 를 의미 한다.

기본 설정은 1 이다.

full replica 설정은 node size - 1 이다.

 SPOF 대응을 위한 설정이다.

shard)

primary shard 와 replica shard 가 있다.

primary shard 에 기본적으로 색인이 되며, 이를 기준으로 replica shard 를 생성하게 된다.

shard 는 lucene 에서 사용하는 index 기준이다. ( 루씬 기준의 물리적인 인덱스 라고 보시면 됩니다. )

추가로, unassigned shard 도 여러가지 상황에 따라 발생을 하게 됩니다.

- 할당한 노드가 없을 때도 발생을 하고

- recovery 가 실패 했을 떄도 발생을 합니다.

- 그 외 여러가지 상황이 있을 수 있구요.

기본적으로 정상적인 shard 인데 unassigned shard 로 남아 있는 경우 수동으로 할당을 시켜 줄 수 있습니다.

shard reroute 를 통해서 할당해 주면 됩니다. (http://jjeong.tistory.com/909)

그리고 sharding 알고리즘은 기본적으로 각 노드에 순차적으로 shard 를 할당하는 구조 입니다. (http://jjeong.tistory.com/926)

요정도 까지만 정리하도록 하겠습니다.

es 의 기본 개념은 elasticsearch.org 의 glossary 를 참고하세요.

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/glossary.html

부끄럽지만 제가 쓴 책 소개를 하겠습니다.

Elasticsearch 관련된 개발 서적 입니다.

수준은 초급 개발자에 맞춰져 있고, 검색에 대한 기본 이해를 도와 줍니다.

입문 과정이기 떄문에 Elasticsearch 에서 제공하는 모든 API와 연관 컴포넌트들에 대한 것을 담고 있지는 않습니다. 이런 것들은 이후 활용편에서 다룰 예정이니 이것도 기대해 주시면 좋겠습니다.

종이책은 4월 10일 출간 예정입니다.

설치 그리고 설정, 색인, 검색 까지의 기본 스토리를 전제로 작성 되어 있으며, 기본 예제로 사용된 내용은 일반 쇼핑몰 데이터와 검색을 바탕으로 구성을 하였습니다.

출판사) 한빛미디어

책제목) 실무 예제로 배우는 Elasticsearch 검색엔진 - 기본편

링크) http://www.hanbit.co.kr/ebook/look.html?isbn=9788968486913