-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