Delete API는 id를 가지고 특정 index에서 JSON document를 삭제한다. 다음 예제는 twitter index, tweet type, id 값이 1인 JSON document를 삭제하는 것을 보여준다.

$ curl -XDELETE 'http://localhost:9200/twitter/tweet/1'

위 delete operation의 결과는 다음과 같다.

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

Versioning

Index된 각 document는 version이 붙여진다. Document를 삭제할 때, version은 지우려고 하는 document가 실제로 지우려고 하는 것으로 적절한지 삭제하는 동안 변경되지 않는지 확신할 수 있게 한다. Delete를 포함하여 Document에  write operation이 매번 실행될 때마다 버전이 증가한다.

Routing

Routing을 제어하기 위해 indexing을 사용할 때, document를 삭제하기 위해서 routing value가 제공되어야만 한다. 예를 들면 다음과 같다.

$ curl -XDELETE 'http://localhost:9200/twitter/tweet/1?routing=kimchy'

위의 결과는 id 1인 document를 삭제할 것이다. 하지만 사용자 기반으로 route될 것이다. 정확한 route없이 삭제하는 경우 document가 삭제되지 않을 수도 있다.

많은 경우에 routing value는 document를 삭제할 때 주어지지 않는다. 그러한 경우에서는 _routing이 required로 맵핑되었지만 routing이 없으면 전체 shard에 있는 값들을 자동으로 삭제할 것이다.

Parent

Parent parameter가 설정되면, routing parameter가 설정되는 것과 기본적으로 동일하다. Parent document를 삭제하는 것은 그 자식까지 자동으로 삭제하지는 않음에 유의하라. 주어진 id에 해당하는 parent의 모든 자식 document를 삭제하는 한가지 방법은 자동으로 생성되고 index된 field _parent로 child index를 삭제하는 쿼리 (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html) 를 수행하는 것이다. 형식은 parent_type#parent_id이다.

Automatic index creation

Delete operation은 이전에 생성되지 않았으면 자동으로 index를 생성한다. (수동으로 index를 생성하는 index API를 확인하라). 그리고 이전에 생성되지 않았다면, 자동으로 특정 type에 대해 맵핑되는 type을 동적으로 생성한다. (mapping type을 수동으로 생성하는 put mapping AP?I에 대해서 확인하라.)

Distributed

Delete operation은 hash값으로 해당 shard id를 얻는다. 그리고 그 id group내의 primary shard로 redirect 되고, id group에 속한 shard replica로 (필요하다면) 복제된다.

Replication Type

[WARNING]

1.5.0에서 deprecated됨.

Async replication을 지정하는 것은 deprecate되었고, 버전 2.0.0에서는 삭제될 것이다.

Operation 복제 (replication)는 async 방식으로 replica로 처리될 수 있다. (operation은 primary shard에 수행되고 리턴될 것이다.) replication parameter는 async로 설정될 수 있다. (기본값은 sync이다.)

Write Consistency

Partition 내 (replication group) 에서 Operation이 active shard 수에 근거하여 실행되도록 허용된다면 통제하라. 그 값은 one, quorum, all이 있다. Consistency parameter는 node level 설정에서 기본적으로 action.write_consistency가 quorum으로 설정되어 있다.

예를 들면, 2개의 replica index를 가지는 N개의 shard가 있다면, operation이 성공하기 위해서는 적합한 partition (quorum)내에 최소한 2개의 active shard가 있어야만 할 것이다. 1개의 replica를 가지는 N개의 shard가 있는 시나리오에서는 하나의 shard active가 있어야 한다. (이 경우에는 one 과 quorum이 같다.)

Refresh

Refresh parameter는 적합한 primary를 refresh하고 delete operation이 일어난 이후 replica shard를 통해 검색할 수 있도록 true로 설정될 수 있다. True로 설정하는 것은 시스템에 과부하를 주지 않을 것이라는 주의 깊은 생각과 확신 하에 이루어져야 한다. (indexing하는데 느려질 수도 있다.)

Timeout

