'Index API'에 해당되는 글 4건

  1. 2015/05/19 용비 04. Index APIs - 04
  2. 2015/05/19 용비 03. Index APIs - 03
  3. 2015/05/19 용비 02. Index APIs - 02
  4. 2015/05/19 용비 01. Index APIs - 01

TTL


Document 그와 관련된 ttl (Time To Live) 값을 가지고 index 있다. 폐기된 document 자동으로 삭제된다. Ttl값으로 제공되는 document 폐기 일자는 document index되는 시점이나 값으로 제공되는 어느 특정 시간의 timestamp 관련되어 있다. 값으로 제공되는 ttl값은 양수값이어야만 하고, milliseconds 단위의 숫자나 다음 예제에서 보여지는 적합한 시간 값이어야 한다.


curl -XPUT 'http://localhost:9200/twitter/tweet/1?ttl=86400000' -d '{
  
"user": "kimchy",
  
"message": "Trying out elasticsearch, so far so good?"
}'


curl -XPUT 'http://localhost:9200/twitter/tweet/1?ttl=1d' -d '{
  
"user": "kimchy",
  
"message": "Trying out elasticsearch, so far so good?"
}'


curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
  
"_ttl": "1d",
  
"user": "kimchy",
  
"message": "Trying out elasticsearch, so far so good?"
}'


많은 정보는 _ttl mappling page (https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-ttl-field.html) 에서 찾아볼 있다.


Distributed


Index operation routing section에서 것처럼 직접적으로 primary shard 기반 route하고, shard 있는 실제 노드에서 수행된다. Primary shard에서 operation 완료되면, 필요한 경우에, 업데이트는 replica 분산처리 된다.


Write Consistency


잘못된 network side write하는 것을 방지하기 위해서, 기본적으로 index operation active shard 수가 quorum (replicas 2분의 1 + 1) 성공적으로 수행된다. 기본값은 action.write_consistency 설정을 통해서 node-by-node별로 덮어쓸 있다. Operation별로 consistency parameter 보내면 값을 변경시킬 있다.

유효한 write consistency 값으로는 one, quorum, all 있다.

Replica 숫자가 1 경우 (전체 데이터 복제본이 2) 에는 기본 동작은 1개의 copy (primary)에서 write 발생하면, 성공한다.


Asynchronous Replication


[WARNING]

1.5.0에서 삭제되었음. Asynch replication 지정하는 것은 deprecated ( 이상 사용되지 않고 앞으로 사라질 것으로 마크) 되었고, 2.0.0에서는 삭제될 것이다.


기본적으로 index operation replication group 있는 모든 shard document index하고 나서 리턴한다. (sync replication임). Asynchronous replication 사용하기 위해서는 background replication process 일어나기 때문에 replication parameter async 설정해야 한다. Asynchronous replication 사용될 , index operation primary shard 성공적으로 operation 수행되었을 경우에 바로 결과를 리턴할 것이다.


Replication 설정의 기본 값은 sync이다. 그리고 기본 값은 action.replication_type 설정을 사용하여 노드별 기본 설정값으로 덮어쓸 있다. Replication type 유효한 값으로는, sync async가 있다. Operatio별로 동작을 다르게 하기 위해서는 replication request parameter 이용할 있다.


Refresh


Operation 발생한 이후 즉시 (전체 인덱스가 아니라) shard refresh하기 위해서, 그리고 즉시 검색 결과에 operation 적용된 document 나타나게 하기 위해서는 refresh parameter true 설정하면 된다. 옵션을 true 설정하는 것은, indexing하는 것과 검색하는 양쪽 상황에서 성능상 문제를 일으키지 않는다는 주의 깊은 생각과 확신 속에서 수행되어야만 한다. Get API 통해서 document 조회하는 것은 realtime으로 이루어진다는 것을 유의하라.


Timeout


Index operation 수행하도록 할당된 primary shard index operation 실행되고 있을 때는 이용할 없다. 여기에는 가지 이유가 있는데, primary shard gateway로부터 바로 기록되고 재배치가 일어나기 때문이다. 기본적으로 index operation primary shard 사용할 있을 때까지 1 정도를 기다린다. 1 이후에는 실패로 간주하고 오류를 응답한다. Timeout parameter 얼마나 오래 응답을 기다릴 것인지를 명시적으로 설정하는데 사용된다. 다음 예제에서는 5분으로 설정하고 있다.


$ curl -XPUT 'http://localhost:9200/twitter/tweet/1?timeout=5m' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/726

Automatic ID Generation


Index operation 특정 id 지정 없이 실행될 있다. 그런 경우에는 id 자동으로 생성된다. 게다가 op_type 자동으로 create 설정될 것이다. 여기에 예제가 있다. (PUT 대신에 POST 사용되었음에 유의하라.)


