【Elasticsearch】初识elasticsearch

目次

elasticsearch について知る

1.1. ES を理解する

1.1.1. elasticsearch の役割

1.1.2. ELK テクノロジースタック

1.1.3.elasticsearchとlucene

1.1.4. 他の検索手法を使用しない理由は何ですか?

1.1.5. 概要

1.2. 転置インデックス

1.2.1. フォワードインデックス

1.2.2. 転置インデックス

1.2.3. 前進と後退

1.3.es のいくつかの概念

1.3.1. ドキュメントとフィールド

1.3.2. インデックスとマッピング

1.3.3.mysqlとelasticsearch

elasticsearch について知る

1.1. ES を理解する

1.1.1. elasticsearch の役割

Elasticsearch は、大量のデータから必要なものを素早く見つけるのに役立つ多くの強力な機能を備えた非常に強力なオープンソース検索エンジンです。

例えば:

  • GitHub でコードを検索する

  • ECサイトで商品を探す

  • Baidu で答えを検索する

  • タクシーアプリで近くの車を検索

1.1.2. ELK テクノロジースタック

elasticsearch は、kibana、Logstash、Elastic Stack (ELK) である Beats を組み合わせたものです。ログデータ分析、リアルタイム監視などの分野で広く使用されています。

Elasticsearch はエラスティック スタックの中核であり、データの保存、検索、分析を担当します。

1.1.3.elasticsearchとlucene

elasticsearch の最下層はluceneに基づいて実装されています。

Luceneは、Apache 社の最上位プロジェクトであり、1999 年に Doug Cutting によって開発された Java 言語検索エンジンのクラス ライブラリです。公式 Web サイトのアドレス: Apache Lucene - Apache Lucene へようこそ

elasticsearchの開発履歴:

  • 2004 年、Shay Banon は Lucene に基づいて Compass を開発しました。

  • 2010 年に、Shay Banon は Compass を書き換え、Elasticsearch と名付けました。

1.1.4. 他の検索手法を使用しない理由は何ですか?

現在よく知られている検索エンジン技術ランキング:

初期の頃は、Apache Solr が最も重要な検索エンジン テクノロジでしたが、elasticsearch の開発により、徐々に Solr を上回り、リードするようになりました。

1.1.5. 概要

エラスティックサーチとは何ですか?

  • 検索、ログ統計、分析、システム監視などの機能を実装するために使用できるオープンソースの分散型検索エンジン

エラスティック スタック (ELK) とは何ですか?

  • elasticsearch をコアとするテクノロジー スタック (beats、Logstash、kibana、elasticsearch を含む)

ルシーンとは何ですか?

  • Apache のオープンソース検索エンジン クラス ライブラリであり、検索エンジンのコア API を提供します。

1.2. 転置インデックス

転置インデックスの概念は、MySQL のような順方向インデックスに基づいています。

1.2.1. フォワードインデックス

では、フォワードインデックスとは何でしょうか? たとえば、次のテーブル (tb_goods) に ID のインデックスを作成します。

ID に基づいてクエリを実行すると、インデックスに直接アクセスするため、クエリ速度が非常に速くなります。

ただし、タイトルに基づいてファジー クエリを実行する場合は、データを 1 行ずつスキャンすることしかできません。プロセスは次のとおりです。

1) ユーザーがデータを検索します。条件はタイトルが一致することです。"%手机%"

2) ID 1 のデータなど、データを行ごとに取得します。

3) データ内のタイトルがユーザーの検索条件を満たしているかどうかを判断します

4) 一致する場合は結果セットに追加し、一致しない場合は破棄します。ステップ1に戻る

プログレッシブ スキャン、つまりフル テーブル スキャンでは、データ量が増加するにつれてクエリ効率が低下します。データの量が数百万に達すると、それは大惨事になります。

1.2.2. 転置インデックス

転置インデックスには 2 つの非常に重要な概念があります。

  • ドキュメント(Document):検索に使用するデータであり、各データがドキュメントです。例: Web ページ、製品情報

  • エントリ(Term):文書データやユーザ検索データなどを、一定のアルゴリズムで単語を分割し、意味を持った単語をエントリとします。例: 私は中国人です。これはいくつかのエントリに分けることができます: 私、はい、中国人、中国、中国人

転置インデックスの作成は順方向インデックスの特別な処理であり、そのプロセスは次のとおりです。

  • アルゴリズムを使用して各ドキュメントのデータをセグメント化し、各エントリを取得します

  • テーブルを作成します。データの各行には、エントリ、エントリが存在するドキュメント ID、場所などの情報が含まれます。

  • エントリの一意性により、ハッシュ テーブル構造インデックスなどのエントリのインデックスを作成できます。

図に示すように:

転置インデックスの検索プロセスは次のとおりです (例として「Huawei 携帯電話」の検索を取り上げます)。

1) ユーザーは"华为手机"検索条件を入力します。

