私は検索エンジン(仮想プロジェクト)を書いています。 パート1.2。 内部のレンガ

上から下へ、および下から上への2つの設計方法が知られています。 自転車を再び発明しようとしていますが、途中から3番目の方法を試みています。

私は現在、検索の「部分的派生」、つまり特定のサイト(単一のユニットにグループ化されたサイトのグループ)の検索により興味があるので、この方向に進みます。



実際の検索に加えて、インデックスを更新する問題もあります。 たとえば、同僚は検索エンジン<a href stemwww.sphinxsearch.com»>Sphinxを使用してセットアップしました。 彼らが遭遇した問題の1つは、メインインデックスを迅速に更新できないことでした。これはメディアサイトでは受け入れられません。

これらは、いくつかのインデックスの検索を使用してねじれていました(Sphinxはこれを許可しています)。 日中に別の記事を投稿すると、当日のインデックスが再構築されました。 そのようなインデックスの週の間に、7が蓄積され、サーバーの負荷が低下した週末に、蓄積されたインデックスを考慮してメインインデックスが再構築されました。 そして円で。 このインデックスの剛性は、検索プロセスを高速化するために作成されました。 すべてを支払う必要があります。

Sphinx開発者はすでにこの問題を解決している(または解決している)と聞きました。 インデックスを組み合わせて、ソースデータに応じた再生成を回避できるようになりました。 このように、彼はあなたが踏むことができるレーキ(そのうちの1つ)を(多くの人に感謝します)見せました。 開発を待っている技術的な熊手に関するこのような情報は、検索理論に関するすべての原稿よりも価値があります。 結局のところ、理論を実践に移そうとすると、最大の困難が始まります。

ふう! たくさんの言葉。 しかし、ここにいなければ、コメントの中で、私が決定した理由を説明する必要があります。

ベースインデックスを3つの並列インデックスに分割します。

メインインデックス-それがメインです。

この日のインデックス-当日のすべての更新。

真夜中以降、「今日」は「昨日」になり、新しい日の余地ができます。

日中は、メインインデックスと「昨日の」が結合され、その後、昨日のものが削除され、メインはユニオンの結果に置き換えられます。

したがって、インデックスの関連性を維持するコストは最小限に抑えられます。

通常の検索エンジンモードで作業するとき(サイトがスキャンするキューとしてデータが更新されるとき)、昨日のインデックスは不要であり、今日のレシートに基づいて今日のインデックスが生成されます。



PS。 Googleはすでに、サイト上のコンテンツの更新を即座にインデックス化する技術PubSubHubbubに取り組んでいます。 次の更新バッチを受信すると、インデックス全体が再構築されるとは思いません。おそらく、メインのインデックスと並行して利用可能な何らかの種類のバッファインデックスにニュースが蓄積されるでしょう。 検索エンジンは、ニュース検索で同じような技術を長い間実行していた可能性があります。 次に、すべてのコンテンツにそれらを配布します。



All Articles