は、私は（最初から小さな検索エンジンを書きでいくつかの経験を共有するために、この質問を使用しますノー検索固有ライブラリが使用されていました）（実際には、単一サーバ上で動作するには小さすぎたり大きすぎたりしないので、stackoverflowを検索します。 Check it out。以下は私の調査結果です。
クローラ
まず、クローラが行うには厳しいものです。実際の問題は、Webページを取得するのと同じくらい速くディスクにデータを書き込むことです。主なデータ構造は逆インデックスであるため、 "banana"という単語を取得すると、 "バナナ"インデックス（文書の位置とともに文書のリスト）を新しいレコードに追加する必要がありますそれを書き戻します。リストが大きくなるにつれて、それを引っ張ったり書き込んだりするのが遅くなります。つまり、逆インデックス（およびドキュメント）をパーティションに分割することです（たとえば、最初のパーティションの1-1000ドキュメントなど）。もう1つの「トリック」は、パーティションをクロールしてインデックスをメモリに保持し、パーティションが完了したときにのみディスクにフラッシュします。
重要ビット：どのようなデータを格納するために使用するには？多くのオプションがあり、多くの実験の結果、今日の時点でleveldbが最良の選択であることが分かりました。そして、SSDディスクを忘れないでください！
ので、すべてのすべては、一台のマシン（4 GBのRAM）を使用して、このように（〜13 000 000ページ）のstackoverflowのほとんどをクロールして約2ヶ月かかります。結果のデータ（逆索引、生の文字列など） - 約80 GBのディスク容量。
検索
目標は、それは、高速かつ高品質で行うことです。実現しなければならないことの1つは、高速にしたい場合は、データセット全体を検索することができないということです。幸いなことに、すべてのパーティションを分割して、キーワードが表示されている最初の100個のパーティション（別のインデックス）を検索し、「十分に良い」結果が見つかると停止します。
最も遅い部分は、ディスクからインデックスを読んで、それをdeserialisingています。Leveldbは高速シーケンシャル読み取りをサポートしているため、データの大半がシーケンシャルに読み取られるようにデータを保存する必要があります。一度メモリに設定されている交差点はかなり速いです。
今、品質。それは最も厳しいものであり、決して十分ではありません。私の最初の試みは、テキストだけでなく、タイトル、リンクテキスト、およびURLの逆インデックスを維持することでした。これらの中でヒットするたびに、ドキュメントにいくつかの点が追加されます。もう1つは、シノニムを使用してクエリを言い換えて、どのクエリが最もうまく機能したかを確認することです。それはおそらく自分自身のポストに値するだろう。
とにかく、私は読書に役立つことを願っています！
出典
2015-09-02 20:56:28
ren
ありがとうございました！私はこれを一度見たが、どこにいたのか忘れてしまった。 – davemackey