More than 5 years have passed since last update.

Elasticsearchで最初にぶつかるワードたち

Last updated at 2018-03-06Posted at 2018-02-23

Elasticsearchで最初にぶつかるワードの意味などをRDBに例えて覚えたので、それらを書いておく。
加えて3日ほどで覚えた知識も併せて書く。

対応表

Elasticsearch	RDB	備考
index	テーブル	elasticはスキーマレスだがmappingというカラムの型情報がある
type	該当なし
document	row	行データ
node	DBサーバー	保存領域の数
shard		データ保存の分割数。検索処理の並列数にも影響する
primary shard	master	水平分割数
replica shard	slave	レプリケーション数

RDBのデータベースとテーブルの関係と書かれていることが多いが、Elasticsearch6ではindex(1) : type(1)、さらに将来ではtypeは削除されるかもしれないので、indexがテーブルに該当することとなる。

typeは今後なくなるかつ6では1つしか定義できないので、お気をつけください。基本、ないものと考えていただくのが良いかと。
— Jun Ohtani (@johtani) 2018年2月20日

はい。理由や今後のスケジュールはこちらにあります。https://t.co/Ir5z2swCP9 複数タイプに関してはどう考えればいいかなどもあるので参考にしていただければと。
— Jun Ohtani (@johtani) 2018年2月20日

"(データ名)-yyyy.mm.dd" の形式が良いかと思われる。

logstash形式でデータを保存すると、indexが"logstash-yyyy.mm.dd"となる。kibanaもこの形式を標準にしている。
この形式だと日付パーテーションの役割も兼ねるので、n日以前のデータ削除としても使える。
"logstash-yyyy.mm.dd"ではなく"(データ名)"を先頭を付けるのは、日付パージの粒度をデータ毎に調整できるから。（日単位、週単位、月単位）
index作成後にshard(分割数)の変更ができないので、日単位でindexを作ると、後になって日毎のデータ量が増えてきた時に分割数を増やすことができる
Elasticsearchは利用するindexを前方一致で指定できるので、末尾に日付が付いていても人間の検索コストは増えない。RDBだとtableのpartitionを超えて検索するのに似ている。

primary shard = p
replica shard = r
と省略します

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1||
||node2|r1||
||node3|(空き)||

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1||
||node2|r1||
||node3|r2||

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1||
||node2|p2||
||node3|(空き)||

とか

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1|p2|
||node2|(空き)||
||node3|(空き)||

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1|p2のr1|
||node2|p2|p1のr1|
||node3|空き||

とか

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1|p2のr1|
||node2|p2||
||node3|p1のr1||

|index|node|shard||
|:--|:--|:--|:--|:--|
|index|node1|p1|p2のr1|
||node2|p2|p1のr1|
||node3|p1のr2|p2のr2|