私はElasticsearchの各シャードがインデックスであると仮定していました。しかし、私はどこかで、各セグメントがLuceneインデックスであることを読みました。
セグメントとは正確には何ですか？検索パフォーマンスにどのように影響しますか？デフォルトのElasticsearch設定で、毎日約450GBのサイズに達するインデックスがあります（毎日新しいインデックスを作成します）。
を実行する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 つのシャードで構成することもできますが、通常、インデックスを拡張して複数のマシンに分割できるように、複数のシャードで構成されます。
「プライマリ シャード」は、ドキュメントのメイン ホームです。「レプリカ シャード」は、(1) プライマリが停止した場合のフェイルオーバーと (2) 読み取りスループットの向上を提供するプライマリ シャードのコピーです。
各シャードには複数の「セグメント」が含まれており、セグメントは逆インデックスです。シャード内の検索では、各セグメントが順番に検索され、その結果がそのシャードの最終結果に結合されます。
ドキュメントのインデックスを作成している間、Elasticsearch はドキュメントをメモリ (および安全のためにトランザクション ログ) に収集し、約 1 秒ごとに新しい小さなセグメントをディスクに書き込み、検索を「更新」します。
これにより、新しいセグメントのデータが検索できるようになります (つまり、"検索可能" になります) が、セグメントはディスクに fsync されていないため、依然としてデータ損失のリスクがあります。
ときどき、Elasticsearch は「フラッシュ」します。これは、セグメントを fsync し (現在は「コミット」されています)、トランザクション ログをクリアすることを意味します。これは、新しいデータがディスクに書き込まれていることがわかっているため、不要になりました。 .
セグメントが多いほど、各検索にかかる時間が長くなります。そのため、Elasticsearch は、バックグラウンド マージ プロセスを通じて、同様のサイズ (「層」) の多数のセグメントを 1 つのより大きなセグメントにマージします。新しい大きなセグメントが書き込まれると、古いセグメントは削除されます。同じサイズのセグメントが多すぎる場合、このプロセスがより大きなセグメントで繰り返されます。
セグメントは不変です。ドキュメントが更新されると、実際には古いドキュメントが削除済みとしてマークされ、新しいドキュメントがインデックスに登録されます。マージ プロセスでは、これらの古い削除済みドキュメントも消去されます。