ElasticSearch Getting Started - 1

Elasticsearch Getting Started 에 대해서 번역

클러스터 탐험

1. REST API
   https://www.elastic.co/guide/en/elasticsearch/reference/current/_exploring_your_cluster.html#_the_rest_api
   
   우리 노드(그리고 클러스터)을 올리고 가동하고 있죠.
   다음 단계는 이것와 커뮤니케이션을 어떻게 하는지에 대해서 이해하도록 합니다.
   운좋게시리, Elasticsearch는 여러분의 클러스터와 소통하는데 사용할수 있는 아주 포괄적이고 파워풀한 REST API을 제공합니다.
   API을 가지고 할수 있는 몇가지를 진행해보도록 합시다.
   
   - 여러분의 클러스터, 노드, Index health, 상태 그리고 통계를 체크합니다.
   - 여러분의 클러스터, 노드 , index data, metadata를 관리합니다.
   - CRUD 동작하고, 여러분의 인덱스들을에 대해 동작을 찾아보도록 합니다.
   - 보다 업그레이드된 찾기 기능을 실행해보도록 합시다.
     예를 들면, paging, sorting, filtering , scripting, aggregation 등등..
   
   
2. Cluster Health
   https://www.elastic.co/guide/en/elasticsearch/reference/current/_cluster_health.html
   
   클러스터들이 어떻게 동작하는지 볼수 있는 기본 Health check에 대해서 알아봅시다.
   우리는 Health Check하기 위해서는 curl 을 사용하겠지만, HTTP/REST 호출을 할수 있는 툴이면 어떤것이든 괜찮습니다.
   우리가 Elasticsearch를 시작한 같은 노드 상에 있다고 가정하고, 다른 컴맨드 창을 띄워봅시다.
   
   Cluster health을 체크하기 위해서는, _cat API을 사용할 것입니다.
   VIEW IN CONSOLE을 클릭해서 Kibana's Console에서 명령을 실행 할수 있습니다.
   또는 COPY AS CURL  링크를 클릭해서 curl을 가지고 터미널에 아래 명을 붙여넣어서 실행할 수 있습니다.
   
   
   GET /_cat/health?v
   
   
   
   응답은 아래와 같죠
   
   
   epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
   1475247709 17:01:49  elasticsearch green           1         1      0   0    0    0        0             0                  -                100.0%
   
   
   
   elasticsearch 라고 하는 우리의 클러스터는 green 상태와 함께 올라와 있다는 것을 확인 할 수 있습니다.
   
   cluster health을 요청할 때마다, green, yellow, red 중에 하나를 받게 됩니다.
   Green은 모든 것이 괜찮다(클러스러는 완전하게 동작합니다.)
   Yellow는 모든 데이터가 사용가능하다란 뜻입니다. 하지만 몇가지 replicas가 아직 할당되지 않았다란 뜻입니다.
   (클러스러는 완전하게 동작합니다.)
   Red는 몇몇 데이터가 어떤 이유에선가 사용 할 수 없다는 것입니다.
   클러스터가 red라고 해도, 아직 부분적으로 동작합니다.
   (i.e 사용가능한 사드들로 부터  검색 요청들을 제공하는 것을 유지할것입니다.)
   하지만 데이터를 잃어버리고 있다면, 가능한 빨리 고칠 필요가 있습니다.
   
   위의 요청으로 부터, 우리는 1 node의 total 과 아직 안에 데이터를 갖고 있지 않을때까진 0 shard을 가지고 있는것을 볼수 있습니다.
   우리가 기본 클러스터 이름(elasticsearch)을 사용하고 있고,
   Elasticsearch가 기본으로 같은 머신 안에서 다른 노드를 찾기 위해 unicast network discovery를 사용하고 있다면,
   여러분의 컴퓨터에 한 노드 이상 예기치 않게 기동하고 하나의 싱글 클러스트로 모든 노드들을 조인하는 것이 가능합니다.
   이 시나리오상에서, 여러분은 위의 response에 1개의 노드 이상 있는 것을 보게 될것 입니다.
    
   우리 클러스터에 노드 리스트를  가져올수 있습니다.
   

   GET /_cat/nodes?v
   

   
   
   응답은 아래와 같습니다.
   
   

   ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
   127.0.0.1           10           5   5    4.46                        mdi      *      PB2SGZY
   

   
   
   우리 클러스트 상에 현재 존재하는 PB2SGZY 라는 이름의  하나의 노드를 볼수 있습니다.
   
   
3. List All indices
   https://www.elastic.co/guide/en/elasticsearch/reference/current/_list_all_indices.html
   우리의 indices(지수)을 찝어봅시다.
   
   

   GET /_cat/indices?v
   

   
   
   응답은 
   

   health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
   

   
   
   클러스터에 indices가 아직 없다란 뜻입니다.
   
   
