0

次のように、MySQL データベースに位置レコードが格納されている転置インデックスを考えてみましょう。

  Word (VARCHAR)  |    Documents (LONGTEXT)
-------------------------------------------------------------
     Hello        | {id: 11, freq: 4, pos: [18, 37, 43, 119]}, 
                  | {id: 19, freq: 2, pos: [17, 32]}
-------------------------------------------------------------

ここで、新しい文書が作成され、その単語のほとんどが既に索引付けされています。今のインデックス操作はどうあるべきですか? 基本的なアプローチは、単語がデータベースに既に存在する場合、そのドキュメントを取得し、現在のドキュメントをそれに追加してレコードを更新するようです。

ドキュメントの数が数百万に達するまで増加しても、これは持続可能でしょうか? Solr、Xapain、Google、Bing などの実際の検索エンジンは、これをどのように処理しますか?

4

1 に答える 1

0

コレクションに新しいドキュメントが追加されると、操作は次のようになります。

  1. ドキュメントを一意に識別する ID、たとえば 20 をドキュメントに割り当てます。通常、この ID は、コレクションに新しいドキュメントが追加されるたびに 1 ずつ増加します。

  2. 新しいドキュメント内のすべての単語のリストを作成し、それらがどの位置に出現するかを調べます。

    ドキュメントHi Hello Hello Byeの場合、これは次のようになります。

    さようなら: {id: 20, freq: 1, pos: [15]}
こんにちは: {id: 20, freq: 2, pos: [3, 9]}
こんにちは: {ID: 20、頻度: 1、位置: [0]}

  3. 新しい単語 (Bye、Hi) については、その単語のエントリをデータベースに追加します。データベース内の既存の単語 (Hello) については、新しいデータをその値に追加します。

    以下は、ドキュメントを追加した後のデータベースの外観です。

    Word (VARCHAR)  |    Documents (LONGTEXT)
    -------------------------------------------------------------
       Bye          | {id: 20, freq: 1, pos: [15]}
       Hello        | {id: 11, freq: 4, pos: [18, 37, 43, 119]}, 
                    | {id: 19, freq: 2, pos: [17, 32]}
                    | {id: 20, freq: 2, pos: [3, 9]}
       Hi           | {id: 20, freq: 1, pos: [0]}
    -------------------------------------------------------------

あなたの他の質問に対する簡単な答えは次のとおりです。はい、これは大きなインデックスでも持続可能です。逆インデックスは通常、ハッシュ テーブルまたはバイナリ ツリーを使用してルックアップ用に最適化されているため、ドキュメント コレクションのサイズに実質的に依存しない検索が行われます。

大規模な検索エンジンがこれをどのように処理するかについて: 詳細についてはわかりません (知りたいのですが)。彼らは明らかにデータ クラスターを使用して複数のサーバーに負荷を分散します (はい、負荷を分散すると言いましたが、意図的なものではありませんでした)。彼らはたくさんのものを前処理し、「スタックオーバーフロー」のような一般的なクエリをキャッシュしたので、そのためのソリューションページがすでにあるに違いありません.

于 2013-05-20T22:14:40.430 に答える