2) ユーザーが入力したコンテンツをセグメント化して、エントリを取得します:华为手机

3) エントリを取得し、転置インデックスを検索すると、エントリを含むドキュメント ID 1、2、および 3 を取得できます。

4) ドキュメント ID を取得して、前方インデックス内の特定のドキュメントを検索します。

図に示すように:

最初に転置インデックスをクエリし、次に転置インデックスをクエリする必要がありますが、エントリとドキュメント ID の両方にインデックスが作成されており、クエリ速度は非常に高速です。フルテーブルスキャンは必要ありません。

1.2.3. 前進と後退

では、なぜ一方は順方向インデックスと呼ばれ、もう一方は逆インデックスと呼ばれるのでしょうか?

  • 前方インデックス作成は、ID によるインデックス作成の最も伝統的な方法です。ただし、用語に基づいてクエリを実行する場合は、まず各ドキュメントを 1 つずつ取得し、必要な用語がドキュメントに含まれているかどうかを判断する必要があります。これは、ドキュメントに基づいて用語を検索するプロセスです

  • 転置インデックスはその逆で、まずユーザーが検索したいエントリを見つけ、そのエントリに従ってそのエントリを保護するドキュメントの ID を取得し、その ID に従ってドキュメントを取得します。これは、エントリに基づいてドキュメントを検索するプロセスです。

それはただ逆ですか?

それでは、両方のアプローチの長所と短所は何でしょうか?

前方インデックス:

  • アドバンテージ:

    • 複数のフィールドに対してインデックスを作成できます

    • インデックスフィールドに基づいた検索と並べ替えは非常に高速です

  • 欠点:

    • インデックスのないフィールドまたはインデックス付きフィールドの一部の用語に基づいて検索する場合、フル テーブル スキャンのみを実行できます。

転置インデックス:

  • アドバンテージ:

    • 用語検索やあいまい検索の速度が非常に速い

  • 欠点:

    • インデックスは用語に対してのみ作成でき、フィールドには作成できません

    • フィールドごとに並べ替えることはできません

1.3.es のいくつかの概念

elasticsearch には、mysql とは少し異なる独自の概念が多数ありますが、類似点もあります。

1.3.1. ドキュメントとフィールド

Elasticsearch はドキュメント指向のストレージであり、データベース内の商品データまたは注文情報の一部にすることができます。ドキュメント データは json 形式にシリアル化され、elasticsearch に保存されます。

Json ドキュメントには多くの場合、データベースの列に似た多くのフィールド (フィールド)が含まれます。

1.3.2. インデックスとマッピング

インデックス (Index) は、同じ種類のドキュメントの集合です。

例えば:

  • すべてのユーザー ドキュメントは、ユーザー インデックスと呼ばれる 1 つにまとめて編成できます。

  • すべての商品のドキュメントは、商品インデックスと呼ばれてまとめて編成できます。

  • すべての注文の文書は、注文のインデックスと呼ばれてまとめて整理できます。

したがって、インデックスはデータベース内のテーブルと考えることができます。

データベースのテーブルには、テーブルの構造、フィールドの名前とタイプ、その他の情報を定義するために使用される制約情報があります。したがって、インデックス ライブラリには、テーブルの構造制約と同様に、インデックス内のドキュメントのフィールド制約情報であるマッピングが存在します。

1.3.3.mysqlとelasticsearch

mysql と elasticsearch の概念を統一した方法で比較してみましょう。

MySQL エラスティックサーチ 説明する
テーブル 索引 インデックスは、データベースのテーブルに似たドキュメントのコレクションです。
書類 ドキュメント (Document) はデータベースの行 (Row) と同様のデータであり、ドキュメントは JSON 形式です
カラム 分野 フィールド (Field) は、データベースの列 (Column) に似た、JSON ドキュメント内のフィールドです。
スキーマ マッピング マッピングは、フィールド タイプの制約など、インデックス内のドキュメントに対する制約です。データベースのようなテーブル構造 (スキーマ)
SQL DSL DSL は elasticsearch によって提供される JSON スタイルのリクエスト ステートメントであり、elasticsearch の操作と CRUD の実装に使用されます。

elasticsearchを学んだ後はmysqlはもう必要ないということですか?

実際にはそうではありませんが、どちらにも独自の長所と短所があります。

  • Mysql: トランザクション型の操作が得意で、データのセキュリティと一貫性を確保できます。

  • Elasticsearch: 大量のデータの検索、分析、計算が得意です。

したがって、企業では、この 2 つが組み合わせて使用​​されることがよくあります。

  • 高度なセキュリティ要件が必要な書き込み操作の場合は、mysql を使用して実装します。

  • 高いクエリ パフォーマンスを必要とする検索要件の場合は、elasticsearch を使用して、

  • この 2 つは、データの同期を実現し、一貫性を確保するための特定の方法に基づいています。

おすすめ

転載: blog.csdn.net/weixin_45481821/article/details/131624356