私は Elastic Search (Lucene を基盤としている) を使用してきましたが、これは素晴らしいものです。何を投げても爆速。
なぜ今は速いのか知りたいです。逆インデックスの使用を理解しています。私が見つけたいくつかの記事とそれを説明しているいくつかの優れたYouTubeビデオに基づいていることを部分的に理解していますが、たとえばMysqlやMongoのバイナリツリーよりもはるかに高速なのはなぜですか? 私はそれがややリンゴとオレンジの比較であることを知っていますが、二分木インデックスがどのように機能するかと比較して、逆インデックスがどのように機能するかについての本当に良い説明 (並べて表示など) を見つけることができませんでした。
これまでに収集した唯一のことは、インデックス作成時間に基づいて、逆インデックスはツリーの葉のバランスを取り直す必要がないため、常に高速になるということです (フラクタル インデックスと同じ)。
これはすべてトレードオフに関するものです。
Lucene のインデックスは、B ツリーとは大きく異なり、1 回だけ書き込み可能なセグメントに基づいています。各セグメントには、用語辞書と投稿リストがあります。用語を調べるには、用語辞書の用語に関する情報を読む必要があり、それらは投稿リストの最初にジャンプします。そこでは、この用語に一致するドキュメントのリストを順番に読むことができます。用語辞書のルックアップは、範囲クエリを効率的に実行できるようにするために、二分探索の変形に基づいています。
ドキュメントを追加するたびに、新しいセグメントが作成され (これが、Lucene が一括更新ではるかに優れている理由です)。セグメントの数が構成可能なしきい値 (結合係数と呼ばれます) に達すると、いくつかのセグメントが結合されます ( MergePolicy )。
この設計により、Lucene は多くのクエリを効率的に実行できますが、その一方で、Lucene はアトミックな単一ドキュメントの更新にはまだあまり適していません (コミットごとに新しいセグメントをフラッシュする必要があり、ドキュメント全体のインデックスを再作成する必要があるため)。変更がどれほど大きくても）。個々のフィールドの更新に関連する進行中の作業がありますが、これはまだ実験的なものです。