目次
一、エラスティックサーチ
1.1. ElasticSearchとは何ですか?
ElasticSearch は、大量のデータから必要なコンテンツを迅速に見つけるのに役立つ非常に強力な検索エンジンです。
例えば、タオバオでみんなで買い物に行くときに商品情報を入力すると、入力したキーワードに関連する情報がすぐに検索され、例えば「iPhone」というキーワードを入力すると、さまざまな情報が表示されます。 「iPhone 13 特売」「iPhone 10 中古 セール」などで検索すると、「iPhone」というキーワードが赤くなり、ハイライト表示と呼ばれます。 。
1.2. ElasticStackとは何ですか?
実際には、ここには ElasticSearch と一緒に使用されるいくつかのコンポーネント (Kibana、Logstash、Beats) があり、それらの組み合わせが ElasticStack テクノロジー スタックです。
このツール セットは、マイクロサービスのログ データ分析とリアルタイム監視で広く使用されています。
ログ データ分析:プロジェクトの運用中に、大量のログ情報が生成されますが、これは誰にとっても珍しいことではありません。これらのログ情報は、システム内の問題を特定しやすくするために使用されます。システムがエラーを報告し、はオンラインで実行されています。場合によっては、中断してデバッグすることが不可能です。通常、最初に Logstash を通じてログ データを取得し、elasticsearch を通じてデータを保存、計算、検索し、最後に Kibana を使用してデータを視覚化して表示することができます。これにより、ログ解析を行う際に非常に便利です。
リアルタイムモニタリング:プロジェクトが実行されている場合、CPU、メモリの状態、アクセス頻度などの実行状況もデータになります。これらの情報も es によって管理され、視覚化によって表示および処理されます。プロジェクトの実行状況を明確に知ることができます。
しかし実際には、ElasticStack では、Kibana、Logstash、Beats の 3 つのコンポーネントはすべて置き換え可能です。これらは公式に提供されています。必要に応じて使用できます。使用しなくても問題ありません。たとえば、 , タオバオが検索結果を表示するとき、それらはすべて、自分の Web ページを自分で表示する場合、必ずしも Kibana によって生成されたデータ レポートを通じて表示する必要はありません。説明は後ほど）。
1.3. 順方向インデックスと転置インデックス
1.3.1. フォワードインデックス
従来のデータベース (mysql など) は前方インデックスを使用します。
ここにデータベース テーブルがある場合、通常は ID に基づいてインデックスを作成して b+ ツリーを形成します。そうすると、ID に基づいた取得速度が非常に速くなります。この方法は前方インデックスです。しかし、フィールドが検索対象は ID ではありません。これは通常のタイトル フィールド (通常、コンテンツは比較的長い) であるため、インデックスは作成されません。
インデックスを付けたとしても、今検索したいのが正確なタイトル値ではなく、その一部だけだったらどうしますか？select * from table where title like... を求めているわけではありません。このようなあいまい一致が一度使用されると、たとえこのフィールドにインデックスがあっても、それは将来的には有効になりません。最終的には、データベースは 1 バイトを使用することになります。 -各行を1回スキャンして判断する データにタイトルキーワードが含まれているかどうかを判断し、含まれていない場合は破棄し、含まれている場合は結果セットに含める このように、10億個のデータがある場合、1回スキャンすることになります。億回！パフォーマンスは想像できますが、これもフォワードインデックスです。
1.3.2. 転置インデックス
elasticsearch の最下層は逆インデックスを使用しており、ここには 2 つの概念が関係しています。
- ドキュメント:各データはドキュメントです (たとえば、MySQL テーブルのデータ行、たとえば製品テーブルでは、製品がドキュメントであり、ユーザー テーブルのユーザーがデータです)。
- エントリ:ドキュメントは意味論に基づいて単語に分割されます。たとえば、「Huawei mobile Phone」という 4 つの単語は、「Huawei」と「携帯電話」に分割できます。
a) 転置インデックスの作成プロセス:
製品テーブルがあるとします。
1. 製品テーブル内の製品名の転置インデックスを作成する場合、製品名のコンテンツはストレージ用のエントリに分割されます。たとえば、製品名が「Xiaomi mobile Phone」の場合、タイトルは次のようにセグメント化されます。 「Xiaomi」「Mobile」という 2 つの単語を取得して保存します。
2. このとき、たとえば「Xiaomi」を取得して保存すると、その ID もその文書に記録され、「携帯電話」という単語が新しい文書に保存され、その ID が次の場所に記録されます。同じ時間です。
3. 次のデータの製品名を分割して「携帯電話」という用語が得られた場合、そのIDを同じ用語で文書に保存します。
4. 同様に、最終的にデータの整理が完了すると、取得したすべての用語に対してインデックスを作成でき、将来的には用語に基づくクエリ速度が向上します。
b) 転置インデックスのクエリ処理:
1. たとえば、「Huawei 携帯電話」を検索すると、まず単語に分割され、「Huawei」と「携帯電話」という 2 つのエントリが取得されます。
2. 次に、エントリを取得し、転置インデックスでクエリを実行します。インデックスはエントリに基づいて作成されたばかりなので、エントリ「Huawei」に含まれるドキュメント ID をすぐに見つけることができます (ID が 2 、 3 であると仮定します)。 「携帯電話」に含まれるドキュメント ID (ID が 1、2 であると仮定)、これは「Huawei 携帯電話」に含まれるすべてのドキュメント (1、2、3) を知っていることと同等です。
3. id = 2 の商品情報が 2 つの文書に存在します。つまり、id = 2 の商品名の方が検索情報と一致しており、今後はこの一致度に従ってソートされます。
4. この時点で、これらの ID を使用して、前方インデックス内のドキュメントをクエリできます。前方インデックスは ID に基づくインデックスではありませんか? そうすれば、ID を使用してドキュメントをすばやく見つけてクエリを実行できます。データは次のとおりです。ソートされた ID に従って結果セットに入れられます。
c) 分析の概要:
上記のプロセスによれば、検索プロセスが 2 つの取得を経たことがわかります。
- 1 回目は、ユーザーが入力した内容のエントリに基づいて、対応する文書 ID を検索します。
- 2 回目は、ドキュメント ID を持つドキュメントを検索します。
この種のクエリ効率は、前方インデックスで携帯電話のキーワードを含むデータを行ごとに検索するよりもはるかに高速です。
ここで、インデックスが反転されている理由もわかります。順方向インデックスでは 1 行ずつ検索し、一致するものを結果セットに入れる必要がありますが、反転インデックスはその逆で、用語に基づいてインデックスを作成します。検索件数が多い場合には、単語から該当する文書を探します（前方インデックスとは文書から単語を見つけることです）。
1.3.3. 転置インデックスの適用可能なシナリオ
転置インデックスは、ドキュメントの一部をクエリする場合に適しています (たとえば、ブラウザでコンテンツの一部を検索する場合や、製品情報を検索する場合など)。
これが、elasticsearchが逆インデックスに基づいた検索エンジンである理由です~~
