[Updating Documents]

Document를 index하고 replace할 수 있을 뿐만 아니라, 또한 document를 update할 수도 있다. Elasticsearch는 실제로는 제자리 (이전 데이터를 덮어쓰는) 업데이트를 하지 않는다. Elasticsearch는 old document를 삭제하고, 한번 업데이트 했다는 내용이 적용된 새로운 document를 index한다.

다음 예제는 이전 document (ID 1)가 어떻게 이름을 "Jane Doe"로 변경한 새로운 document로 업데이트 되는지를 보여준다.

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty' -d '
{
  "doc": { "name": "Jane Doe" }
}'

다음 예제는 이전 document (ID 1)가 어떻게 이름을 "Jane Doe"로 변경하고 age 필드가 새로 추가된 새로운 document로 업데이트 되는지를 보여준다.

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty' -d '
{
  "doc": { "name": "Jane Doe", "age": 20 }
}'

업데이트는 간단한 스크립트로 수행될 수도 있다. 다음에 나타나는 dynamic script는 1.4.3에서는 기본적으로 사용할 수 없다. 더 자세한 내용은 Scripting Docs (http://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting.html)에서 확인할 수 있다. 다음 예제는 script로 나이를 5살 증가시키는 것이다.

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty' -d '
{
  "script" : "ctx._source.age += 5"
}'

위의 예제에서 ctx._source는 업데이트 되는 현재 source document를 나타낸다.

스크립트는 한번에 하나의 document에 대해서만 update를 수행할 수 있다. 나중에는 elasticsearch에서 주어진 query 조건에 따라 여러 document를 update하는 기능을 지원할 것이다. (SQL문의 Update - Where 문과 유사한 기능 제공 예정)

Elasticsearch는 data manipulation과 준 실시간 (near realtime) 검색 기능을 제공한다. 기본적으로 실제로 data를  index/update/delete한 시점에서 검색 결과로 나타나기까지 1초 delay (refresh interval)가 발생한다. 이것은 transaction이 완료된 이후에 즉시 data가 나타나는 SQL과 같은 다른 platform과 가장 중요한 차이점이다.

[Indexing/Replacing Documents]

앞에서 어떻게 single document를 index하는지 살펴보았다. 그때 command를 다시 호출해 보자.

curl -XPUT 'localhost:9200/customer/external/1?pretty' -d '
{
  "name": "John Doe"
}'

위의 command는 customer index에 external type으로 ID 1인 document를 index할 것이다. 만약 다른 document (혹은 같은)로 위의 command를 다시 실행하면, elasticsecarh는 기존에 존재하는 ID 1에 새로운 document로 replace할 것이다.

curl -XPUT 'localhost:9200/customer/external/1?pretty' -d '
{
  "name": "Jane Doe"
}'

위의 command는 ID 1인 document의 내용 중에서 이름을 "John Doe"에서 "Jane Doe"로 변경한다. 다른 한편, 만약 다른 ID를 사용한다면, 새로운 document가 index되고, 기존에 입력한 document는 변경되지 않고 남아 있게 된다.

curl -XPUT 'localhost:9200/customer/external/2?pretty' -d '
{
  "name": "Jane Doe"
}'

위의 결과로 ID 2를 가지는 새로운 document가 index된다.

Index될 때, ID part는 optional이다. ID가 지정되지 않으면 elasticsearch는 random ID를 생성하고 그것을 이용해 document를 index한다. Elasticsearch가 생성한 ID (이전에 명시적으로 지정한 ID도 마찬가지로)는 index API call의 한 부분으로 리턴된다.

명시적인 ID를 지정하지 않고 document를 index하기 위한 예제는 다음과 같다.

curl -XPOST 'localhost:9200/customer/external?pretty' -d '
{
  "name": "Jane Doe"
}'

명시적으로 ID를 지정하지 않을 때는 PUT 대신 POST를 사용한다.

[Delete an Index]

이제 앞에서 생성했던 index를 삭제하고 다시 index list를 조회해 보자.

curl -XDELETE 'localhost:9200/customer?pretty'
curl 'localhost:9200/_cat/indices?v'

응답 결과는 다음과 같다.

curl -XDELETE 'localhost:9200/customer?pretty'
{
  "acknowledged" : true
}
curl 'localhost:9200/_cat/indices?v'
health index pri rep docs.count docs.deleted store.size pri.store.size

Index가 성공적으로 삭제되었음을 나타낸다. 그리고 아무것도 없이 cluster가 시작되었을 때로 되돌아 갔음을 알 수 있다. 이동하기 전에, API command에 대해서 조금 더 깊이 들어가서 배워 보자.

curl -XPUT 'localhost:9200/customer'
curl -XPUT 'localhost:9200/customer/external/1' -d '
{
  "name": "John Doe"
}'
curl 'localhost:9200/customer/external/1'
curl -XDELETE 'localhost:9200/customer'

위의 command를 주의 깊게 살펴보면, elasticsearch에서 어떻게 data에 access하는지 볼 수 있다. 다음과 같은 패턴으로 요약될 수 있다.

curl -X<REST Verb> <Node>:<Port>/<Index>/<Type>/<ID>

이러한 REST access 패턴은 모든 API command 구석구석 숨어 있다. 여러분이 이것을 기억하고 있다면, 좋은 머리로elasticsearch를 마스터할 수 있다.

[Index and Query a Document]

이제 customer index에 무엇인가를 집어 넣어 보자. 앞의 내용에 대한 기억을 되살려보면, document를 index하기 위하여 elasticsearch에 index의 어느 Type인지를 알려주어야 한다.

Customer index에 "external" type 다음과 같은 간단한 customer document를 index해 보자.

JSON Document는 {"name":"John Doe"}이다.

curl -XPUT 'localhost:9200/customer/external/1?pretty' -d '
{
  "name": "John Doe"
}'

응답 결과는 다음과 같다.

curl -XPUT 'localhost:9200/customer/external/1?pretty' -d '
{
  "name": "John Doe"
}'
{
  "_index" : "customer",
  "_type" : "external",
  "_id" : "1",
  "_version" : 1,
  "created" : true
}

위에서 살펴보면, 새로운 customer document가 customer index내에 성공적으로 생성되었음을 알 수 있다. 생성된 document는 내부적으로 특정 index time에 1이라는 ID를 갖는다. Elasticsearch가 document를 index하기 전에 명시적으로 customer index를 먼저 생성하도록 요구하지 않는다는 것에 주목하라. 이전 예제에서 살펴보면, elasticsearch는 이전에 customer index가 존재하지 않으면 자동으로 customer index를 생성한다. 이제 index된 document를 조회해 보자.

curl -XGET 'localhost:9200/customer/external/1?pretty'

응답 결과는 다음과 같다.

curl -XGET 'localhost:9200/customer/external/1?pretty'
{
  "_index" : "customer",
  "_type" : "external",
  "_id" : "1",
  "_version" : 1,
  "found" : true, "_source" : { "name": "John Doe" }
}

found 필드 외에는 모두 일반적으로 나타나는 필드이다. 이전 단계에서 index된 JSON document는 _source 필드에 있다.

[Create an Index]

자, 이제 "customer"라는 이름을 가지는 index를 생성해 보자. 그리고 그 후, 다시 모든 index list를 조회해 보자.

curl -XPUT 'localhost:9200/customer?pretty'
curl 'localhost:9200/_cat/indices?v'

첫 번째 command는 http PUT method로 "customer"라는 이름을 갖는 index를 생성한다. 간단히 pretty를 맨 끝에 호출하여 JSON 응답을 출력할 수 있다.

응답 결과는 다음과 같다.

curl -XPUT 'localhost:9200/customer?pretty'
{
  "acknowledged" : true
}

curl 'localhost:9200/_cat/indices?v'
health index    pri rep docs.count docs.deleted store.size pri.store.size
yellow customer   5   1          0            0       495b           495b

두 번째 command의 응답 결과를 통해서 customer 이름의 index 1개가 있고, 5개의 primary shard와 1개의 replica가 있음을 알 수 있다. 아직 document는 없다.

Customer index는 yellow health가 tag되어 있음을 알 수 있다. 이전에 논의했던 내용을 되새겨 보면, yellow는 아직 replica가 할당되어 있지 않았음을 의미함을 알 수 있다. 그 이유는 elasticsearch에서 index에 대해 하나의 replica를 default로 생성했기 때문이다. 이 순간, 하나의 node만을 가지고 있기 때문에 또 다른 node가 cluster에 join할 때까지 replica는 할당되지 않는다. Replica가 second node에 할당되면 health status는 green으로 바뀐다.