예시 elasticsearch reindex와 샤드

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  }
}
'

 

 

https://www.elastic.co/guide/en/elasticsearch/reference/5.4/docs-reindex.html

Reindex API | Elasticsearch Reference [5.4] | Elastic

 

 

-> 근데 알고보니 리인덱스는 인덱스를 생성해놔야 할수있는거였다.

 

-> 인덱스 생성

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html

https://www.elastic.co/guide/kr/elasticsearch/reference/current/gs-basic-concepts.html

 

-> 

이렇게 하면 된다고 과장님이 예시를 보내줌.

근데 number of replica와 number of shards가 뭘까??

 

https://codingexplained.com/coding/elasticsearch/understanding-sharding-in-elasticsearch

샤드 & 리플리카편집
색인은 방대한 양의 데이터를 저장할 수 있는데, 이 데이터가 단일 노드의 하드웨어 한도를 초과할 수도 있습니다. 예를 들어 10억 개의 문서로 구성된 하나의 색인에 1TB의 디스크 공간이 필요할 경우, 단일 노드의 디스크에서 수용하지 못하거나 단일 노드에서 검색 요청 처리 시 속도가 너무 느려질 수 있습니다.

Elasticsearch는 이러한 문제를 해결하고자 색인을 이른바 샤드(shard)라는 조각으로 분할하는 기능을 제공합니다. 색인을 생성할 때 원하는 샤드 수를 간단히 정의할 수 있습니다. 각 샤드는 그 자체가 온전한 기능을 가진 독립적인 "색인"이며, 클러스터의 어떤 노드에서도 호스팅할 수 있습니다.

샤딩은 무엇보다도 2가지 이유로 중요합니다.

콘텐츠 볼륨의 수평 분할/확장이 가능해집니다.
작업을 (어쩌면 여러 노드에 위치한) 여러 샤드에 분산 배치하고 병렬화함으로써 성능/처리량을 늘릴 수 있습니다.
샤드가 분산 배치되는 방식 및 그 문서가 다시 검색 요청으로 집계되는 방식의 메커니즘은 모두 Elasticsearch에서 관리하며 사용자에게는 투명하게 이루어집니다.

언제든 오류가 일어날 가능성이 있는 네트워크/클라우드 환경에서는 어떤 이유에서든 샤드/노드가 오프라인 상태가 되거나 사라지게 될 경우에 대비하여 페일오버 메커니즘을 마련하는 것이 매우 유익하고 바람직합니다. 이러한 취지에서 Elasticsearch에서는 색인의 샤드에 대해 하나 이상의 복사본을 생성할 수 있는데, 이를 리플리카 샤드(replica shard), 줄여서 리플리카라고 합니다.

이처럼 리플리카를 만드는 복제는 무엇보다도 2가지 이유로 중요합니다.

샤드/노드 오류가 발생하더라도 고가용성을 제공합니다. 따라서 리플리카 샤드는 그 원본인 기본 샤드와 동일한 노드에 배정되지 않습니다.
모든 리플리카에서 병렬 방식으로 검색을 실행할 수 있으므로 검색 볼륨/처리량을 확장할 수 있습니다.
요약하자면 각 색인은 여러 개의 샤드로 분할할 수 있습니다. 또한 하나의 색인은 복제하지 않거나(리플리카 없음) 1회 이상 복제할 수 있습니다. 복제되면 각 색인은 기본 샤드(복제 원본 샤드)와 리플리카 샤드(기본 샤드의 복사본)를 갖습니다. 샤드 및 리플리카의 수는 색인별로, 색인 생성 시점에 정의할 수 있습니다. 색인이 생성된 다음 언제라도 탄력적으로 리플리카의 수를 변경할 수 있으나, 샤드 수는 사후 변경이 불가합니다.

기본적으로 Elasticsearch의 각 색인은 기본 샤드 5개, 리플리카 1개를 갖습니다. 따라서 클러스터에 최소한 2개의 노드가 있다면 색인은 기본 샤드 5개, 리플리카 샤드 5개(완전한 리플리카 1개)를 가지므로 색인당 총 10개의 샤드가 존재하게 됩니다.

 

 

하단의 여러 블로그를 참고한뒤 샤딩은 수평 파티셔닝 이라는 것과 파티셔닝이 샤딩을 포함한다는 것을 알게되었다.

위의  index 생성 요청을 보면 body 부분에 

 

{
  "settings": {
    "index": {
      "number_of_replicas": 1,
      "number_of_shards": "5"
    }
  },
  "mappings": {
    "doc": {
      "properties": {
        "boundaries": {
          "type": "geo_shape",
          "tree": "quadtree",
          "precision": "1m",
          "distance_error_pct": 0.009
        },
        "admin_level": {
          "type": "integer"
        }
      }
    }
  }
}

이렇게 적었는데 

number_of_replica란 (우리 팀 기준으로 우리팀은 데이타 노드가 3개인데, 하나를 제외한 나머지 노드? 임)

긍까 number_of_replica를 2로 하면 우리는 3개 가지고 있으니까, replica노드는 2란 소리.

 

number_of_shards란 보통 cpu코어 * node수 라고 하는데 그럼 우리가 cpu10개라고 생각하면 30개의 샤드를 가질 수 있다는 것 같음.

 

이부분에 대해서는 best practice나 공식이 있다고 하니 그걸 찾아봐야겠음 

 

 

https://m.blog.naver.com/PostView.nhn?blogId=indy9052&logNo=220948106201&proxyReferer=https%3A%2F%2Fwww.google.com%2F

 

여기블로그에따르면 cpu core * node +/-1 이정도인데 늘 그런건 아니고 케바케 라고 는 한다. 과장님이 우리꺼두 할때 이렇게 했다구 했음

 

 

https://hanburn.tistory.com/106

https://goodgid.github.io/DB-Sharding/

http://theeye.pe.kr/archives/1917

 

https://aws.amazon.com/ko/blogs/database/run-a-petabyte-scale-cluster-in-amazon-elasticsearch-service/

 

 

https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster