-Elasticsearchを独立させた。Solrと同じくLuceneベース

*構成 [#rad07179]

|INDEX|RDBのDatabaseに相当。この単位でSHADE数が決まるので、更新頻度が違うものはINDEXを分ける|
|シャード|インデックスを何分割するか?作成時のみしか指定できず|
|TYPE|INDEXに格納されるドキュメントの型。テーブルみたいなもの|
|DOCUMENT|RDBの1レコード|
|FIELD|列定義|
|CLUSTER|NODEの集合|
|NODE|ESの1プロセス。最小構成単位である|

シャードの数はノードの数に合わせておくと良いらしい。ノードが少ないのにシャードを増やしても早くならない。

-更新は苦手なのでINDEX単位で日付を付与して、古くなったものはINDEX毎すてていく

|RDB|Elasticsearch|
|Databases|Indices|
|Tables|Types|
|Rows|Documents|
|Fields|Columns|

*ノードの種類 [#i320b5b1]

-マスターノード(Master-eligible node)
node_master: trueになっているものがマスターノードになれる。デフォルトtrue。マスターノードはクラスターをコントロールするノードである。
-データノード(node_data: true)
CRUDに関する動作を請け負うノード
-クライアントノード(masterでもなくdataでもない)
データも保持せず、マスターにも昇格しない。検索時の負荷分散など

シャードはノード数と同じにしておくと良いのだが、将来的にノードを増やすことで負荷分散することを考えているのであればノード数以上にシャードを設定しておくのもあり。


*シャードの数 [#sdb5a88e]

https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

*INDEX設計 [#uc7cf228]

一つのINDEXでシャードの数が決まるので、スケールさせる前提であればINDEXを分ける。また親子関係がある場合は一つのINDEXにする必要がある。INDEX名を適当に決めるとINDEX TEMPLATEが適用できなくなってしまうので、きちんと命名規約を決めておくこと!


#counter


トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS