Elasticsearchの用語が覚えられないのでまとめた

https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html
ここに記載されている内容のまとめです。
5.4系だと日本語訳があるんですが、いまいちピンとこないので自力でまとめました。
ただ、違いとしてはおそらくTypeがDeprecatedになったことくらいしかないです。

# クラスタ

- 1つまたは複数のノードの集合。
- ユニークな名前を持つ。デフォルトは"elasticsearch". 
- nodeは名前でクラスタを判定するので重要。
- 従って、クラスタ名を使いまわすとノードが誤ったクラスタに集まるので注意。
- 例えばlogging-dev, logging-stage, and logging-prodといった風に分けると良い。
- 一つのノードしか持たないクラスタをつくるのもOK
- ユニークな名前をつけた複数のクラスタを持ってもOK

# ノード
- クラスターを構成する一つのサーバー。
— データの保存、インデックスと検索機能を提供する。
- クラスタと同様に、起動時にuuidを持つ。任意の名前をつけられる。
- クラスタ名を元にノードを探し出し、複数のノードによるクラスタを構成する。
- 単一クラスタだと、いくつでもノードを持てる。
- NW内でノードがひとつだけ存在する場合、それ自体がデフォルトでelasticsearchという名前のクラスタになる。

# Index
- 同じ特徴を持ったデータの集合。顧客情報、製品情報など。lowercaseで名前をつける必要がある。
- クラスタ内で幾つでも定義できる。
※複数形だとindicesになるので注意。APIはこの形

# Type
同じインデックスの中で異なるタイプを指定することができたが、6.0.0.以降ではDeprecatedになった。

# Document
- インデックスされる情報の単位。JSONで表現される。
- 顧客情報の例であれば、ひとりの顧客の情報がこれに当たる。

# Shards & Replicas
- 一つのインデックスは、一つのノードのハードウェア許容量を超えた大容量のデータを保存できる。
- 例えば、1TBを要する10億のドキュメントは一つのノードでは実現できない。
- この問題を解決するために、インデックスをシャードと呼ばれる複数のpieceに分解できる。
- インデックスを作成するときに、必要なシャードの数を指定することができる。
- それぞれのシャードは独立しており、必要な機能を提供できる。

## シャーディングは以下の理由から重要
1. コンテンツのボリュームを水平に分割・分散できる。
2. シャード間で処理を分散できるのでパフォーマンス・スループットがあがる
- シャードがどのような仕組みで提供されるのか、検索のリクエストに対してどのようにドキュメントを集めるのか、などはElasticsearchにお任せできる。
- いつ障害が起きるかわからないNW・クラウド環境では、シャード・ノードがオフラインになったり消失したときのためにフェールオーバーの仕組みを持っておくことが大切。
- 1つ以上のレプリカシャードを持っておくことも可能。

## レプリケーションは以下の理由から重要
1. シャード・ノードが消失した際にも高い可用性を提供する。そのため、レプリカシャードはオリジナルのシャードとは同じノードには存在しない。
2. 全てのレプリカシャードで検索リクエストが並行処理されるため、検索のスループットがスケールアウトする。

まとめると、
- それぞれのインデックスは複数のシャードに分割できる。
- インデックスは0以上のレプリケーションを作成できる。
- レプリケーションされると、それぞれのインデックスはプライマリーシャードとレプリカシャードに分かれる。
- シャードとレプリカシャードの数は、インデックスが作成されたタイミングで決まる。
- インデックスが作成された後でも、いつでも数の変更は可能。
- 変更には`_shrink and _split APIs`を用いる。
- ちょちょいと終わる作業ではないので、最初に正しいシャードの数を設計しておく方が良い。
- デフォルトで、インデックスには5つのプライマリーシャードと1つのレプリカが割り当てられる。
- 二つのノードがクラスタ内にあれば、インデックスは5つのプライマリーシャードと5つのレプリカシャードができることになる。

備考
- ElasticsearchのシャードはLucene indexである。
- 一つのLucene indexには、As of LUCENE-5843の場合、2,147,483,519 (= Integer.MAX_VALUE - 128)までのドキュメントが保存できる。 - `_cat/shards API`でシャードをモニタリングできる。

# API
## ヘルスチェック
`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
1539490886 04:21:26  docker-cluster yellow          1         1     26  26    0    0       25             0                  -                 51.0%
```

## ステータスの意味

- Green オールオッケー
- Yellow クラスタの準備はできていて、全てのデータは使用可能だがいくつかのレプリカがまだ完成していない
- Red いくつかのデータが利用できない状態

`GET /_cat/nodes?v` ノードの一覧を返す
`GET /_cat/indices?v`インデックスの一覧を返す

```
health status index               uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .kibana             1Uqnv0AmT7WnKLZ6Gk0xRw   1   0          5            0     29.4kb         29.4kb
yellow open   logstash-2015.05.19 KVMlcSGMTL6Iuye5uNoDAA   5   1       4624            0     23.1mb         23.1mb
yellow open   logstash-2015.05.18 I6AVifyyRnKbahszBHy7vg   5   1       4631            0     22.9mb         22.9mb
yellow open   logstash-2015.05.20 iGvYwcGKScCN9wD69JN7dw   5   1       4750            0     23.6mb         23.6mb
yellow open   shakespeare         -mcK6VwWQSuh9RH0FbWErQ   5   1     111396            0     22.5mb         22.5mb
yellow open   bank                0HCdBbSeQ_uo5UbTg27uUw   5   1       1000            0    474.1kb        474.1kb

```

この例だと、primaryが5つあって、replicationが1つあることがわかる。