$ curl -XPOST 'http://localhost:9200/twitter/tweet/' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'


위의 index operation 대한 결과는 다음과 같다.


{
  
"_index" : "twitter",
  
"_type" : "tweet",
  
"_id" : "6a8ca01c-7896-48e9-81cc-9f70661fcb32",
  
"_version" : 1,
  
"created" : true
}


Routing


기본적으로 shard 위치 - 혹은 routing - document id 값을 hash하여 제어된다. 명시적인 제어를 위해서 router 사용된 hash function 반영된 값은 routing parameter 사용한 per-operation 기반으로 직접 사용할 있다. 예를 들면 다음과 같다.


$ curl -XPOST 'http://localhost:9200/twitter/tweet?routing=kimchy' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'


위의 예제에서 "tweet" document 제공된 "kimchy" routing parameter 기반하여 해당 shard route된다.

명시적으로 mapping 설정하면, _routing 필드를 document에서 routing value 추출하여 index operation 직접 사용할 있다. 이것은 추가적인 document parse측면에서 최소한의 비용으로 처리할 있다. 만약 _routing mapping 정의되고, required 설정되었을 경우, routing value 제공되지 않거나 추출한 값이 없으면 index operation 실패할 것이다.


Parents & Children


Child document indexing parent 명시하여 index 있다. 예를 들면 다음과 같다.


$ curl -XPUT localhost:9200/blogs/blog_tag/1122?parent=1111 -d '{
  
"tag" : "something"
}'


Child document indexing , routing value routing parameter 명시적으로 지정되지 않으면, 자동으로 parent 동일하게 설정된다.


Timestamp


Document 그와 관련된 timestamp index 있다. Document timestamp 값은 timestamp parameter 사용해서 설정할 있다. 예를 들면,


$ curl -XPUT localhost:9200/twitter/tweet/1?timestamp=2009-11-15T14%3A12%3A12 -d '{
  
"user" : "kimchy",
  
"message" : "trying out Elasticsearch"
}'


만약 timestamp값이 외부나 _source 제공되지 않으면, timestamp 자동으로 document index chain 의해 처리되는 시점의 날짜로 설정될 것이다. 많은 정보는 _timestamp mapping page (https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-timestamp-field.html) 에서 찾아볼 있다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/725

Versioning


index document 버전 번호를 갖는다. 이와 연관된 version number index API request 대한 response 일부분으로 리턴된다. Index API 선택적으로 version parameter 명시되면 optimistic concurrency control (낙관적 병행 수행 제어 : RDBMS 같은 트랜잭션 기반 시스템에 적용되는 concurrency control) 허용한다. 이것은 operation 의도와는 반대로 실행되지 않도록 document 버전을 제어할 것이다. 버전에 대한 훌륭한 use case sample transactional read-and-update 수행하는 것이다. Document 특정 버전을 명시하면 최초에 읽는 동안 변경되지 않은 데이터를 읽을 있다. (업데이트 하기 위해서 데이터를 read하는 경우라면 preference _primary 설정하는 것을 권고한다.) 예를 들면 다음과 같다.


curl -XPUT 'localhost:9200/twitter/tweet/1?version=2' -d '{
  
"message" : "elasticsearch now has versioning support, double cool!"
}'


[NOTE]

Versioning 완전히 real-time (실시간)이다. 그리고 실시간 (near real time) 성인 검색 작업에는 영향을 주지 않는다. Version 제공하지 않을 경우에는 operation 어떤 버전도 체크하지 않고 실행된다.


기본적으로, 내부적인 versioning 1부터 시작하여 update, delete마다 1 증가한다. 선택적으로, version number 외부 (예를 들어, database 저장된 )으로 보강될 있다. 이런 기능을 가능하게 하기 위해서는 version_type external 설정되어야 한다. Version 값은 0이상 9.2e+18 이하의 numeric, long 값이어야만 한다. 매칭되는 version number 체크하는 대신에 External version type 사용할 때는 index request 전달된 version number 현재 저장된 document version 보다 큰지를 알기 위해 시스템에서 체크한다. 만약 크면, document index되고 새로운 number 사용될 것이다. 작거나 같으면 version conflict 발생하고 index operation 실패할 것이다.


Version number database 저장하도록 하면, async indexing operation 대한 strict ordering 유지할 필요가 없다. Database 데이터를 사용하여 elasticsearch index update하는 경우에도 external versioning 사용하면 단순화할 있다. 어떤 이유로든지 index operation 잘못되더라도 가장 마지막 버전이 사용되기 때문이다.


Version types


