database - 逆索引の格納

Question

逆索引付けが単語を索引付けするための良い方法であることは知っていますが、検索エンジンが実際にそれらをどのように保管するかについて混乱していますか? たとえば、「google」という単語がドキュメントに表示されている場合、頻度の異なる 2、4、6、8 の場合、それらをどこに保存する必要がありますか? 1対多の関係を持つデータベーステーブルは、それらを保存するのに役立ちますか?

Answer 1

主要な検索エンジンのそれぞれが、逆索引を処理するための独自のテクノロジーを持っていることは間違いありません。また、標準のリレーショナル データベース テクノロジに基づいていないことも、適度に良い賭けです。

Google の特定のケースでは、現在使用されているテクノロジは、2006 年に Fay Chang 氏らがBigtable: A Distributed Storage System for Structured Dataで説明したBigTableテクノロジから派生したものであると推測できます。しかし、システムがその後進化したことは間違いありません。

Answer 2

従来、転置インデックスはファイルに直接書き込まれ、ディスクのどこかに保存されていました。ブール検索クエリを実行したい場合 (ファイルにクエリ内のすべての単語が含まれているかどうかに関係なく)、投稿はファイルに連続して保存されているように見える場合があります。

Term_ID_1:Frequency_N:Doc_ID_1,Doc_ID_2,Doc_ID_N.Term_ID_2:Frequency_N:Doc_ID_1,Doc_ID_2,Doc_ID_N.Term_ID_N:Frequency_N:Doc_ID_1,Doc_ID_2,Doc_ID_N

用語 ID は用語の ID であり、頻度は用語が表示されるドキュメントの数 (つまり、投稿リストの長さ) であり、ドキュメント ID は用語を含むドキュメントです。

インデックスに加えて、すべてがファイルのどこにあるかを知る必要があるため、マッピングも別のファイルのどこかに保存する必要があります。たとえば、term_id を指定すると、マップはそのインデックスを含むファイルの位置を返す必要があり、その位置にシークすることができます。frequency_id は投稿に記録されるため、ファイルから読み取る doc_id の数がわかります。さらに、ID から実際の用語/ドキュメント名へのマッピングが必要になります。

ユース ケースが小さい場合は、投稿リストに BLOB を使用し、クエリを実行するときに交差を自分で処理することにより、SQL でこれを実現できる場合があります。

非常に小規模なユース ケースのもう 1 つの戦略は、用語ドキュメント マトリックスを使用することです。