Delete operation을 수행하도록 할당된 primary shard는 delete operation이 수행되는 동안에는 이용할 수 없다. 몇가지 이유로 primary shard는 gateway로부터 즉시 복구되거나 재배치를 겪는다. 기본적으로 delete operation은 primary shard가 이용가능해질 때까지 1분을 기다릴 것이다. 그 이후에는 요청이 실패하고 error로 응답한다. Timeout parameter는 얼마나 오래 기다릴지 명시적으로 지정하는데 사용할 수 있다. 다음 예제에서는 timeout값을 5분으로 설정했다.

$ curl -XDELETE 'http://localhost:9200/twitter/tweet/1?timeout=5m'

Generated fields

Indexing과 refresh 사이에 refresh가 일어나지 않는다면, GET은 document를 가져오기 위해서 transaction log에 접속할 것이다. 그러나 어떤 fields들은 indexing되는 시점에서만 생성된다. 만약 indexing되는 시점에서만 생성되는 field에 접근하고자 한다면, (기본적으로) exception이 발생할 것이다. 만약 transaction log에 ignore_errors_on_generated_fields=true 설정으로  접근한다면 생성된 필드들 중에서 무시할 필드 (ignore field)를 선택할 수 있다.

Getting the _source directly

Document의 _source field를 조회하기 위해서는 별다른 추가적인 content없이 /{index}/{type}/{id}/_source endpoint를 사용하라. 예를 들면 다음과 같다.

curl -XGET 'http://localhost:9200/twitter/tweet/1/_source'

_source의 일부가 리턴될 때, 제어하기 위하여 마찬가지로 동일한 source filtering parameter를 사용할 수 있다.

curl -XGET 'http://localhost:9200/twitter/tweet/1/_source?_source_include=*.id&_source_exclude=entities'

Document가 존재하는지 효과적으로 테스트하기 위해서 _source endpoint에 대해 HEAD variant를 사용할 수 있다. Curl 예제는 다음과 같다.

curl -XHEAD -i 'http://localhost:9200/twitter/tweet/1/_source'

Routing

Routing을 제어하기 위해서 index를 사용할 경우, document를 조회하기 위해서 routing value를 제공해야 한다. 예를 들면 다음과 같다.

curl -XGET 'http://localhost:9200/twitter/tweet/1?routing=kimchy'

위에서 id 1을 갖는 tweet을 조회할 수 있다. 그러나 user에 기반하여 route될 것이다. 적합한 routing없이 조회하는 것은 document가 조회되지 않는 원인이 될 수도 있다.

Preference

조회 요청을 어느 shard replica가 수행할지는 preference로 제어한다. 기본적으로 operation은 shard replica 사이에 랜덤으로 처리한다.

Preference는 다음 값으로 설정될 수 있다.

_primary : operation은 단지 primary shard에서 수행될 것이다.

_local : operation은 가능하면 local에 할당된 shard에서 수행될 것이다.

Custom (string) value

Custom value는 동일한 shard가 동일한 custom value에 대해서 사용될 것을 보장하는데 사용될 것이다. 이것은 서로 다른 refresh 상황에서 서로 다른 shard에 요청할 때, "jumping value"로 도울 수 있다. Sample value는 web session id나 user name과 같은 어떤 것이 될 수 있다.

Refresh

Refresh parameter는 get operation 전에 적절한 shard를 refresh하고 검색 가능하게 하기 위해서 true로 설정할 수 있다. True로 설정하려면 system상 과부하 (indexing하는데 느려짐) 를 야기하지 않는다는 주의와 확신하에 설정하라.

Distributed

Get operation은 hash하여 해당 shard id를 얻는다. 그리고 그 결과에 따라 shard id에 해당하는 replica들 중 하나로 redirect되고 결과를 리턴받는다. Replica는 primary shard와 shard id group내에 있는 replicas를 의미한다. 이것은 replica가 많을수록 더 좋은 GET scaling을 가짐을 의미한다.

Versioning support

만약 현재 버전이 지정된 것과 동일하다면 Document 조회에 version parameter를 사용할 수 있다. 이것은 항상 document를 가져올 수 있는 version type FORCE를 제외하고 모든 version type에서 동일하다.

Elasticsearch는 document의 예전 버전은 저장하지 않음에 유의하라. 단지 현재 버전만 조회할 수 있다.

