目次
最近社内で Elasticsearch を共有したので、この記事は主に要約を目的としており、この記事が読者に Elasticsearch の機能、その使用法、および基本原理を一般的に理解してもらえることを願っています。
1. 生活の中のデータ
検索エンジンはデータを取得するので、生活の中のデータから始めましょう。私たちの生活の中のデータは、一般に 2 つのタイプに分類されます。
-
構造化データ
-
非構造化データ
構造化データ: 行データとも呼ばれ、2 次元のテーブル構造によって論理的に表現および実現されるデータであり、データ形式と長さの仕様に厳密に従っており、主にリレーショナル データベースによって格納および管理されます。データベース、メタデータなど、固定形式または制限された長さのデータを指します。
非構造化データ: フルテキスト データとも呼ばれ、可変長または固定フォーマットがなく、オフィス文書、XML、HTML、Word 文書、電子メール、さまざまなレポート、画像などのすべてのフォーマットを含む、2 次元データベース テーブルによる表現には適していません。音声や映像の情報など。
説明: より注意深く区別したい場合は、XML と HTML を半構造化データに分けることができます。独自のタグ形式もあるため、必要に応じて構造化データとして処理することも、プレーン テキストから抽出して非構造化データとして処理することもできます。
2 つのデータ分類に従って、検索も次の 2 つのタイプに分類されます。
-
構造化データ検索
-
非構造化データの検索
構造化データの場合、特定の構造を持っているため、一般にリレーショナル データベース (MySQL、Oracle など) の 2 次元テーブル (Table) に格納および検索でき、インデックスを構築することもできます。
非構造化データの場合、フルテキスト データを検索するには主に 2 つの方法があります。
-
シーケンシャルスキャン
-
全文検索
順次スキャン: テキスト名を通じてその一般的な検索方法、つまり、順次スキャン方式で特定のキーワードをクエリすることもできます。
たとえば、新聞を渡された場合、その新聞のどこに「平安」という言葉が載っているかを調べてみましょう。必ず新聞を最初から最後まで目を通して、そのキーワードがどのセクションのどこに登場するかをマークする必要があります。
この方法は間違いなく最も時間がかかり、最も効率的ではありませんが、新聞の植字フォントが小さく、セクションが多く、場合によっては複数の新聞がある場合は、目を流し読みするだけでほぼ十分です。
全文検索: 非構造化データの順次スキャンは遅いのですが、最適化できますか? 非構造化データに特定の構造を持たせる方法を見つけるだけで十分ではないでしょうか?
非構造化データ内の情報の一部を抽出し、特定の構造を持つように再編成してから、特定の構造を持つデータを検索することで、比較的高速な検索の目的を達成します。
このアプローチは、全文検索の基本的な考え方を構成します。非構造化データから抽出され、再編成された情報のこの部分は、インデックスと呼ばれます。
この方法の主な作業負荷は初期段階でのインデックスの作成ですが、後の検索では高速かつ効率的です。
2、最初に Lucene について話します
世の中のデータの種類を簡単に理解すると、リレーショナル データベースの SQL 検索ではこの種の非構造化データを処理できないことがわかります。
この種の非構造化データの処理は全文検索に依存する必要があり、現在市場で最も優れたオープンソースの全文検索エンジン ツールキットは Apache の Lucene に属しています。
ただし、Lucene は単なるツールキットであり、完全な全文検索エンジンではありません。Lucene の目的は、ターゲット システムでの全文検索機能を容易にするための使いやすいツールキットをソフトウェア開発者に提供すること、またはこれに基づいて完全な全文検索エンジンを構築することです。
現在、オープンソースで利用可能な Lucene ベースの全文検索エンジンは、主に Solr と Elasticsearch です。
Solr と Elasticsearch はどちらも比較的成熟した全文検索エンジンであり、機能や性能は基本的に同じです。
ただし、ES自体は配布が容易で導入・利用が容易であるという特徴があるのに対し、Solrの配布はZooKeeperを利用して分散調整管理を実現するなどサードパーティによる実現が必要です。
Solr と Elasticsearch はどちらも最下層で Lucene に依存しており、Lucene が全文検索を実現できるのは主に転置インデックスのクエリ構造を実装しているためです。
転置インデックスを理解するにはどうすればよいですか? 既存のデータ ファイルが 3 つある場合、ファイルの内容は次のとおりです。
-
Java は最高のプログラミング言語です。
-
PHP は最高のプログラミング言語です。
-
JavaScript は最高のプログラミング言語です。
転置インデックスを作成するには、トークナイザーを使用して各ドキュメントのコンテンツ ドメインを個別の単語 (用語または用語と呼びます) に分割し、すべての一意の用語の並べ替えられたリストを作成して、その用語がどの文書に出現するかをそれぞれリストします。
結果は次のようになります。
Term Doc_1 Doc_2 Doc_3
-------------------------------------
Java | X | |
is | X | X | X
the | X | X | X
best | X | X | X
programming | x | X | X
language | X | X | X
PHP | | X |
Javascript | | | X
-------------------------------------
この構造は、文書内のすべての一意の単語のリストで構成されており、各単語にはそれに関連付けられた文書のリストがあります。
この属性値によってレコードの位置を決める構造が転置インデックスです。転置インデックスを持つファイルは転置ファイルと呼ばれます。
次の図に示すように、上記の内容をグラフの形式に変換して、転置インデックスの構造情報を示します。
理解する必要がある主に次の中心的な用語があります。
-
用語: インデックス内の最小のストレージおよびクエリ単位。英語の場合は単語、中国語の場合は通常、単語分割後の単語を指します。
-
辞書 (用語辞書): 辞書、用語のエントリのコレクションです。検索エンジンの通常のインデックス単位は単語であり、単語辞書はドキュメント コレクションに出現したすべての単語で構成される文字列コレクションです。単語辞書の各インデックス項目には、単語自体に関する情報と、単語へのポインタが記録されます。 「投稿リスト」。
-
投稿リスト: 通常、文書は複数の単語で構成され、投稿リストには、その単語がどの文書内でどこに出現したかが記録されます。各レコードは「投稿」と呼ばれます。転置リストには文書番号が記録されるだけでなく、単語の出現頻度やその他の情報も記録されます。
-
転置ファイル: すべての単語の転置リストは、多くの場合、ディスク上の特定のファイルに順次に格納されます。このファイルは転置ファイルと呼ばれ、転置ファイルは転置インデックスを格納する物理ファイルです。
上の図から、転置インデックスは主に 2 つの部分で構成されていることがわかります。
-
辞書
-
反転ファイル
辞書と投稿リストは Lucene の 2 つの非常に重要なデータ構造であり、高速な検索の重要な基盤です。辞書と反転ファイルは 2 つの部分に分けて保存され、辞書はメモリに保存され、反転ファイルはディスクに保存されます。
3. ES のコアコンセプト
いくつかの基本的な知識の基礎を築いた後、今日の主役である Elasticsearch の紹介に正式に入ります。
ES は Java で書かれたオープン ソースの検索エンジンです。内部のインデックス作成と検索に Lucene を使用します。Lucene をカプセル化することで、Lucene の複雑さを隠し、代わりにシンプルで一貫性のある RESTful API を提供します。
ただし、Elasticsearch は Lucene を超えており、単なる全文検索エンジンではありません。
それは次のように正確に説明できます。
-
· 分散型リアルタイム文書ストレージ。各フィールドにインデックスを付けて検索できます。
-
· 分散型リアルタイム分析検索エンジン。
-
·数百のサービス ノードの拡張を処理でき、PB レベルの構造化データまたは非構造化データをサポートします。
公式 Web サイトの Elasticsearch の紹介は次のとおりです: Elasticsearch は、分散型でスケーラブルな、ほぼリアルタイムの検索およびデータ分析エンジンです。
Elasticsearch が分散型でスケーラブルなほぼリアルタイムの検索を、いくつかの核となる概念を通じてどのように実現するかを見てみましょう。
集まる
ES のクラスタ構成は非常にシンプルで、サードパーティの調整および管理コンポーネントに依存する必要がなく、クラスタ管理機能は内部で実現されます。
ES クラスターは 1 つ以上の Elasticsearch ノードで構成されます。各ノードは、同じクラスター名を設定することでクラスターに参加できます。デフォルト値は「elasticsearch」です。
異なる環境では必ず異なるクラスター名を使用してください。そうしないと、ノードが間違ったクラスターに参加することになります。
Elasticsearch サービスの起動インスタンスはノード (Node) です。ノードは、node.name を介してノード名を設定します。設定されていない場合は、ランダムな普遍的に一意識別子が起動時に名前としてノードに割り当てられます。
① 発見の仕組み
次に、ES が同じ設定cluster.name を使用して異なるノードを同じクラスターに接続するにはどうすればよいかという疑問があります。答えは禅の発見です。
Zen Discovery は、Elasticsearch の組み込みのデフォルト検出モジュールです (検出モジュールの役割は、クラスター内のノードを検出し、マスター ノードを選択することです)。
ユニキャストおよびファイルベースの検出を提供し、プラグインを介してクラウド環境や他の形式の検出をサポートするように拡張できます。
Zen Discovery は他のモジュールと統合されており、たとえば、ノード間のすべての通信は Transport モジュールを使用して行われます。ノードは検出メカニズムを使用して、Ping によって他のノードを見つけます。
Elasticsearch は、ノードが誤ってクラスターに参加することを防ぐために、ユニキャスト検出を使用するようにデフォルトで設定されています。同じマシン上で実行されているノードのみが自動的にクラスターを形成します。
クラスターのノードが別のマシンで実行されている場合は、ユニキャストを使用して、接続を試行するノードのリストを Elasticsearch に提供できます。
ノードがユニキャスト リストのメンバーに接続すると、クラスター全体のすべてのノードのステータスを取得し、マスター ノードに接続してクラスターに参加します。
これは、ユニキャスト リストにはクラスター内のすべてのノードを含める必要はなく、新しいノードがそのうちの 1 つに接続して通信できるのに十分なノードだけが必要であることを意味します。
マスター候補ノードをユニキャスト リストとして使用する場合、リストする必要があるのは 3 つだけです。この設定は elasticsearch.yml ファイルにあります。
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
ノードが起動したら、最初に ping を実行し、 discovery.zen.ping.unicast.hosts 設定がある場合は設定内のホストに ping を実行し、設定がない場合はローカルホストのいくつかのポートに ping を実行してみます。
Elasticsearch は、同じホストで複数のノードを起動することをサポートしており、Ping 応答には、ノードとノードが考慮するマスター ノードの基本情報が含まれます。
選出の開始時に、各ノードが考慮するマスターから選択します。ルールは非常に単純で、ID の辞書順に従ってソートし、最初のものを取得します。各ノードに認識されたマスターがない場合は、すべてのノードから選択します。ルールは上記と同じです。
discovery.zen.minimum_master_nodes ここには、ノード数が最小制限に達しない場合、ノード数が選挙を開始するのに十分になるまで上記のプロセスが繰り返されるという制限があります 。
最終的な選出の結果、マスターは確実に選出され、ローカル ノードが 1 つしかない場合は、それ自体が選出されます。
現在のノードが Master の場合、ノード数が に達するまで待機を開始し discovery.zen.minimum_master_nodes、サービスを提供します。
現在のノードがマスターではない場合は、マスターへの参加を試みます。Elasticsearch では、上記のサービス検出とマスター選択のプロセスを Zen Discovery と呼びます。
任意の数のクラスター (1 ～ N) をサポートするため、Zookeeper のようにノードの数を奇数に制限することはできません。また、マスターを選出するために投票メカニズムを使用することはできませんが、ルールを使用します。
すべてのノードが同じルールに従っている限り、取得される情報は同等であり、選択されたマスター ノードは一貫している必要があります。
しかし、分散システムの問題点は情報の不平等な状況にあり、このときスプリットブレイン（Split-Brain）の問題が現れやすい。
ほとんどのソリューションでは、クォーラム値を設定します。これには、外部サービスを提供するために、使用可能なノードがクォーラムより大きい (通常はノードの半分以上) 必要があります。
Elasticsearch では、このクォーラム構成は です discovery.zen.minimum_master_nodes 。
②ノードの役割
各ノードは候補マスター ノードまたはデータ ノードのいずれかになります。これらは構成ファイル ../config/elasticsearch.yml で設定できます (デフォルトでは true)。
node.master: true //是否候选主节点
node.data: true //是否数据节点
データ ノードは、データのストレージと、データの追加、削除、変更、クエリ、集計などの関連操作を担当します。そのため、データ ノード (データ ノード) には、マシン構成の要件と、CPU、メモリ、およびデータの要件が比較的高くなります。 I/Oを大量に消費します。
通常、クラスターが拡大するにつれて、パフォーマンスと可用性を向上させるために、より多くのデータ ノードを追加する必要があります。
マスター ノード候補はマスター ノード (マスター ノード) として選出できます。クラスタ内のマスター ノード候補のみが投票および選出される権利を持ち、他のノードは選挙に参加しません。
マスター ノードは、インデックスの作成、インデックスの削除、クラスターの一部であるノードの追跡、関連するノードにどのシャードを割り当てるかの決定、クラスター内のノードのステータスの追跡などを行います。安定したマスター ノードは、安定したマスター ノードが非常に重要です。クラスターの健全性。
ノードはマスター ノード候補またはデータ ノードのいずれかになりますが、データ ノードは大量の CPU およびメモリ コア I/O を消費します。したがって、ノードがデータ ノードとマスター ノードの両方である場合、マスター ノードに影響を与え、ひいてはクラスター全体の状態に影響を与える可能性があります。
したがって、クラスターの健全性を改善するには、Elasticsearch クラスター内のノードの役割を分割して分離する必要があります。低構成のいくつかのマシン ファームをマスター ノード ファームの候補として使用できます。
マスター ノードと他のノードは Ping を通じて相互にチェックし、マスター ノードは他のすべてのノードに Ping を送信して、ハングアップしたノードがあるかどうかを判断する責任があります。他のノードも Ping を通じてマスターノードが利用可能かどうかを判断します。
ノードの役割は区別されますが、ユーザーのリクエストはどのノードにも送信でき、マスターノードが転送することなく、ノードはリクエストの配布、結果の収集などを担当します。
この種のノードをコーディネーター ノードと呼ぶことができます。コーディネーター ノードを指定して構成する必要はなく、クラスター内の任意のノードがコーディネーター ノードとして機能できます。
③スプリットブレイン現象
同時に、ネットワークなどの理由でクラスター内で複数のマスター ノードが選択され、データ更新に不整合が生じる場合、この現象はスプリット ブレインと呼ばれます。つまり、クラスター内の異なるノードがマスター ノードの選択に同意しません。マスター、および複数の A マスター コンテスト。
「スプリット ブレイン」問題は、次のようないくつかの理由で発生する可能性があります。
-
ネットワークの問題: クラスター間のネットワーク遅延により、一部のノードがマスターへのアクセスに失敗します。マスターがダウンしていると考えられ、新しいマスターが選出され、マスター上のシャードとレプリカが赤でマークされ、新しいマスター シャードが表示されます。割り当てられました。
-
ノード負荷： マスターノードの役割はMasterとDataの両方であり、大量のアクセスがあった場合、ESが応答停止（擬似死亡状態）し、広範囲の遅延が発生する場合があります。他のノードはマスター ノードから応答を取得できず、マスター ノードがハングアップしたと判断し、プライマリ ノードが再選択されます。
-
メモリ回復: マスター ノードの役割はマスターとデータの両方です。データ ノード上の ES プロセスが大量のメモリを占有すると、JVM の大規模なメモリ回復が発生し、ES プロセスの応答が失われます。 。
スプリット ブレイン現象を回避するには、理由から始めて、次の側面から最適化対策を講じることができます。
-
応答時間を適切に長くし、誤判断を軽減します。 Discovery.zen.ping_timeout パラメーターを使用してノード ステータスの応答時間を設定します。デフォルトは 3 秒で、適切に調整できます。
マスターが応答時間範囲内に応答しない場合、ノードはハングアップしたと判断されます。パラメータ（6s、 などdiscovery.zen.ping_timeout:6）を大きくすると、誤判定が適切に軽減されます。
-
選挙のトリガー。 候補クラスター内のノードの構成ファイルにパラメーターの値を設定する必要があります
discovery.zen.minimum_master_nodes。
このパラメータは、マスター ノードの選出時に選挙に参加する必要があるマスター ノード候補の数を示します。デフォルト値は 1 で、公式推奨値は ( です。ここで、 はマスター ノード候補の数master_eligibel_nodes)+1です master_eligibel_nodes 。
これにより、スプリット ブレイン現象の発生を防ぐことができるだけでなく、少なくとも 2 つの discovery.zen.minimum_master_nodes 候補ノードが生き残っている限り、選出は正常に続行できるため、クラスターの高可用性を最大限に高めることができます。この値より小さい場合、選出動作はトリガーされず、クラスターは使用できず、断片化の混乱は発生しません。
-
役割分担。 つまり、前述したマスターノード候補とデータノードの役割分離により、マスターノードの負担が軽減され、マスターノードの誤死を防ぎ、マスターノードが「死んだ」という誤った判断を減らすことができます。
断片化 (シャード)
ES は PB レベルの全文検索をサポートしています。インデックス上のデータ量が大きすぎる場合、ES はインデックス上のデータを分割し、水平分割を通じて異なるデータ ブロックに分散します。分割されたデータベース ブロックはスライスとして呼び出されます。
これは MySQL のサブデータベースとサブテーブルに似ていますが、MySQL のサブデータベースとサブテーブルはサードパーティのコンポーネントに依存する必要があり、ES はこの機能を内部的に実装する点が異なります。
マルチシャード インデックスにデータを書き込む場合、書き込まれる特定のシャードはルーティングによって決定されるため、インデックスの作成時にシャードの数を指定する必要があり、シャードの数が決定されると変更できません。
以下に説明するシャードの数とコピーの数は、インデックス作成時に設定で設定できます。デフォルトでは、ES はインデックスに対して 5 つのプライマリ シャードを作成し、各シャードにコピーを作成します。
PUT /myIndex
{
"settings" : {
"number_of_shards" : 5,
"number_of_replicas" : 1
}
}
ES は、インデックスのスケールとパフォーマンスを向上させるためにシャーディングの機能を使用します。各シャードは Lucene のインデックス ファイルであり、各シャードにはプライマリ シャードとゼロから複数のコピーが必要です。
レプリカ
レプリカはシャードのコピーです。各プライマリ シャードには 1 つ以上のレプリカ シャードがあります。プライマリ シャードが異常な場合、レプリカはデータ クエリやその他の操作を提供できます。
プライマリ シャードと対応するレプリカ シャードは同じノード上に存在しないため、レプリカ シャードの最大数は N-1 になります (N はノードの数です)。
ドキュメントの作成、インデックス作成、削除リクエストはすべて書き込み操作であり、関連するレプリカ シャードにレプリケートされる前にプライマリ シャードで完了する必要があります。
ESの書き込み能力を向上させるため、この処理を並行して書き込みますが、同時に書き込みの際のデータ競合の問題を解決するために、ESは楽観的ロックによる制御を行っています。各ドキュメントには（バージョン）が付いています。文書が _version 変更されると、バージョン番号が増加します。
すべてのレプリカ シャードが成功を報告すると、コーディネーター ノードに成功を報告し、コーディネーター ノードはクライアントに成功を報告します。
上の図から、高可用性を実現するために、マスター ノードはプライマリ フラグメントとレプリカ フラグメントを同じノードに配置することを回避していることがわかります。
この時点でノード Node1 サービスがダウンしているかネットワークが利用できないとすると、プライマリ ノード上のプライマリ シャード S0 も利用できなくなります。
幸いなことに、他に 2 つの正常に動作するノードがあり、この時点で ES は新しいマスター ノードを再選択し、必要な S0 のデータはすべてこれら 2 つのノード上に存在します。
S0 のコピー シャードをプライマリ シャードに昇格させます。プライマリ シャードを昇格させるこのプロセスは瞬時に行われます。この時点で、クラスターのステータスは黄色になります。
クラスターのステータスが緑色ではなく黄色なのはなぜですか? 2 つのプライマリ シャードがすべてありますが、各プライマリ シャードは 2 つのレプリカ シャードに対応する必要があることも設定されており、現時点ではレプリカ シャードが 1 つだけ存在します。したがって、クラスターは Green 状態になることはできません。
Node2 もシャットダウンしても、Node3 がシャードごとにコピーを保持しているため、プログラムはデータを失うことなく実行を続けることができます。
Node1 を再起動すると、クラスターは不足しているレプリカ フラグメントを再配布でき、クラスターの状態は元の通常の状態に戻ります。
Node1 に以前のシャードがまだある場合は、それらを再利用しようとしますが、現時点では Node1 のシャードはプライマリ シャードではなくレプリカ シャードになっているため、変更されたデータ ファイルをシャードにコピーするだけです。
まとめ：
-
データのシャーディングは、処理できるデータの容量を増やして水平方向の拡張を容易にするためのものであり、シャードのコピーを作成することは、クラスターの安定性を向上させ、同時実行の量を増やすためです。
-
コピーは増殖するもので、消費すればするほど安全性が高まります。シャーディングとは分割のことであり、シャードが増えれば増えるほど、単一シャード データの分散が少なくなります。
-
コピーが多いほどクラスターの可用性は高くなりますが、各シャードは Lucene インデックス ファイルに相当するため、一定量のファイル ハンドル、メモリ、CPU を占有します。さらに、シャード間のデータ同期にも一定量のネットワーク帯域幅が占有されるため、シャードとインデックスのコピーの数はできるだけ多くなりません。
マッピング
マッピングは、ドキュメントが持つ可能性のあるフィールドまたは属性とデータ型を記述するデータベースのスキーマと同様に、ストレージの種類、単語の分割方法、ES によるインデックス内のフィールドの保存の有無などの情報を定義するために使用されます。各分野の。
リレーショナル データベースでテーブルを作成するときにフィールド タイプを指定する必要があるだけですが、ES ではフィールド タイプを指定して動的にフィールド タイプを推測したり、インデックスを作成するときにフィールド タイプを指定したりすることはできません。
データ形式に応じてフィールドの型を自動的に認識するマッピングを動的マッピング(Dynamic Mapping)と呼び、インデックス作成時にフィールドの型を具体的に定義するマッピングを静的マッピングまたは明示的マッピング(Explicit Mapping)と呼びます。
動的マッピングと静的マッピングの使用を説明する前に、まず ES のデータにはどのようなフィールド タイプがあるかを理解しましょう。後で、インデックスを作成するときに動的マッピングではなく静的マッピングを確立する必要がある理由について説明します。
ES (v6.8) のフィールド データ タイプには主に次のカテゴリが含まれます。
テキスト 電子メールの本文や製品説明などの全文値のインデックスを作成するためのフィールド。これらのフィールドはトークン化され、インデックス付けされる前に文字列を個々の用語のリストに変換するためにトークナイザーに渡されます。
解析プロセスにより、Elasticsearch は 1 つの単語内のすべての完全なテキスト フィールドを検索できます。テキスト フィールドは並べ替えには使用されず、集計にもほとんど使用されません。
キーワード 電子メール アドレス、ホスト名、ステータス コード、郵便番号、ラベルなどの構造化コンテンツのインデックスを作成するためのフィールド。これらは通常、フィルタリング、並べ替え、集計に使用されます。キーワード フィールドは、正確な値でのみ検索できます。
フィールド タイプを理解すると、一部のフィールドを明確に定義する必要があることがわかります。たとえば、フィールドがテキスト タイプであるかキーワード タイプであるかは大きく異なります。時間フィールドには時間形式を指定する必要があるかもしれません。トークナイザーなど、いくつかのフィールドに特定のフィールドを指定します。
これを動的マッピングで正確に行うことができない場合、自動認識は期待したものと多少異なることがよくあります。したがって、インデックスを作成するときは、次のようにシャードとレプリカの数、およびマッピングの定義を指定する完全な形式にする必要があります。
PUT my_index
{
"settings" : {
"number_of_shards" : 5,
"number_of_replicas" : 1
}
"mappings": {
"_doc": {
"properties": {
"title": { "type": "text" },
"name": { "type": "text" },
"age": { "type": "integer" },
"created": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis"
}
}
}
}
}
第四に、ESの基本的な使い方
Elasticsearch の使用を決定する際に最初に考慮すべきことは、バージョンの問題です。Elasticsearch (0.x と 1.x を除く) には現在、一般的に使用される安定したメジャー バージョン 2.x、5.x、6.x、7 があります。 x (現在)。
3.x と 4.x はなく、ES は 2.4.6 から 5.0.0 に直接ジャンプしたことがわかるかもしれません。実際、これはユーザーの混乱を避けるために、ELK (ElasticSearch、Logstash、Kibana) テクノロジー スタックのバージョンを統一するためのものです。
Elasticsearch が 2.x (2.x の最後のバージョン 2.4.6 は 2017 年 7 月 25 日にリリースされました) の場合、Kibana はすでに 4.x (Kibana 4.6.5 は 2017 年 7 月 25 日にリリースされました) です。
次に、Kibana の次のメジャー バージョンは 5.x でなければならないため、Elasticsearch はメイン バージョンを 5.0.0 として直接リリースしました。
統合後はバージョン選択に迷うことがなくなり、Elasticsearchのバージョンを選択した後、同じバージョンのKibanaを選択できるため、バージョンの非互換性を気にする必要がなくなりました。
Elasticsearch は Java を使用して構築されているため、Elasticsearch のバージョンを選択する際には、ELK テクノロジーの統合バージョンに注意を払うことに加えて、JDK のバージョンにも注意する必要があります。
各メジャー バージョンは異なる JDK バージョンに依存しているため、現在のバージョン 7.2 はすでに JDK11 をサポートしています。
インストールと使用
①Elasticsearchをダウンロードして解凍します。インストールは必要ありません。解凍後に使用できます。解凍後のディレクトリは上記のようになります。
-
bin: 起動コマンドやプラグインのインストールコマンドなどを含むバイナリシステムコマンドディレクトリ。 -
config: 設定ファイルのディレクトリ。 -
data：データ保存ディレクトリ。 -
lib: 依存関係パッケージのディレクトリ。 -
logs: ログファイルのディレクトリ。 -
modules: モジュール ライブラリ (x-pack のモジュールなど)。 -
plugins: プラグインのディレクトリ。
②インストールディレクトリで 実行しbin/elasticsearch てESを起動します。
③ デフォルトでは、ポート 9200 で実行されます。curl http://localhost:9200/ をリクエストするか、ブラウザに http://localhost:9200 と入力して、現在のノード、クラスター、および現在のノード、クラスター、およびクラスターなどの情報を含む JSON オブジェクトを取得します。バージョン。
{
"name" : "U7fp3O9",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "-Rj8jGQvRIelGd9ckicUOA",
"version" : {
"number" : "6.8.1",
"build_flavor" : "default",
"build_type" : "zip",
"build_hash" : "1fad4e1",
"build_date" : "2019-06-18T13:16:52.517138Z",
"build_snapshot" : false,
"lucene_version" : "7.7.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
クラスターの健全性ステータス
クラスターの健全性を確認するには、Kibana コンソールでコマンド GET /_cluster/health を実行し、次の情報を取得します。
{
"cluster_name" : "wujiajian",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 9,
"active_shards" : 9,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 64.28571428571429
}
クラスターのステータスは、緑、黄、赤で示されます。
-
緑: クラスターは正常で、すべてが完全に機能し、すべてのシャードとレプリカが適切に動作しています。
-
黄色: 警告ステータス。すべてのプライマリ シャードは正常に機能していますが、少なくとも 1 つのレプリカが正常に動作していません。この時点でクラスターは機能しますが、高可用性がある程度損なわれます。
-
赤：クラスタが正常に使用できません。1 つまたは一部のシャードとそのレプリカが異常に利用できません。現時点では、クラスターのクエリ操作は引き続き実行できますが、返される結果は不正確になります。このシャードに割り当てられた書き込みリクエストはエラーを報告し、最終的にはデータ損失につながります。
クラスターのステータスが赤の場合、クラスターは使用可能なシャードからの検索リクエストを処理し続けますが、割り当てられていないシャードをできるだけ早く修正する必要があります。
5. ES機構の原理
ES の基本概念と基本操作を紹介した後でも、まだ多くの疑問が残るかもしれません。
-
内部ではどのように機能しているのでしょうか?
-
プライマリ シャードとレプリカ シャードはどのように同期されますか?
-
インデックスを作成するプロセスは何ですか?
-
ES はインデックス データを異なるシャードにどのように割り当てますか? そして、これらのインデックスデータはどのように保存されるのでしょうか?
-
ES はほぼリアルタイムの検索エンジンであり、ドキュメントの CRUD (作成、読み取り、更新、削除) 操作がリアルタイムであると言われるのはなぜですか?
-
そして、Elasticsearch は、電源がオフのときにデータを失わずに更新が永続化されることをどのように保証するのでしょうか?
-
また、ドキュメントを削除してもすぐにスペースが解放されないのはなぜですか?
これらの質問を踏まえて、次のコンテンツに進みます。
インデックス書き込みの原則
次の図は、4 つのプライマリ シャード (S0、S1、S2、S3) と 8 つのレプリカ シャード (R0、R1、R2、R3) を含む合計 12 のシャードを持つ 3 つのノードのクラスターを示しています。各プライマリ シャードはそれぞれに対応します。 2 つのレプリカ シャードがあり、ノード 1 はクラスター全体のステータスを担当するプライマリ ノード (マスター ノード) です。
インデックスの書き込みはプライマリ シャードにのみ書き込め、その後レプリカ シャードに同期されます。ここには 4 つのプライマリ シャードがあります。データ ES はどのようなルールに従って特定のシャードに書き込まれますか?
このインデックス データは S0 に書き込まれ、S1 または S2 には書き込まれないのはなぜですか? そのデータが S0 ではなく S3 に書き込まれるのはなぜですか?
まず第一に、これは決してランダムではありません。そうしないと、将来文書を入手したいときにどこを探せばよいのかわかりません。
実際、このプロセスは次の式に従って決定されます。
shard = hash(routing) % number_of_primary_shards
ルーティングは変数値であり、デフォルトで文書化されており _id 、カスタム値に設定することもできます。
ルーティングはハッシュ関数を通じて数値を生成し、この数値を number_of_primary_shards (プライマリ シャードの数) で割って余りを求めます。
0 と number_of_primary_shards-1 の間の残りの部分は、探しているドキュメントが存在するシャードの場所です。
これは、インデックスの作成時にプライマリ シャードの数を決定し、この数を決して変更しない必要がある理由を説明しています。数が変更されると、以前のすべてのルーティング値が無効になり、ドキュメントが二度と見つからなくなるからです。
ES クラスター内の各ノードは、上記の計算式を通じてクラスター内のドキュメントの保存場所を知っているため、各ノードは読み取りおよび書き込みリクエストを処理する能力を持ちます。
書き込みリクエストがノードに送信されると、そのノードは前述の調整ノードとなり、ルーティング式に従ってどのシャードに書き込むかを計算し、ノード上のシャードのメイン シャードにリクエストを転送します。 。
このとき、データの余りをルーティング計算式でとった値が だったとします shard=hash(routing)%4=0。
具体的なプロセスは次のとおりです。
-
クライアントが ES1 ノード (調整ノード) に書き込みリクエストを送信し、ルーティング計算式を通じて得られた値が 0 である場合、現在のデータはプライマリ シャード S0 に書き込まれる必要があります。
-
ES1 ノードは、S0 のプライマリ フラグメントが存在するノード ES3 にリクエストを転送し、ES3 はリクエストを受け入れてディスクに書き込みます。
-
データを 2 つのレプリカ シャード R0 に同時にレプリケートします。データの競合はオプティミスティック同時実行によって制御されます。すべてのレプリカ フラグメントが成功を報告すると、ノード ES3 はコーディネーター ノードに成功を報告し、コーディネーター ノードはクライアントに成功を報告します。
保管原理
上記はESの内部インデックスの書き込み処理プロセスです。この処理はESのメモリ上で実行され、データは特定のシャードとコピーに割り当てられた後、最終的にディスクに保存されます。データが失われることはありません。
特定の保存パスは ../config/elasticsearch.yml 構成ファイルで設定でき、デフォルトではインストール ディレクトリの Data フォルダーに保存されます。
ES をアップグレードするとすべてのデータが失われる可能性があるため、デフォルト値を使用しないことをお勧めします。
path.data: /path/to/data //索引数据
path.logs: /path/to/logs //日志记录
①分割保管
インデックス ドキュメントはセグメントの形式でディスクに保存されます。セグメントとは何ですか? インデックス ファイルは複数のサブファイルに分割されており、各サブファイルはセグメントと呼ばれます。各セグメントは転置インデックスそのものであり、セグメントは不変です。インデックス データがハードディスクに書き込まれると、変更することはできません。
最下層にセグメントストレージモードを採用することで、読み書き時のロックの発生をほぼ完全に回避し、読み書きのパフォーマンスを大幅に向上させます。
セグメントがディスクに書き込まれた後、コミット ポイントが生成されます。コミット ポイントは、コミット後のすべてのセグメント情報を記録するために使用されるファイルです。
セグメントにコミット ポイントが設定されると、セグメントには読み取り権限のみが付与され、書き込み権限が失われます。逆に、セグメントがメモリ内にある場合、セグメントには書き込み権限のみがあり、データの読み取り権限はありません。つまり、データを取得することはできません。
セグメントの概念が提案されている主な理由は次のとおりです。 初期の全文検索では、文書コレクション全体に対して大規模な逆索引が確立され、ディスクに書き込まれていました。
インデックスが更新された場合は、完全なインデックスを再作成して、元のインデックスを置き換える必要があります。この方法は、データ量が多い場合には非常に非効率であり、インデックスの作成コストが非常に高いため、データを頻繁に更新できず、適時性が保証されません。
インデックス ファイルはセグメントに保存され、変更できません。追加、更新、削除にはどのように対処すればよいでしょうか?
-
データが新しいため、追加の処理は簡単です。現在のドキュメントに新しいセグメントを追加するだけで済みます。
-
削除。変更できないため、削除操作では、ドキュメントは古いセグメントから削除されませんが、新しい .del ファイルが追加され、これらの削除されたドキュメントのセグメント情報がファイルにリストされます。削除対象としてマークされたドキュメントはクエリで引き続き照合できますが、最終結果が返される前に結果セットから削除されます。
-
更新では、古いセグメントを変更してドキュメントの更新を反映することはできません。実際、更新は削除と追加の 2 つのアクションに相当します。古いドキュメントは .del ファイル内で削除対象としてマークされ、ドキュメントの新しいバージョンは新しいセグメントにインデックス付けされます。両方のバージョンのドキュメントが 1 つのクエリで一致する可能性がありますが、削除された古いバージョンのドキュメントは結果セットが返される前に削除されます。
このセクションは変更不可として設定されているため、利点と欠点がいくつかあります。利点は主に次の点に現れます。
-
ロックは必要ありません。インデックスを更新しない場合は、複数のプロセスが同時にデータを変更することを心配する必要はありません。
-
インデックスがカーネルのファイルシステム キャッシュに読み込まれると、その不変性によりインデックスはそこに残ります。ファイル システム キャッシュに十分なスペースがある限り、ほとんどの読み取りリクエストはディスクにアクセスせずにメモリに直接送信されます。これにより、パフォーマンスが大幅に向上します。
-
他のキャッシュ (フィルター キャッシュなど) は、インデックスの存続期間中常に有効です。データは変更されないため、データが変更されるたびに再構築する必要はありません。
-
単一の大きな逆インデックスに書き込むと、データが圧縮され、ディスク I/O とメモリにキャッシュする必要があるインデックスの使用量が削減されます。
セグメントの不変性の欠点は次のとおりです。
-
古いデータを削除する場合、古いデータはすぐには削除されませんが、.del ファイル内で削除済みとしてマークされます。古いデータはセグメントが更新された場合にのみ削除できるため、大量のスペースの無駄が発生します。
-
頻繁に更新されるデータがあり、更新のたびに古いデータをマークするために新しいデータが追加される場合、多くの無駄なスペースが発生します。
-
新しいデータが追加されるたびに、データを保存するために新しいセグメントが必要になります。セグメント数が多すぎると、ファイルハンドルなどのサーバーリソースの消費が非常に大きくなります。
-
すべての結果セットをクエリ結果に含めると、削除対象としてマークされた古いデータを除外する必要があり、クエリの負担が増加します。
② 遅延書き込み戦略
ストレージの形式を導入した後、インデックスをディスクに書き込むプロセスはどのようなものですか? Fsync を直接呼び出して物理的にディスクに書き込みますか?
答えは明らかで、ディスクに直接書き込むと、ディスクの I/O 消費量がパフォーマンスに重大な影響を及ぼします。
その後、大量のデータを書き込むと、ES が一時停止してフリーズし、クエリが迅速に応答できなくなります。この場合、ES は準リアルタイム全文検索エンジンとは言えなくなります。
書き込みパフォーマンスを向上させるために、ES は新しいデータが追加されるたびにディスクにセグメントを追加するのではなく、遅延書き込み戦略を採用しています。
新しいデータがあると、そのデータはまずメモリに書き込まれ、メモリとディスクの間にファイル システム キャッシュが存在します。
デフォルト時間（1秒）に達するか、メモリ内のデータが一定量に達すると、リフレッシュ（Refresh）がトリガーされ、メモリ内のデータが新しいセグメントに生成され、ファイル キャッシュ システムにキャッシュされます。 . はディスクにフラッシュされ、コミット ポイントが生成されます。
ここでのメモリは ES の JVM メモリを使用しますが、ファイル キャッシュ システムはオペレーティング システムのメモリを使用します。
新しいデータはメモリに書き込まれ続けますが、メモリ内のデータはセグメント形式で保存されていないため、検索機能は提供できません。
メモリがファイル キャッシュ システムにフラッシュされると、新しいセグメントが生成され、そのセグメントはディスクへのフラッシュを待たずに検索用に開かれます。
Elasticsearch では、新しいセグメントを書き込んで開く軽量のプロセスはリフレッシュと呼ばれます (つまり、メモリがファイル キャッシュ システムにフラッシュされます)。
デフォルトでは、各シャードは 1 秒ごとに自動的に更新されます。これが、Elasticsearch がリアルタイム検索に近いと言われる理由です。ドキュメントへの変更はすぐには検索に表示されませんが、1 秒以内に表示されるからです。
また、手動でリフレッシュをトリガーしたり、POST /_refresh すべてのインデックスをリフレッシュしたり、POST /nba/_refresh 指定したインデックスをリフレッシュしたりすることもできます。
ヒント: 更新は送信よりもはるかに軽い操作ですが、それでもパフォーマンスのオーバーヘッドが発生します。手動更新はテストを作成する場合には便利ですが、運用環境でドキュメントのインデックスが作成されるたびに手動で更新しないでください。また、すべてのケースを毎秒更新する必要があるわけではありません。
Elasticsearch を使用して多数のログ ファイルのインデックスを作成しており、ほぼリアルタイムの検索ではなくインデックス作成速度を最適化したい場合もあります。
このとき、インデックスを作成するときに [設定] の refresh_interval = "30s" 値を増やすことで、各インデックスの更新頻度を減らすことができます。値を設定するときは、その背後にある時間単位に注意する必要があります。それ以外の場合、デフォルトはミリ秒です。このとき、 refresh_interval=-1 インデックスの自動更新をオフにすることになります。
遅延書き込み戦略は、データがディスクに書き込まれる回数を減らし、全体的な書き込み能力を向上させることができますが、ファイル キャッシュ システムはオペレーティング システムのメモリに属するメモリ空間でもあることがわかっています。メモリの電源がオフになっている場合、またはデータが失われる異常なリスクがある場合。
データ損失を避けるために、Elasticsearch はトランザクション ログ (Translog) を追加します。これは、まだディスクに保存されていないすべてのデータを記録します。
トランザクション ログを追加した後、インデックスを書き込むプロセス全体が上の図に示されています。
-
新しいドキュメントのインデックスが作成されると、まずメモリに書き込まれますが、データの損失を防ぐために、データのコピーがトランザクション ログに追加されます。
新しいドキュメントは常にメモリに書き込まれ、トランザクション ログにも記録されます。この時点では、新しいデータを取得したりクエリしたりすることはまだできません。
-
デフォルトのリフレッシュ時間に達するか、メモリ内のデータが一定量に達すると、リフレッシュがトリガーされ、メモリ内のデータが新しいセグメントの形式でファイル キャッシュ システムにリフレッシュされ、メモリがクリアされます。現時点では、新しいセグメントはディスクに送信されていませんが、ドキュメントの検索機能を提供でき、変更することはできません。
-
新しいドキュメント インデックスが継続的に書き込まれるため、ログ データ サイズが 512M を超えるか、時間が 30 分を超えると、フラッシュがトリガーされます。
メモリ内のデータは新しいセグメントに書き込まれると同時にファイル キャッシュ システムに書き込まれ、ファイル システム キャッシュ内のデータは Fsync を通じてディスクにフラッシュされ、コミット ポイントが生成され、ログ ファイルが削除され、空の新しいログが作成されます。
このように、電源がオフになっている場合、または再起動する必要がある場合、ES はコミット ポイントに従って永続化されたセグメントをロードする必要があるだけでなく、永続化されていないデータをディスクに再永続化するためにツール Translog 内のレコードも必要になります。データ損失の可能性を回避します。
③セグメントマージ
自動更新プロセスでは 1 秒ごとに新しいセグメントが作成されるため、短期間にセグメント数が急増する可能性があります。また、セグメントの数が多すぎると、より大きな問題が発生します。
各セグメントはファイル ハンドル、メモリ、CPU サイクルを消費します。さらに、各検索リクエストは各セグメントを順番に調べてクエリ結果を結合する必要があるため、セグメントが多いほど検索は遅くなります。
Elasticsearch は、バックグラウンドで定期的にセグメントのマージを実行することで、この問題を解決します。小さなセグメントは大きなセグメントにマージされ、さらに大きなセグメントがさらに大きなセグメントにマージされます。
これらの古い削除されたドキュメントは、セグメントがマージされるときにファイル システムから消去されます。削除されたドキュメントは、新しい大きなセクションにはコピーされません。インデックス作成と検索はマージ中に中断されません。
セグメントのマージは、インデックス作成および検索中に自動的に行われます。マージ プロセスでは、同様のサイズのセグメントの小さなセットが選択され、バックグラウンドでそれらがより大きなセグメントにマージされます。セグメントは、コミットされていない場合とコミットされていない場合があります。
マージが完了すると、古いセグメントが削除され、新しいセグメントがディスクにフラッシュされ、新しいセグメントを含み、古いセグメントと小さいセグメントを除外する新しいコミット ポイントが書き込まれ、新しいセグメントが開きます。検索用に。
セグメントのマージは膨大な量の計算を必要とし、大量のディスク I/O を消費します。セグメントのマージにより書き込み速度が低下し、チェックを外したままにすると検索パフォーマンスに影響します。
Elasticsearch はデフォルトでマージ プロセスをリソース制限しているため、検索を適切に実行するのに十分なリソースがまだあります。
6、ESパフォーマンスの最適化
ストレージデバイス
最近のサーバーではディスクがボトルネックになることがよくあります。Elasticsearch はディスクを大量に使用するため、ディスクが処理できるスループットが高くなるほど、ノードの安定性が高まります。
ディスク I/O を最適化するためのヒントをいくつか紹介します。
-
SSDを使用します。他の場所で述べたように、それらは機械式ディスクよりもはるかに優れています。
-
RAID0を使用します。ストライピング RAID では、ディスク I/O が増加しますが、1 台のハード ドライブに障害が発生すると、当然のことながら障害が発生します。ミラーリングやパリティ、RAID はレプリカがすでに提供しているため、使用しないでください。
-
あるいは、複数のハードドライブを使用し、Elasticsearch が複数の path.data ディレクトリ構成を介してハードドライブ全体にデータをストライプ化できるようにします。
-
NFS や SMB/CIFS など、リモートにマウントされたストレージは使用しないでください。この遅延が発生すると、パフォーマンスに完全に逆効果になります。
-
EC2 を使用している場合は、EBS に注意してください。SSD ベースの EBS であっても、通常はローカル インスタンス ストレージよりも低速です。
内部インデックスの最適化
用語をすばやく見つけるために、Elasticsearch は最初にすべての用語を並べ替えてから、二分法に従って用語を検索します。時間計算量は logN であり、辞書を検索するのと同じです。これが用語辞書です。
今見ると、従来のデータベースが B-Tree を使用する方法と似ているように思えます。ただし、用語が多すぎる場合、用語辞書は非常に大きくなり、メモリに保存するのは非現実的であるため、用語インデックスが用意されています。
どの用語が A で始まり、どのページにあるのかを示す辞書の索引ページと同じように、用語索引はツリーであることがわかります。
このツリーにはすべての用語が含まれているわけではなく、用語のいくつかのプレフィックスが含まれています。用語インデックスを使用すると、用語辞書内の特定のオフセットをすばやく見つけ、その位置から順番に検索できます。
FST を使用してメモリ内の用語インデックスを圧縮し、FST はすべての用語をバイト単位で保存します。この圧縮方法では、ストレージ領域を効果的に削減でき、用語インデックスをメモリ内に十分に収めることができますが、この方法ではより多くの CPU リソースも必要になります。
ディスクに保存される投稿リストについては、ストレージの占有容量を削減するために圧縮技術も使用されます。
構成パラメータを調整する
構成パラメータを調整するための提案は次のとおりです。
-
各ドキュメントに、適切に圧縮されたシーケンス パターンを使用して順序付けされた ID を割り当てます。圧縮率が低く、Lucene の速度が大幅に低下する UUID-4 のようなランダム ID は避けてください。
-
集計と並べ替えを必要としないインデックス フィールドの Doc 値を無効にします。Doc Values は、
document=>field valueに基づくマッピングの順序付きリストです。 -
ファジー検索を必要としないフィールドの場合は、インデックス作成前のテキストの単語分割を避けるために、テキスト タイプの代わりにキーワード タイプを使用します。
-
検索結果にほぼリアルタイムの精度が必要ない場合は、
index.refresh_intervalインデックスあたり 30 秒に変更することを検討してください。一括インポートを実行している場合は、この値を -1 に設定することでインポート中の更新をオフにすることができます。また、
index.number_of_replicas: 0この値を設定することでコピーをオフにすることもできます。完了したら、忘れずにオンに戻してください。 -
深いページング クエリを回避するには、ページング クエリに Scroll を使用することをお勧めします。通常のページネーション クエリでは、
from+size空の優先キューが作成され、各フラグメントはfrom+sizeデータの一部を返します。このデータには、デフォルトではドキュメント ID と調整ノードへのスコアのみが含まれます。N 個のフラグメントがある場合、調整ノードは (from + size) × n 個のデータに対して 2 次ソートを実行し、取得する必要があるドキュメントを選択します。from が大きいと、ソート処理が非常に重くなり、CPU リソースを著しく占有します。
-
マッピング フィールドを減らして、取得、集計、または並べ替えが必要なフィールドのみを提供します。他のフィールドは Hbase などの他のストレージ デバイスに保存でき、ES で結果を取得した後、Hbase に移動してこれらのフィールドをクエリします。
-
インデックスとクエリを作成するときにルーティング値を指定すると、特定のシャードを正確にクエリでき、クエリ効率が向上します。ルーティングの選択では、データのバランスのとれた分散に注意を払う必要があります。
JVMのチューニング
JVM チューニングの推奨事項は次のとおりです。
-
プログラムが実行時にヒープ メモリ サイズを変更しないように、ヒープ メモリの最小サイズ ( Xms ) と最大サイズ ( Xmx ) が同じであることを確認してください。インストール後に Elasticsearch によって設定されるヒープ メモリは、デフォルトで 1GB です。ファイルを通じて
../config/jvm.option構成できますが、物理メモリの 50% と 32GB を超えないようにすることが最善です。 -
GC はデフォルトで CMS 方式を採用しており、同時実行ですが STW の問題があるため、G1 コレクターの使用を検討できます。
-
ES はファイル システム キャッシュ (ファイルシステム キャッシュ)、高速検索に大きく依存しています。一般に、使用可能なメモリの少なくとも半分がファイル システム キャッシュに物理的に割り当てられていることを確認する必要があります。