4. Create an Index
   https://www.elastic.co/guide/en/elasticsearch/reference/current/_create_an_index.html
   
   customer 라는 이름의 인덱스를 생성해 봅시다.그리고 리스트를 확인해볼까요?
   
   

   PUT /customer?pretty
   GET /_cat/indices?v
   

   
   
   PUSH 동사를 사용해서 customer라는 이름의 인덱스를 생성했습니다.
   JSON response를 pretty-print 하라고 전달하라는 pretty 를 호출 끝에 더했습니다.
   그리고 응답을 보면
   
   

   health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
   yellow open   customer 95SQ4TSUT7mWBT7VNHH67A   5   1          0            0       260b           260b
   

   
   
   
   customer 라는 인덱스 1개를 이젠 보유하고 있고,
   5 primary shard를 가지고 있고, 1 replica(기본값) , 그것안에는 0 document를 포함하고 있다라는 내용을 위에서 보여주고 있습니다.
   
   근데 health 태그가 yellow로 되어 있네요
   앞서서 이야기한대로, yellow가 뜻하는 것은 몇몇 복제본들이 아직 할당되지 않았다는 것을 뜻하는 것이였죠.
   이유는 Elasticsearch는 기본으로 이 인덱스에 대해 하나의 복제본를 생성하기 때문입니다.
   순식간에 동작하는 하나의 노드를 가지고 있으므로, 다른 노드가 클러스터에 조인될때 까지
   복제본(replica) 한개를 할당 할수 없기 때문입니다.(고가용성을 위해) 
   복제본이 두번째 노드안에 할당된 것을 얻었을땐, 해당 인덱스에 대한 health 상태는 green으로 변경될 것입니다.
   
   
5. Index and Query a Document
   
   이제 우리의 Customer 인덱스에 무언가를 넣어보도록 합시다.
   document를 인덱스하기 위해서 이전에 기억해야 할것은,
   인덱스가 진행해야하는 어떤 타입인지에 대해서 ElasticSearch에게 전달해야 합니다.
   
   간단한 customer document을 customer index 안에 인덱스 해봅시다.
   external 타입으로, 1의 ID를 갖는...
   
   

   PUT /customer/external/1?pretty
   {
     "name": "John Doe"
   }
   

   
   
   응답을 보면
   
   

   {
     "_index" : "customer",
     "_type" : "external",
     "_id" : "1",
     "_version" : 1,
     "result" : "created",
     "_shards" : {
       "total" : 2,
       "successful" : 1,
       "failed" : 0
     },
     "created" : true
   }
   

   
   
   뭐, 성공적으로 customer index와 external type 안에 생성된 customer document을 볼수 있습니다.
   document는 인덱스 타임에 우리가 명시했던, 1의 internal id를 가지고 있습니다.
   
   Elasticsearch는 여러분들에게 명쾌하게 인덱스를 우선 생성하라고 요구하지 않습니다.
   전에 여러분들은 그것안에 documents를 인덱스 할수 있습니다.
   이전 예제에서, 만약 사전에 이미 존재하지 않았더라면,
   Elasticsearch 는 자동으로 customer index를 생성 할것입니다.
   
   자 우리가 막 인덱싱한 document를 가져와봅시다.
   
   

   GET /customer/external/1?pretty
   

   
   
   우리는 요청한 ID 1 과 이전 단계에서 인덱싱한 full JSON document를 리턴하는 _source 필드을 포함하는
   document를 발견한 것을 알수 있는 필드 이외에 특별한 건 없습니다.
   
   
6. Delete an Index
   
   생성한 index를 지워보고, 다시 리스트로 확인해봅시다.
   
   

   DELETE /customer?pretty
   GET /_cat/indices?v
   

   
   
   응답을 보면
   
    

   health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
   

   
   
   잘 지웠습니다.
   
   넘어가기 전에 전체적으로 정리를 해봅시다.
   
   

   PUT /customer
   PUT /customer/external/1
   {
     "name": "John Doe"
   }
   GET /customer/external/1
   DELETE /customer
   

   
   
   
   위의 명령들을 주의깊게 공부한다면,
   우리는 실제로 Elasticsearch안에서 데이터를 어떻게 접근하는지에 대한 패턴을 확인할수있습니다.
   위 패턴을 정리하면 아래와 같습니다.
   
   

   <REST Verb> /<Index>/<Type>/<ID>
   

   
   
   
   REST 접근 패턴은 모든 API 명령어 전반에 널리 퍼져있습니다. 
   여러분이 간단하게 이걸 기억할수 있다면, 여러분은 Elasticsearch를 마스터하는 좋은 시작점을 갖게 될것입니다.