Get API는 index에서 id로 JSON 형태의 document를 조회한다. 다음 예제는 twitter로 불리는 index, tweet로 불리는 type으로부터 id 값이 1인 JSON document를 얻는 예제이다.

curl -XGET 'http://localhost:9200/twitter/tweet/1'

위의 get operation의 결과는 다음과 같다.

{
   "_index" : "twitter",
   "_type" : "tweet",
   "_id" : "1",
   "_version" : 1,
   "found": true,
   "_source" : {
       "user" : "kimchy",
       "postDate" : "2009-11-15T14:12:12",
       "message" : "trying out Elasticsearch"
   }
}

위의 결과에는 조회하고자 하는 document가 있을 경우, document에 대한 _index, _type, _id, _version, 실제 document이 내용인 _source가 담겨 있다. (response의 found 필드에 있는 값이 true일 경우 데이터 조회 성공을 의미함)

또한 HEAD를 사용하여 document가 있는지 여부를 체크할 수도 있다. 예제는 다음과 같다.

curl -XHEAD -i 'http://localhost:9200/twitter/tweet/1'

Realtime

기본적으로 get API는 realtime이다. 그리고 index의 refresh rate에 영향을 받지 않는다. (검색한 데이터가 보인다.) realtime GET을 사용하지 못하게 하기 위해서는 realtime parameter를 false로 설정하면 된다. 노드 설정에 있는 action.get.realtime의 글로벌 설정값을 false로 해도 된다.

Document를 얻고자 할 때는 가져오고자 하는 fields를 지정하면 된다. 가능하다면 저장되어 있는 fields를 가져올 것이다. (fields는 저장되어 있는 것과 맵핑되어 있다.) realtime GET을 이용할 경우, 저장된 field라는 개념이 없다. (기본적으로 최소한 다음 flush까지의 기간 동안) 따라서 source 그 자체로부터 추출될 것이다. Realtime GET을 사용할 때, fleldㄴ가 저장된다고 하더라도 source로부터 flelds들이 load된다고 가정하는 것도 좋은 방법이다.

Optional Type

Get API는 _type을 optional로 허용한다. 모든 type에 대해서 Id와 첫번째 match되는 첫번째 document를 가져오기 위해서 _all로 설정하라.

Source filtering

기본적으로 get operation은 fields parameter를 사용하지 않거나 _source field를 사용할 수 없다면, _source field의 content를 리턴한다. _source parameter를 사용하여 _source 검색을 끌 수 있다.

curl -XGET 'http://localhost:9200/twitter/tweet/1?_source=false'

전체 _source에서 한 두개의 field만 필요하다면 필요한 부분을 포함시키는 _source_include와 걸러내는 _source_exclude parameter를 사용할 수 있다. 이것은 network overhead를 줄일 수 있기 때문에 large document로부터 partial retrieval (부분 검색)을 하는 경우 특히나 유용하다. 두 가지 parameter는 콤마로 구분된 field list나 wildcard expression을 가질 수 있다. 예를 들면 다음과 같다.

curl -XGET 'http://localhost:9200/twitter/tweet/1?_source_include=*.id&_source_exclude=entities'

Include의 경우만 처리하고 싶다면 다음과 같이 더 짧게 표기할 수 있다.

curl -XGET 'http://localhost:9200/twitter/tweet/1?_source=*.id,retweeted'

Fields

Get operation은 field parameter를 통해서 리턴받을 저장되어 있는 field를 명시할 수 있다. 예를 들면 다음과 같다.

curl -XGET 'http://localhost:9200/twitter/tweet/1?fields=title,content'

이전 호환성 (backward compatibility)를 위해서 요청된 field가 저장되어 있지 않다면, _source (파싱하여 추출)로부터 가져올 것이다. 이 기능은 source filtering parameter를 통해서 대체할 수 있다.

Document에서 추출된 Field 값은 항상 array로 리턴된다. _routing과 _parent 필드와 같은 Metadata field는 결코 array로 리턴되지 않는다. 또한 leaf field (개별 필드)는 field option을 통해 리턴될 수 있다. 따라서 object field는 리턴될 수 없고, 그러한 요청은 실패할 것이다.