注：古いです（es1.0か0.90くらいのときに書いたもの）
glossaryの超適当まとめ
死ぬほど初心者です。お気づきの点がございましたらご指摘の程よろしくお願い致します。
- analysis
全文をtermに変換する処理 - cluster
同一の名前を持つnodeの集合 - document
elasticsearchに保存されるjsonデータ。RDBにおける行みたいなもん - id
documentの識別子 - field
RDBにおけるカラムみたいなもん。ネスト構造も許可 - index
RDBにおけるデータベースみたいなもん。typeを定義するmappingを複数持てる。論理的な名前空間で、1つ以上のprimary shardにマッピングされ、0個以上のreplica shardを持つことができる - mapping
RDBにおけるスキーマ定義みたいなもん。全てのindexは、index内のtypeを定義したmappingを持つ。明示的に指定することもできるし、自動で生成することも可能 - node
elasticsearchインスタンスを実行している単位。1サーバ上に複数ノードを起動できるが、テスト以外では、1サーバ1ノードにした方が良い - primary shard
documentはprimary shardに保存される。documentをインデックスするとき、まずprimary shardに保存され、その後replica shardに反映される。デフォルトでは1indexに5個のprimary shardを持つ。数は設定可能だが、一度作成したindexのprimary shardの個数は変更できない - replica shard
primary shardのコピー。primary shardは0個以上のreplicaを持てる。primaryが死んだ時にreplicaがprimaryに昇格できるため、フェイルオーバーできる。また、参照系はprimaryかreplicaが対象になるので、パフォーマンス向上になる。デフォルトではprimary shardは1つのreplicaを持つが、数は動的に変更可能。replicaはprimaryと同一nodeに作られることは無い - routing
documentをインデックスすると、1つのprimary shardに保存されるが、そのshardは「routing」値をハッシュ化した値で選択される。デフォルトでは、「routing」値はdocumentのidから導出されるが、親を持つようなdocumentの場合は親のidが利用され、親子が同一shardに配置されることを保証する。routingはインデックス時や、mapping設定で上書き可能 - shard
Luceneインスタンス。elasticsearchによって管理されるworker。indexはprimary shard、replica shardを指す論理的な名前空間と言える。shardの数を設定する時以外で、shardを直接参照する必要はなく、代わりにindexを扱う方が良い。elasticsearchはcluster内の全てのnode間でshardを分散する。nodeの障害時や、新規ノードの追加時には自動でshardを移動することができる - source field
デフォルトでは、参照リクエストに対して、documentを「_source」フィールドに保存して返す。 - term
elasticsearchにインデックスされた値。foo, Foo, FOOは等価では無い。termクエリを使って検索できる。 - text
普通の構造化されていないテキストデータ。デフォルトではtextはanalyzeされtermに変換され、indexに保存される -
type
RDBにおけるテーブルみたいなもん。documentを特徴付けるfieldのリストから構成される。mappingはdocumentの各fieldがどのようにanalyzeされるかを定義するInitially, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”.
This was a bad analogy that led to incorrect assumptions.
Removal of mapping types | Elasticsearch Reference [6.0] | Elasticだそうです