[解決済み] リフレッシュとフラッシュ

質問

Elasticsearchのインデックスに新しい文書が登録されると、インデックス操作の1秒後には検索が可能になります。しかし、このドキュメントをすぐに検索可能にするために、強制的に _flush または _refresh という操作をインデックスに対して行います。これらの 2 つの操作の違いは何ですか - 結果はどちらも同じで、ドキュメントはすぐに検索可能になるようです。

これらの操作のそれぞれは、具体的に何をするのでしょうか？

ESのドキュメントでは、この問題に深く取り組んでいないようです。

どのように解決するのですか?

回答は正しいのですが、もう少し詳しく説明する価値があると思います。

リフレッシュは効果的に lucene インデックスリーダの再オープンを呼び出し、検索可能なデータのポイントインタイムスナップショットが更新されるようにします。この lucene の機能は、lucene near real-time api の一部です。

この機能は elasticsearch refresh はドキュメントを検索可能にしますが、fsync を呼び出さないため、ディスクに書き込まれたドキュメントが永続化されることはありません。データの耐久性を保証するのは lucene commit であり、これははるかに高価です。

lucene reopenは1秒ごとに呼び出すことができますが、lucene commitで同じことはできません。

lucene を通して、かなり頻繁に reopen を呼び出すことによって、ほぼリアルタイムで新しいドキュメントを検索できるようになりますが、データがディスクに書き込まれ、fsynced され、したがって安全になるように、まだ commit を呼び出す必要があります。

Elasticsearchはシャード（事実上Luceneインデックス）ごとにトランザクションログを追加し、まだコミットされていない書き込み操作を保存することでこのquot;問題"を解決しています。トランザクションログは同期され、安全であるため、まだコミットされていない文書に対しても、任意の時点で耐久性を確保することができます。1秒ごとに自動的に更新されるため、ほぼリアルタイムで文書を検索することができます。また、万が一の場合でも、トランザクションログを再生することで、最終的に失われた文書を復元することができます。トランザクションログの良いところは、内部で他のことに使えることです。例えば、リアルタイムで idで取得 .

ある elasticsearch flush は効果的に lucene のコミットを引き起こし、トランザクションログも空にします。なぜなら、いったんデータが lucene レベルでコミットされると、lucene 自身によって耐久性が保証されるからです。フラッシュは api として公開されており、微調整を行うことができます。フラッシュは、トランザクションログに追加された操作の数、その大きさ、そして最後にフラッシュが行われた時間に応じて自動的に行われます。