独自の検索エンジンを構築する

I.はじめに

私は検索エンジンとの接触が非常に多いのですが、これまでに何をしてきたかを簡単に思い出してみましょう。以前の仕事には資料がなく、多くのことがほとんど忘れられています。残念です。

1. 10 年以上前、Dongqi Software がコーポレート Web サイトを構築していたときに Lucene で遊んだことがありますが、当時は中国語の単語の分割がまだ非常に弱く、多くの単語が検索できませんでした。 「中国銀行に送られ、その後、私のテクノロジーが銀行で使用されました。人々はそれを軽蔑していますが、銀行の技術部門の人々は銀行の情報システムを構築できますが、彼らは C または Dephi を使用しており、JSP を知らず、それはできません」ウェブサイトをまったく構築していません（笑）。

2. 私はアリババの 3 セットの検索エンジンを使用しました。淘宝網の教育と VSearch のドッキングを行い、機密情報の淘宝網メイン検索とのドッキングを行いました。さらに、淘宝網の最終検索チームに技術情報の共有を依頼しました。私たちのチームとアーキテクチャを構築しました。VSearch と最終検索は両方とも Lucene と Solr に基づいています。それは構築され、完全なデータと増分データのインポートをサポートするフレームワークを提供するためにいくつかの拡張機能が作成されました。Vsearch は当時、淘宝網の垂直市場戦略に役立ちました。メイン検索のドッキング期間が非常に長く、多くの個別ニーズに対応できなかったこと、および最終検索が別のチームによって開発された競合製品であったため、最終検索は文字通りすべての検索を統合することを意味し、当時、2 つのグループは争っていました。非常にハードで、その後メインの検索は C 言語に基づいて開発されました。初期のアーキテクチャは Yahoo、Yitao、および Taobao リスト ページの検索 (この印象では Hasper システムと呼ばれます) はすべてメインの検索エンジンによって構築されています。

3. Niubang で株式ソフトウェアに取り組んでいたとき、新しい株式データのクエリは ElasticSearch によって提供されていました。私は、いくつかの Web サイト上の新しい株式データをクロールするための Python クローラーを作成し、それを ElasticSearch にインポートする責任がありました。リーダーは構築を担当しましたElasticSearch とサービス インターフェイスの提供。

4. 会社が牛乳事業をしていた頃、主に配送注文変更ログのクエリを解決するために同僚にESの構築を依頼したことがありましたが、一向に業務が改善せず、構築完了後も切り替えは行われませんでした。

5. カーテンシステムは、日次在庫価値レポートのスナップショット、リアルタイムの在庫レポートのエクスポート、さまざまなレポートなど、実際に遭遇するいくつかの問題を解決するために ES を構築していますが、現在は完全にデータベースに依存しており、突然の負荷は依然として比較的高く、リアルタイム データ クエリのエクスポート要件の一部は、データベースを使用して満たすことが困難です。

二、MySQL VS ElasticSearch

ES を使用する一般的なアプローチは、MySQL に保存されているデータのコピーを ES に同期し、ES を使用して大量のデータに対してリアルタイム クエリを実行することですが、あいまい検索の解決は小さな機能にすぎません。

1. リレーショナル データベースは構造化されたビジネス データを格納し、ビジネス プロセスを満たすように設計されています。設計がクエリを満たすことを重視しすぎると、全体の構造が混乱し、冗長性が高くなります。ES はクエリを解決するように設計されています。複数のテーブル データ1 つのスキーマ (またはタイプ) にマージでき、パフォーマンスを消費する多くのマルチテーブル関連のクエリを解決できます。

2. MySQL はダーティ データが生成されないようにトランザクション機能を使用しますが、ES はトランザクションをサポートしていないため、通常、MySQL は元のデータを保存するために使用されます。

3. MySQL は大量のデータ クエリを実行するためにデータベースとテーブルを分割する必要がありますが、最終的にはクエリは特定のデータベースの特定のテーブルに分類され、ES は自然な分散アーキテクチャです。データはシャードに保存され、1 つのシャードに保存されます。ノードはクエリに使用されます。A がリクエストを受信すると、リクエストをそのデータ ノードに転送します。他のデータ ノードはローカルにクエリを実行し、結果 ID をノード A に返します。その後、ノード A はすべての結果を並べ替えてページングし、次に進みます。各データノードに送信し、IDに基づいて元のデータを確認し、ユーザーに返します。

4. 単一部分のクエリであっても、ES Lucene の転置インデックスは MySQL の B+TREE よりも高速です。

3. 転置インデックス

ES は、分散型マルチユーザー全文検索エンジンを提供する Lucene に基づく検索サービスですが、Lucene は単なる全文検索エンジン ツールキットです。

1. 転置インデックスとは何ですか?

転置インデックスは全文検索の概念です 転置インデックスがあるからには必ず順方向インデックスが必要です 順方向インデックス、転置インデックスに関係なく、全文検索の概念です MySQLデータベース InnodbはB+TREEですインデックス。これは、順方向インデックスと逆インデックスとは関係がありません。

前方インデックス: 全文を検索して単語を見つけることにより、全文前方インデックスが作成されます。

文書 -> Word 1、Word 2

単語 1 の出現数、単語 1 が出現する位置、単語 2 の出現数、単語 2 が出現する位置。

転置インデックス: 単語から全文を検索します。これは全文転置インデックスです。

Word 1 ---> 文書 1、文書 2、文書 3

Word 2 ---> 文書 1、文書 2

2. 転置インデックスの生成例

記事 1 の内容: qingcai は杭州に住んでいます、私も杭州に住んでいます。

記事 2 の内容: 彼はかつて上饒に住んでいました。

step1: キーワードを取得する

英語の単語は比較的単純で、スペースで直接分割できますが、中国語の単語は、in、too などの意味のない単語をフィルタリングし、句読点をフィルタリングして、大文字と小文字を統一するセグメンタが必要です。 liveとlivedをliveにチェックすることで分離できるように、livedは一緒にチェックアウトします。

第 1 条のキーワード: [青菜][ライブ][杭州][i][ライブ][杭州]

第2条 キーワード：[彼][生きる][シャンラオ]

step2: 転置インデックスを作成する

キーワードは文字順に並べられており、二分検索アルゴリズムを使用してキーワードをすばやく検索できます。

Lucene は上記 3 つの列を次の 3 つのファイルとして保存します。

• 辞書ファイル（用語辞書）

• 周波数ファイル (周波数)

• 位置ファイル

用語辞書は他の 2 つのファイルへのポインターも保存し、最後に Lucene によってインデックスが圧縮されます。

3. インデックスクエリ

「live」という単語がクエリされると、Lucene は辞書ファイル (用語辞書) に対して二分検索を実行し、ポインタを介してすべての記事番号を読み出し、最後に結果データを返します。辞書ファイルは一般に非常に小さいため、クエリプロセス全体が非常に高速かつ効率的です。