위에서 언급된 internal, external version type 다음으로, Elasticsearch 특정 use case 대한 다른 type 지원한다. 다음에서 다른 version type 의미에 대해서 살펴보자.


internal

주어진 version 저장된 document version 동일하다면 document index한다.


external or external_gt

주어진 version 저장된 document version보다 크거나 현재 존재하는 document 없으면 document index한다. 주어진 version 새로운 버전으로 사용되고 새로운 document 저장될 것이다. 적용된 버전은 양수의 long number이어야 한다.


external_gte

주어진 version 저장된 document version 이상일 경우 document를 index한다. Document 존재하지 않더라도 어쨌거나 operation 성공할 것이다. 주어진 version 새로운 version으로 사용되고, 새로운 document 함께 저장될 것이다. 적용된 버전은 양수의 long number이어야 한다.


force

저장된 document version과는 상관없이 document index한다. 또는 document 존재하지 않아도 index한다. 주어진 version 새로운 version으로 사용되고, 새로운 document 함께 저장될 것이다. version type 일반적으로 error 완전하게 하기 위해서 사용한다.


[NOTE]

external_gte force version type 주의 깊게 사용해야만 하는 특별한 use case 위해 고안되었다. 부적합하게 사용한다면, 데이터 유실이 발생할 있다.


Operation Type


Index operation 또한 "put-if-absent" 동작을 허용하도록 create operation 강제화 하는데 사용할 있는 op_type을 지원한다. Create 사용되면, index내에 이미 요청한 id document 존재한다면 index operation 실패할 것이다.


op_type parameter 사용하는 예제는 다음과 같다.


$ curl -XPUT 'http://localhost:9200/twitter/tweet/1?op_type=create' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'


다른 형태의 예제는 다음과 같다.


$ curl -XPUT 'http://localhost:9200/twitter/tweet/1/_create' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/724

섹션에서는 다음 CRUD APIs들을 설명하고 있다.


  • Single document APIs
    • Index API
    • Get API
    • Delete API
    • Update API

  • Multi-document APIs
    • Multi Get API
    • Bulk API
    • Bulk UDP API
    • Delete By Query API

[NOTE]

모든 CRUD API single-index API이다. Index parameter로는 single index 명이나 single index 나타내는 alias 명을 사용한다.


Index API


Index API 특정 index 검색 가능한 형태로 JSON 형식의 document 추가하거나 변경하는데 사용한다. 다음 예제는 "twitter" index id 1 "tweet" type으로 JSON document 추가하는 예제이다.


$ curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
  
"user" : "kimchy",
  
"post_date" : "2009-11-15T14:12:12",
  
"message" : "trying out Elasticsearch"
}'


위의 작업 결과는 다음과 같다.


{
  
"_index" : "twitter",
  
"_type" : "tweet",
  
"_id" : "1",
  
"_version" : 1,
  
"created" : true
}


Automatic Index Creation


Index operation 이전에 index 생성하지 않았다면 자동으로 생성한다. (수동으로 index 생성하는 것에 대해서는 create index API - http://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html - 참고하라.) 그리고 또한, 이전에 만들지 않았다면 자동으로 입력하는 type 맵핑된 type 자동으로 생성한다. (type mapping 수동으로 생성하는 put mapping API - http://www.elastic.co/guide/en/elasticsearch/reference/current/indices-put-mapping.html - 참고하라.)


Mapping 그자체로 굉장히 유연하고 schema-free하다. 신규 필드와 object 특정 type mapping definition 자동으로 추가될 것이다. Mapping definition 대한 자세한 정보를 얻으려면 mapping section 참고하라.


Index.mapping.allow_type_wrapper true 설정하면, JSON document 형식은 type (JSON mapper 사용하면 매우 유용하다) 포함할 있다.


$ curl -XPOST 'http://localhost:9200/twitter' -d '{
 
"settings": {
  
"index": {
    
"mapping.allow_type_wrapper": true
  
}
 
}
}'
{"acknowledged":true}

$ curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
  
"tweet" : {
      
"user" : "kimchy",
      
"post_date" : "2009-11-15T14:12:12",
      
"message" : "trying out Elasticsearch"
  
}
}'


Automatic index creation 모든 node config 파일에 있는 action.auto_create_index false 설정하여 사용하지 않도록 있다. Automatic mapping creation 모든 node config 파일 (또는 특정 index 설정값) 있는 index.mapper.dynamic 값을 false 설정하여 사용하지 않도록 있다.


Automatic index creation white/black list 기반한 패턴을 포함하고 있을 있다. 예를 들면, action.auto_create_index +aaa*, -bbb*, +ccc*, -* 처럼 설정할 수도 있다. (+ 허용, - 불허를 의미한다.)

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/723