Elasticsearchのセグメントについて
Elasticsearchの各シャードはインデックスであると仮定していました。しかし、私はどこかで各セグメントがLuceneインデックスであることを読みました。
セグメントとは正確には何ですか？検索パフォーマンスにどのように影響しますか？デフォルトのElasticsearch設定で毎日約450 GBのサイズに達するインデックスがあります（毎日新しいインデックスを作成しています）。
curl -XPOST "http://localhost:9200/logstash-2013.03.0$i_optimize?max_num_segments=1"を実行すると、num_committed_segments=11とnum_search_segments=11を取得します。
上記の値は1であってはなりませんか？たぶんindex.merge.policy.segments_per_tierの値が原因でしょうか？とにかくこの層は何ですか？
Elasticsearchでは「インデックス」という言葉が少し乱用されますが、これはあまりにも多くのものに適用されます。
説明する：
インデックス
Elasticsearchの「インデックス」は、リレーショナルDBのデータベースに少し似ています。データを保存/インデックスする場所です。しかし、実際には、それはあなたのアプリケーションが見るものです。内部的には、インデックスは1つ以上のシャードを指す論理的な名前空間です。
また、「インデックス付けする」とは、データをElasticsearchに「入れる」ことを意味します。データは（検索用に）保存され、検索用に「インデックス化」されます。
逆索引
「逆索引」は、Luceneがデータを検索可能にするために使用するデータ構造です。データを処理し、一意の用語またはトークンを引き出して、それらのトークンを含むドキュメントを記録します。詳細については、 http://en.wikipedia.org/wiki/Inverted_index を参照してください。
破片
「破片」はLuceneのインスタンスです。それはそれ自体で完全に機能する検索エンジンです。 「インデックス」は単一のシャードで構成することもできますが、通常、インデックスを成長させて複数のマシンに分割できるように、複数のシャードで構成されます。
「プライマリシャード」は、ドキュメントのメインホームです。 「レプリカシャード」は、プライマリシャードのコピーであり、（1）プライマリダイの場合のフェイルオーバーと（2）読み取りスループットの向上を提供します。
セグメント
各シャードには複数の「セグメント」が含まれ、セグメントは逆索引です。シャード内の検索は、各セグメントを順番に検索し、その結果をそのシャードの最終結果に結合します。
ドキュメントのインデックスを作成している間、Elasticsearchはそれらをメモリ（および安全のためにトランザクションログ）に収集し、1秒ごとに新しい小さなセグメントをディスクに書き込み、検索を「更新」します。
これにより、新しいセグメントのデータが検索可能になります（つまり、「検索可能」になります）が、セグメントはディスクにfsyncされていないため、データ損失のリスクがあります。
Elasticsearchは頻繁に「フラッシュ」します。つまり、セグメントをfsyncし（それらは「コミット」されます）、トランザクションログを消去します。これは、新しいデータがディスクに書き込まれたことがわかっているため不要。
セグメントが多いほど、各検索にかかる時間が長くなります。そのため、Elasticsearchは、バックグラウンドマージプロセスを介して、類似サイズ（「ティア」）の多数のセグメントを単一の大きなセグメントにマージします。新しい大きなセグメントが書き込まれると、古いセグメントは削除されます。同じプロセスが多すぎる場合、このプロセスは大きなセグメントで繰り返されます。
セグメントは不変です。ドキュメントが更新されると、実際には古いドキュメントに削除済みのマークが付けられ、新しいドキュメントにインデックスが付けられます。マージプロセスでは、これらの古い削除済みドキュメントも削除されます。