[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으로 바뀐다.

[List All Indexes]

이제 index에 대해서 가만히 들여다 보자.

curl 'localhost:9200/_cat/indices?v'

응답은 다음과 같다.

curl 'localhost:9200/_cat/indices?v'
health index pri rep docs.count docs.deleted store.size pri.store.size

아직 cluster에 index가 하나도 없다는 것을 의미한다.

[Cluster Health]

기본적인 cluster health check부터 시작해 보자. 이를 통해 우리는 cluster가 어떻게 작업을 수행하고 있는지 볼 수 있다. Curl을 사용하여 health check하겠지만, HTTP/REST call을 수행할 수 있는 어떤 tool을 사용해도 된다. Elasticsearch를 실행한 node에 있다고 가정하고, 또 다른 command shell window를 open하자.

Cluster health check하기 위해서, _cat API를 사용할 것이다. 이전에 node의 endpoint 주소를 기억해보면 9200 포트를 사용했다.

curl 'localhost:9200/_cat/health?v'

응답 결과는 다음과 같다.

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
1394735289 14:28:09  elasticsearch green           1         1      0   0    0    0        0

Cluster name이 elasticsearch임을 알 수 있다. 현재 cluser 상태는 green status이다.

Cluster health에 대해 언제든지 질의하면, green/yellow/red 중 한가지 상태를 알 수 있다. Green은 모든 것이 좋은 상태 (cluster가 모든 기능을 정상적으로 수행)임을 의미하고, yellow는 모든 data를 이용할 수는 있지만, 몇몇 replicas가 아직 할당되지 않은 상태(cluster가 모든 기능을 정상적으로 수행)임을 의미하고, red는 몇몇 데이터를 이용할 수 없는 상태임을 의미한다. Cluster가 red 상태일지라도 부분적으로 동작한다. (이용 가능한 shard에 있는 데이터에 대한 검색 요청을 지속적으로 수행) 하지만, 유실한 데이터가 있기 때문에 ASAP(As Soon As Possible) 문제 상황을 fix해야 한다.

위의 응답 결과로부터 우리는 전체 1개의 node가 있고, 0개의 shard가 있음을 알 수 있다. 왜냐하면 아직 데이터가 없기 때문이다. Default cluster name (elasticsearch)를 사용했고, 다른 node를 discover하기 위해서 elasticsearch는 multicase를 사용하므로 네트워크 상에서 하나 이상의 node를 우연하게 실행하면 모두 cluster에 join하게 된다. 이 시나리오에서는 응답 결과로 1개 이상의 node를 볼 수 있을 것이다.

다음과 같이 cluster에 있는 node list를 볼 수 있다.

curl 'localhost:9200/_cat/nodes?v'

응답은 다음과 같다.

curl 'localhost:9200/_cat/nodes?v'
host         ip        heap.percent ram.percent load node.role master name
mwubuntu1    127.0.1.1            8           4 0.00 d         *      New Goblin

여기서 우리는 현재 cluster에 있는 단일 node name이 "New Goblin"임을 알 수 있다.

[The REST API]

이제 우리는 실행된 node (cluster)를 가지고 있다. 다음 단계는 실행중인 node(cluster)와 어떻게 communicate하는지를 이해하는 것이다. 운이 좋게도, elasticsearch는 이해하기 쉽고 강력한 REST API를 제공한다. 여러분은 REST API를 통해서 cluster와 interact할 수 있다. API를 이용해서 할 수 있는 작업들은 다음과 같다.

• Cluster, node, index health, status, statistics 체크

• Cluster, node, index data, metadata 관리

• Index에 대한 CRUD(Create, Read, Update, Delete) 및 검색 작업 수행
• Paging, sorting, filtering, scripting, faceting, aggregation 등의 많은 advanced search 작업 실행