Elasticsearch-quick-guide
Elasticsearch-基本概念
Elasticsearchは、Apache Luceneベースの検索サーバーです。 Shay Banonによって開発され、2010年に公開されました。 現在、Elasticsearch BVによって管理されています。 最新バージョンは7.0.0です。
Elasticsearchは、リアルタイムで分散されたオープンソースの全文検索および分析エンジンです。 RESTful Webサービスインターフェイスからアクセスでき、スキーマを含まないJSON（JavaScript Object Notation）ドキュメントを使用してデータを保存します。 Javaプログラミング言語で構築されているため、Elasticsearchはさまざまなプラットフォームで実行できます。 これにより、ユーザーは非常に大量のデータを非常に高速に探索できます。
一般的な機能
Elasticsearchの一般的な機能は次のとおりです-
- Elasticsearchは、最大数ペタバイトの構造化および非構造化データまで拡張可能です。
- Elasticsearchは、MongoDBやRavenDBなどのドキュメントストアの代替として使用できます。
- Elasticsearchは、非正規化を使用して検索パフォーマンスを改善します。
- Elasticsearchは人気のあるエンタープライズ検索エンジンの1つであり、現在、Wikipedia、The Guardian、StackOverflow、GitHubなどの多くの大きな組織で使用されています。
- Elasticsearchはオープンソースであり、Apacheライセンスバージョン2.0で利用できます。
キーコンセプト
Elasticsearchの重要な概念は次のとおりです-
Node
Elasticsearchの単一の実行中のインスタンスを指します。 単一の物理サーバーと仮想サーバーは、RAM、ストレージ、処理能力などの物理リソースの機能に応じて、複数のノードに対応します。
クラスタ
これは、1つ以上のノードのコレクションです。 クラスターは、データ全体のすべてのノードにわたる集合的なインデックス作成および検索機能を提供します。
索引
これは、さまざまな種類のドキュメントとそのプロパティのコレクションです。 インデックスは、パフォーマンスを向上させるためにシャードの概念も使用します。 たとえば、一連のドキュメントには、ソーシャルネットワーキングアプリケーションのデータが含まれています。
資料
これは、JSON形式で定義された特定の方法でのフィールドのコレクションです。 すべてのドキュメントはタイプに属し、インデックス内に存在します。 すべてのドキュメントは、UIDと呼ばれる一意の識別子に関連付けられています。
シャード
インデックスは水平方向に断片に細分化されます。 つまり、各シャードにはドキュメントのすべてのプロパティが含まれますが、含まれるJSONオブジェクトの数はインデックスよりも少なくなります。 水平分離により、シャードは独立したノードになり、任意のノードに保存できます。 プライマリシャードはインデックスの元の水平部分であり、これらのプライマリシャードはレプリカシャードに複製されます。
レプリカ
Elasticsearchを使用すると、ユーザーはインデックスとシャードのレプリカを作成できます。 レプリケーションは、障害が発生した場合にデータの可用性を高めるのに役立つだけでなく、これらのレプリカで並列検索操作を実行することで検索のパフォーマンスを向上させます。
利点
- ElasticsearchはJavaで開発されているため、ほぼすべてのプラットフォームで互換性があります。
- Elasticsearchはリアルタイムです。つまり、1秒後に、追加されたドキュメントがこのエンジンで検索可能になります。
- Elasticsearchは分散されているため、大規模な組織に簡単に拡張および統合できます。
- Elasticsearchに存在するゲートウェイの概念を使用すると、完全バックアップを簡単に作成できます。
- マルチテナントの処理は、Apache Solrと比較するとElasticsearchでは非常に簡単です。
- Elasticsearchは応答としてJSONオブジェクトを使用するため、多数の異なるプログラミング言語でElasticsearchサーバーを呼び出すことができます。
- Elasticsearchは、テキストレンダリングをサポートしていないドキュメントタイプを除く、ほぼすべてのドキュメントタイプをサポートしています。
デメリット
- Elasticsearchは、CSV、XML、およびJSON形式で可能なApache Solrとは異なり、要求および応答データ（JSONでのみ可能）の処理に関して多言語をサポートしていません。
- 時折、Elasticsearchにはスプリットブレインの状況の問題があります。
ElasticsearchとRDBMSの比較
Elasticsearchでは、インデックスはRDBMS（リレーションデータベース管理システム）のテーブルに似ています。 すべてのインデックスがElasticsearchのドキュメントのコレクションであるように、すべてのテーブルは行のコレクションです。
次の表は、これらの用語の直接比較を示しています。
| Elasticsearch | RDBMS |
|---|---|
| Cluster | Database |
| Shard | Shard |
| Index | Table |
| Field | Column |
| Document | Row |
Elasticsearch-インストール
この章では、Elasticsearchのインストール手順を詳細に理解します。
ローカルコンピューターにElasticsearchをインストールするには、以下の手順に従う必要があります-
- ステップ1 *-コンピューターにインストールされているjavaのバージョンを確認します。 Java 7以上である必要があります。 あなたは次のことを行うことで確認できます-
Windowsオペレーティングシステム（OS）の場合（コマンドプロンプトを使用）-
> java -versionUNIX OSの場合（ターミナルを使用）-
$ echo $JAVA_HOME- ステップ2 *-オペレーティングシステムに応じて、下記のようにwww.elastic.coからElasticsearchをダウンロードします-
- Windows OSの場合、ZIPファイルをダウンロードします。
- UNIX OSの場合、TARファイルをダウンロードします。
- Debian OSの場合、DEBファイルをダウンロードします。
- Red Hatおよびその他のLinuxディストリビューションの場合、RPNファイルをダウンロードします。
- APTおよびYumユーティリティを使用して、多くのLinuxディストリビューションにElasticsearchをインストールすることもできます。
- ステップ3 *-Elasticsearchのインストールプロセスは簡単で、OSごとに以下で説明します-
- * Windows OS *-zipパッケージを解凍すると、Elasticsearchがインストールされます。
- * UNIX OS *-任意の場所にtarファイルを抽出すると、Elasticsearchがインストールされます。
$wget
https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch7.0.0-linux-x86_64.tar.gz
$tar -xzf elasticsearch-7.0.0-linux-x86_64.tar.gz- Linux OS用のAPTユーティリティの使用-公開署名キーをダウンロードしてインストールします
$ wget -qo - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo
apt-key add -以下に示すようにリポジトリ定義を保存します-
$ echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" |
sudo tee -a/etc/apt/sources.list.d/elastic-7.x.list次のコマンドを使用して更新を実行します-
$ sudo apt-get update今、あなたは次のコマンドを使用してインストールすることができます-
$ sudo apt-get install elasticsearch- ここで指定されたコマンドを使用して、Debianパッケージを手動でダウンロードしてインストールします-
$wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch7.0.0-amd64.deb
$sudo dpkg -i elasticsearch-7.0.0-amd64.deb0- * Debian Linux OS用のYUMユーティリティの使用*
$ rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch- 「/etc/yum.repos.d/」ディレクトリ内の接尾辞が.repoのファイルに次のテキストを追加します。 たとえば、elasticsearch.repo
elasticsearch-7.x]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md- 次のコマンドを使用してElasticsearchをインストールできるようになりました
sudo yum install elasticsearch- ステップ4 *-Elasticsearchホームディレクトリおよびbinフォルダー内に移動します。 Windowsの場合はelasticsearch.batファイルを実行します。または、UNIXラムElasticsearchファイルの場合は、コマンドプロンプトとターミナルを使用して同じことを実行できます。
Windowsの場合
> cd elasticsearch-2.1.0/bin
> elasticsearchLinuxの場合
$ cd elasticsearch-2.1.0/bin
$ ./elasticsearch注-Windowsの場合、JAVA_HOMEが設定されていないことを示すエラーが表示される場合があります。環境変数で「C：\ Program Files \ Java \ jre1.8.0_31」またはjavaをインストールした場所に設定してください。
ステップ5 *-Elasticsearch Webインターフェースのデフォルトポートは9200であるか、binディレクトリにあるelasticsearch.ymlファイル内のhttp.portを変更することで変更できます。 *http：//localhost：9200 を参照すると、サーバーが稼働しているかどうかを確認できます。 次の方法でインストールされたElasticsearchに関する情報を含むJSONオブジェクトを返します-
{
"name" : "Brain-Child",
"cluster_name" : "elasticsearch", "version" : {
"number" : "2.1.0",
"build_hash" : "72cd1f1a3eee09505e036106146dc1949dc5dc87",
"build_timestamp" : "2015-11-18T22:40:03Z",
"build_snapshot" : false,
"lucene_version" : "5.3.1"
},
"tagline" : "You Know, for Search"
}- ステップ6 *-このステップでは、Kibanaをインストールします。 LinuxおよびWindowsにインストールする場合は、以下の各コードに従ってください-
- Linuxにインストールする場合-*
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.0.0-linuxx86_64.tar.gz
tar -xzf kibana-7.0.0-linux-x86_64.tar.gz
cd kibana-7.0.0-linux-x86_64/
./bin/kibana- Windowsにインストールする場合-*
[[1]] for Windowsをダウンロードします。 リンクをクリックすると、次のようにホームページが表示されます-
解凍してKibanaホームディレクトリに移動し、実行します。
CD c:\kibana-7.0.0-windows-x86_64
.\bin\kibana.batElasticsearch-移入
この章では、インデックス、マッピング、データをElasticsearchに追加する方法を学びましょう。 このデータの一部は、このチュートリアルで説明する例で使用されることに注意してください。
インデックス作成
次のコマンドを使用してインデックスを作成できます-
PUT school応答
インデックスが作成された場合、次の出力を見ることができます-
{"acknowledged": true}データを追加する
Elasticsearchは、次のコードに示すように、インデックスに追加するドキュメントを保存します。 ドキュメントには、ドキュメントの識別に使用されるいくつかのIDが与えられます。
リクエスト本文
POST school/_doc/10
{
"name":"Saint Paul School", "description":"ICSE Afiliation",
"street":"Dawarka", "city":"Delhi", "state":"Delhi", "zip":"110075",
"location":[28.5733056, 77.0122136], "fees":5000,
"tags":["Good Faculty", "Great Sports"], "rating":"4.5"
}応答
{
"_index" : "school",
"_type" : "_doc",
"_id" : "10",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 2,
"_primary_term" : 1
}ここでは、同様のドキュメントをもう1つ追加しています。
POST school/_doc/16
{
"name":"Crescent School", "description":"State Board Affiliation",
"street":"Tonk Road",
"city":"Jaipur", "state":"RJ", "zip":"176114","location":[26.8535922,75.7923988],
"fees":2500, "tags":["Well equipped labs"], "rating":"4.5"
}応答
{
"_index" : "school",
"_type" : "_doc",
"_id" : "16",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 9,
"_primary_term" : 7
}このようにして、今後の章での作業に必要なサンプルデータを追加し続けます。
Kibanaでのサンプルデータの追加
Kibanaは、データにアクセスして視覚化を作成するためのGUI駆動型ツールです。 このセクションでは、サンプルデータを追加する方法を理解しましょう。
Kibanaホームページで、次のオプションを選択してサンプルのeコマースデータを追加します-
次の画面には、いくつかの視覚化とデータを追加するボタンが表示されます-
[データの追加]をクリックすると、データがeCommerceという名前のインデックスに追加されたことを確認する次の画面が表示されます。
Elasticsearch-バージョン間の移行
どのシステムまたはソフトウェアでも、新しいバージョンにアップグレードする場合、アプリケーションの設定、構成、データなどを維持するためにいくつかの手順に従う必要があります。 これらの手順は、新しいシステムでアプリケーションを安定させるため、またはデータの整合性を維持するために必要です（データが破損しないようにします）。
Elasticsearchをアップグレードするには、次の手順に従う必要があります-
- [[2]]
- UAT、E2E、SIT、またはDEV環境などの非実稼働環境でアップグレードされたバージョンをテストします。
- 以前のElasticsearchバージョンへのロールバックは、データバックアップなしでは不可能であることに注意してください。 したがって、上位バージョンにアップグレードする前に、データのバックアップをお勧めします。
- 完全なクラスター再起動またはローリングアップグレードを使用してアップグレードできます。 ローリングアップグレードは、新しいバージョン用です。 移行にローリングアップグレード方式を使用している場合、サービスの停止はありません。
アップグレードの手順
- 実稼働クラスターをアップグレードする前に、開発環境でアップグレードをテストします。
- データをバックアップします。 データのスナップショットがない限り、以前のバージョンにロールバックすることはできません。
- アップグレードプロセスを開始する前に、機械学習ジョブを閉じることを検討してください。 機械学習ジョブはローリングアップグレード中も引き続き実行できますが、アップグレードプロセス中のクラスターのオーバーヘッドが増加します。
- 次の順序でElastic Stackのコンポーネントをアップグレードします-
- エラスティックサーチ
- キバナ
- Logstash
- ビート
- APMサーバー
6.6以前からのアップグレード
バージョン6.0-6.6からElasticsearch 7.1.0に直接アップグレードするには、繰り越す必要のある5.xインデックスを手動で再インデックスし、クラスター全体の再起動を実行する必要があります。
完全なクラスター再起動
完全なクラスター再起動のプロセスには、クラスター内の各ノードのシャットダウン、各ノードの7xへのアップグレード、およびクラスターの再起動が含まれます。
以下は、完全なクラスタ再起動のために実行する必要がある高レベルの手順です-
- シャード割り当てを無効にする
- {ブランク}
- インデックス作成を停止し、同期フラッシュを実行します
- {ブランク}
- すべてのノードをシャットダウンします
- {ブランク}
- すべてのノードをアップグレードする
- {ブランク}
- プラグインをアップグレードする
- {ブランク}
- アップグレードされた各ノードを起動します
- {ブランク}
- すべてのノードがクラスターに参加し、黄色のステータスを報告するのを待ちます
- {ブランク}
- 割り当てを再度有効にする
- {ブランク}
割り当てが再び有効になると、クラスターはレプリカシャードのデータノードへの割り当てを開始します。 この時点で、インデックス作成と検索を再開しても安全ですが、すべてのプライマリシャードとレプリカシャードが正常に割り当てられ、すべてのノードのステータスが緑になるまで待機できる場合、クラスターはより迅速に回復します。
Elasticsearch-APIの規則
WebのApplication Programming Interface（API）は、特定のWebアプリケーションのソフトウェアコンポーネントにアクセスするための関数呼び出しまたはその他のプログラミング命令のグループです。 たとえば、Facebook APIは、開発者がFacebookのデータやその他の機能にアクセスしてアプリケーションを作成するのに役立ちます。生年月日またはステータスの更新です。
Elasticsearchは、HTTP経由でJSONによってアクセスされるREST APIを提供します。 Elasticsearchでは、これから説明するいくつかの規則を使用します。
複数のインデックス
APIのほとんどの操作（主に検索などの操作）は、1つまたは複数のインデックス用です。 これにより、ユーザーはクエリを1回実行するだけで、複数の場所または利用可能なすべてのデータを検索できます。 複数のインデックスで操作を実行するには、多くの異なる表記法が使用されます。 この章では、そのうちのいくつかについて説明します。
カンマ区切り表記
POST/index1,index2,index3/_searchリクエスト本文
{
"query":{
"query_string":{
"query":"any_string"
}
}
}応答
any_stringを含むindex1、index2、index3のJSONオブジェクト。
_allすべてのインデックスのキーワード
POST/_all/_searchリクエスト本文
{
"query":{
"query_string":{
"query":"any_string"
}
}
}応答
すべてのインデックスからのJSONオブジェクトで、any_stringが含まれています。
ワイルドカード（*、+、–）
POST/school*/_searchリクエスト本文
{
"query":{
"query_string":{
"query":"CBSE"
}
}
}応答
CBSEを含む学校で始まるすべてのインデックスからのJSONオブジェクト。
または、次のコードも使用できます-
POST/school*,-schools_gov/_searchリクエスト本文
{
"query":{
"query_string":{
"query":"CBSE"
}
}
}応答
「school」で始まるすべてのインデックスからのJSONオブジェクト。schools_govからではなく、CBSEが含まれます。
また、いくつかのURLクエリ文字列パラメータがあります-
- ignore_unavailable -URLに存在する1つ以上のインデックスが存在しない場合、エラーは発生せず、操作も停止しません。 たとえば、学校のインデックスは存在しますが、book_shopsは存在しません。
POST/school*,book_shops/_searchリクエスト本文
{
"query":{
"query_string":{
"query":"CBSE"
}
}
}リクエスト本文
{
"error":{
"root_cause":[{
"type":"index_not_found_exception", "reason":"no such index",
"resource.type":"index_or_alias", "resource.id":"book_shops",
"index":"book_shops"
}],
"type":"index_not_found_exception", "reason":"no such index",
"resource.type":"index_or_alias", "resource.id":"book_shops",
"index":"book_shops"
},"status":404
}次のコードを考慮してください-
POST/school*,book_shops/_search?ignore_unavailable = trueリクエスト本文
{
"query":{
"query_string":{
"query":"CBSE"
}
}
}応答（エラーなし）
CBSEを含む学校で始まるすべてのインデックスからのJSONオブジェクト。
allow_no_indices
ワイルドカードを含むURLがインデックスを持たない場合、このパラメーターの true 値はエラーを防ぎます。 たとえば、schools_priで始まるインデックスはありません-
POST/schools_pri*/_search?allow_no_indices = trueリクエスト本文
{
"query":{
"match_all":{}
}
}応答（エラーなし）
{
"took":1,"timed_out": false, "_shards":{"total":0, "successful":0, "failed":0},
"hits":{"total":0, "max_score":0.0, "hits":[]}
}expand_wildcards
このパラメーターは、ワイルドカードを開いたインデックスまたは閉じたインデックスに展開する必要があるか、両方を実行する必要があるかを決定します。 このパラメーターの値は、開いたり閉じたりすることができます。
例えば、近いインデックス学校-
POST/schools/_close応答
{"acknowledged":true}次のコードを考慮してください-
POST/school*/_search?expand_wildcards = closedリクエスト本文
{
"query":{
"match_all":{}
}
}応答
{
"error":{
"root_cause":[{
"type":"index_closed_exception", "reason":"closed", "index":"schools"
}],
"type":"index_closed_exception", "reason":"closed", "index":"schools"
}, "status":403
}インデックス名での日付数学のサポート
Elasticsearchは、日付と時刻に従ってインデックスを検索する機能を提供します。 特定の形式で日付と時刻を指定する必要があります。 たとえば、accountdetail-2015.12.30のインデックスには、2015年12月30日の銀行口座の詳細が格納されます。 数学演算を実行して、特定の日付または日付と時刻の範囲の詳細を取得できます。
日付数学インデックス名の形式-
<static_name{date_math_expr{date_format|time_zone}}>
/<accountdetail-{now-2d{YYYY.MM.dd|utc}}>/_searchstatic_nameは式の一部であり、アカウント詳細などのすべての日付数学インデックスで同じままです。 date_math_exprには、now-2dのように日付と時刻を動的に決定する数式が含まれています。 date_formatには、YYYY.MM.ddのようなインデックスに日付が書き込まれる形式が含まれます。 今日の日付が2015年12月30日の場合、<accountdetail-\ {now-2d \ {YYYY.MM.dd}}>はaccountdetail-2015.12.28を返します。
| Expression | Resolves to |
|---|---|
| <accountdetail-{now-d}> | accountdetail-2015.12.29 |
| <accountdetail-{now-M}> | accountdetail-2015.11.30 |
| <accountdetail-\{now\{YYYY.MM}}> | accountdetail-2015.12 |
指定された形式で応答を取得するために使用できるElasticsearchで利用可能な一般的なオプションのいくつかが表示されます。
きれいな結果
URLクエリパラメータ、つまりpretty = trueを追加するだけで、適切にフォーマットされたJSONオブジェクトで応答を取得できます。
POST/schools/_search?pretty = trueリクエスト本文
{
"query":{
"match_all":{}
}
}応答
……………………..
{
"_index" : "schools", "_type" : "school", "_id" : "1", "_score" : 1.0,
"_source":{
"name":"Central School", "description":"CBSE Affiliation",
"street":"Nagan", "city":"paprola", "state":"HP", "zip":"176115",
"location": [31.8955385, 76.8380405], "fees":2000,
"tags":["Senior Secondary", "beautiful campus"], "rating":"3.5"
}
}
………………….人間が読める出力
このオプションは、統計応答を人間が読める形式（人間= trueの場合）またはコンピューターが読める形式（人間= falseの場合）に変更できます。 たとえば、人間= trueの場合、distance_kilometer = 20KMであり、人間= falseの場合、distance_meter = 20000の場合、応答は別のコンピュータープログラムで使用する必要があります。
応答フィルタリング
field_pathパラメーターに追加することで、より少ないフィールドへの応答をフィルター処理できます。 例えば、
POST/schools/_search?filter_path = hits.totalリクエスト本文
{
"query":{
"match_all":{}
}
}応答
{"hits":{"total":3}}Elasticsearch-ドキュメントAPI
Elasticsearchは、単一ドキュメントAPIと複数ドキュメントAPIを提供します。API呼び出しは、それぞれ単一ドキュメントと複数ドキュメントを対象としています。
インデックスAPI
特定のマッピングでそれぞれのインデックスにリクエストが行われたときに、インデックスにJSONドキュメントを追加または更新するのに役立ちます。 たとえば、次のリクエストはJSONオブジェクトを追加し、学校と学校マッピングの下にインデックスを付けます-
PUT schools/_doc/5
{
name":"City School", "description":"ICSE", "street":"West End",
"city":"Meerut",
"state":"UP", "zip":"250002", "location":[28.9926174, 77.692485],
"fees":3500,
"tags":["fully computerized"], "rating":"4.5"
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "5",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 2,
"_primary_term" : 1
}自動インデックス作成
JSONオブジェクトを特定のインデックスに追加するリクエストが行われ、そのインデックスが存在しない場合、このAPIはそのインデックスとその特定のJSONオブジェクトの基になるマッピングを自動的に作成します。 この機能を無効にするには、次のパラメーターの値をfalseに変更します。これはelasticsearch.ymlファイルにあります。
action.auto_create_index:false
index.mapper.dynamic:falseまた、次のパラメータの値を変更することにより、特定のパターンを持つインデックス名のみが許可されているインデックスの自動作成を制限することができます-
action.auto_create_index:+acc*,-bank*注-ここで+は許可されていることを示し、-は許可されていないことを示します。
バージョニング
Elasticsearchはバージョン管理機能も提供します。 バージョンクエリパラメータを使用して、特定のドキュメントのバージョンを指定できます。
PUT schools/_doc/5?version=7&version_type=external
{
"name":"Central School", "description":"CBSE Affiliation", "street":"Nagan",
"city":"paprola", "state":"HP", "zip":"176115", "location":[31.8955385, 76.8380405],
"fees":2200, "tags":["Senior Secondary", "beautiful campus"], "rating":"3.3"
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "5",
"_version" : 7,
"result" : "updated",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 3,
"_primary_term" : 1
}バージョニングはリアルタイムのプロセスであり、リアルタイムの検索操作の影響を受けません。
バージョン管理には2つの最も重要なタイプがあります-
内部バージョン管理
内部バージョニングは、1から始まり、更新ごとに増分されるデフォルトのバージョンで、削除が含まれます。
外部バージョン管理
ドキュメントのバージョン管理がサードパーティのバージョン管理システムなどの外部システムに保存されている場合に使用されます。 この機能を有効にするには、version_typeをexternalに設定する必要があります。 ここで、Elasticsearchは外部システムによって指定されたバージョン番号を保存し、自動的にインクリメントしません。
操作タイプ
操作タイプは、作成操作を強制するために使用されます。 これにより、既存のドキュメントの上書きを回避できます。
PUT chapter/_doc/1?op_type=create
{
"Text":"this is chapter one"
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "chapter",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}自動ID生成
IDがインデックス操作で指定されていない場合、ElasticsearchはそのドキュメントのIDを自動的に生成します。
POST chapter/_doc/
{
"user" : "tpoint",
"post_date" : "2018-12-25T14:12:12",
"message" : "Elasticsearch Tutorial"
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "chapter",
"_type" : "_doc",
"_id" : "PVghWGoB7LiDTeV6LSGu",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1
}APIを取得
APIは、特定のドキュメントに対してgetリクエストを実行することにより、タイプJSONオブジェクトを抽出するのに役立ちます。
pre class="prettyprint notranslate" > GET schools/_doc/5上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "5",
"_version" : 7,
"_seq_no" : 3,
"_primary_term" : 1,
"found" : true,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
}- この操作はリアルタイムであり、Indexのリフレッシュレートの影響を受けません。
- バージョンを指定することもできます。Elasticsearchはそのバージョンのドキュメントのみを取得します。
- Elasticsearchが検索できるように、リクエストで_allを指定することもできます すべてのタイプのそのドキュメントIDに対して、最初に一致したドキュメントを返します。
- また、特定のドキュメントの結果に必要なフィールドを指定することもできます。
GET schools/_doc/5?_source_includes=name,fees上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "5",
"_version" : 7,
"_seq_no" : 3,
"_primary_term" : 1,
"found" : true,
"_source" : {
"fees" : 2200,
"name" : "Central School"
}
}getリクエストに_sourceパーツを追加するだけで、結果のソースパーツを取得することもできます。
GET schools/_doc/5?_source上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "5",
"_version" : 7,
"_seq_no" : 3,
"_primary_term" : 1,
"found" : true,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
}refreshパラメーターをtrueに設定することにより、get操作を実行する前にシャードを更新することもできます。
APIを削除
ElasticsearchにHTTP DELETEリクエストを送信することにより、特定のインデックス、マッピング、またはドキュメントを削除できます。
DELETE schools/_doc/4上記のコードを実行すると、次の結果が得られます-
{
"found":true, "_index":"schools", "_type":"school", "_id":"4", "_version":2,
"_shards":{"total":2, "successful":1, "failed":0}
}ドキュメントのバージョンを指定して、その特定のバージョンを削除できます。 ルーティングパラメータを指定して、特定のユーザーからドキュメントを削除できます。ドキュメントがその特定のユーザーに属していない場合、操作は失敗します。 この操作では、GET APIと同じように、リフレッシュオプションとタイムアウトオプションを指定できます。
更新API
この操作を実行するためにスクリプトが使用され、バージョニングが使用されて、取得および再インデックス中に更新が発生していないことを確認します。 たとえば、あなたはスクリプトを使用して学校の費用を更新することができます-
POST schools/_update/4
{
"script" : {
"source": "ctx._source.name = params.sname",
"lang": "painless",
"params" : {
"sname" : "City Wise School"
}
}
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "schools",
"_type" : "_doc",
"_id" : "4",
"_version" : 3,
"result" : "updated",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 4,
"_primary_term" : 2
}更新されたドキュメントにgetリクエストを送信して、更新を確認できます。
Elasticsearch-検索API
このAPIは、Elasticsearchでコンテンツを検索するために使用されます。 ユーザーは、パラメーターとしてクエリ文字列を使用してgetリクエストを送信することで検索できます。または、ポストリクエストのメッセージ本文にクエリを投稿できます。 主にすべての検索APIはマルチインデックス、マルチタイプです。
マルチインデックス
Elasticsearchでは、すべてのインデックスまたは特定のインデックスに存在するドキュメントを検索できます。 たとえば、中央を含む名前を持つすべてのドキュメントを検索する必要がある場合、ここに示すように行うことができます-
GET/_all/_search?q=city:paprola上記のコードを実行すると、次の応答が得られます-
{
"took" : 33,
"timed_out" : false,
"_shards" : {
"total" : 7,
"successful" : 7,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.9808292,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "5",
"_score" : 0.9808292,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
}
]
}
}URI検索
Uniform Resource Identifierを使用して、検索操作で多くのパラメーターを渡すことができます-
| S.No | Parameter & Description |
|---|---|
| 1 |
Q このパラメーターは、クエリ文字列を指定するために使用されます。 |
| 2 |
lenient このパラメーターは、クエリ文字列を指定するために使用されます。このパラメーターをtrueに設定するだけで、フォーマットベースのエラーを無視できます。 デフォルトではfalseです。 |
| 3 |
fields このパラメーターは、クエリ文字列を指定するために使用されます。 |
| 4 |
sort このパラメーターを使用して、ソートされた結果を取得できます。このパラメーターに指定できる値は、fieldName、fieldName：asc/fieldname：descです。 |
| 5 |
timeout このパラメーターを使用して検索時間を制限でき、応答にはその指定された時間のヒットのみが含まれます。 デフォルトでは、タイムアウトはありません。 |
| 6 |
terminate_after シャードごとに指定された数のドキュメントに応答を制限し、それに到達すると、クエリは早期に終了します。 デフォルトでは、terminate_afterはありません。 |
| 7 |
from 返すヒットの開始インデックス。 デフォルトは0です。 |
| 8 |
size 返されるヒット数を示します。 デフォルトは10です。 |
ボディ検索のリクエスト
リクエストボディでクエリDSLを使用してクエリを指定することもできます。これまでの章では、すでに多くの例が示されています。 そのような例の1つをここに示します-
POST/schools/_search
{
"query":{
"query_string":{
"query":"up"
}
}
}上記のコードを実行すると、次の応答が得られます-
{
"took" : 11,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.47000363,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "4",
"_score" : 0.47000363,
"_source" : {
"name" : "City Best School",
"description" : "ICSE",
"street" : "West End",
"city" : "Meerut",
"state" : "UP",
"zip" : "250002",
"location" : [
28.9926174,
77.692485
],
"fees" : 3500,
"tags" : [
"fully computerized"
],
"rating" : "4.5"
}
}
]
}
}Elasticsearch-集計
集計フレームワークは、検索クエリによって選択されたすべてのデータを収集し、データの複雑な概要を構築するのに役立つ多くのビルディングブロックで構成されます。 集約の基本構造はここに示されています-
"aggregations" : {
"" : {
"" : {
}
[,"meta" : { [] } ]?
[,"aggregations" : { []+ } ]?
}
[,"" : { ... } ]*
}さまざまなタイプの集約があり、それぞれ独自の目的があります。 これらについては、この章で詳しく説明します。
メトリック集計
これらの集約は、集約されたドキュメントのフィールドの値からマトリックスを計算するのに役立ち、スクリプトからいくつかの値を生成できる場合もあります。
数値マトリックスは、平均集約のような単一値または統計のような複数値のいずれかです。
平均集計
この集約は、集約されたドキュメントに存在する数値フィールドの平均を取得するために使用されます。 例えば、
POST/schools/_search
{
"aggs":{
"avg_fees":{"avg":{"field":"fees"}}
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 41,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "5",
"_score" : 1.0,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
},
{
"_index" : "schools",
"_type" : "school",
"_id" : "4",
"_score" : 1.0,
"_source" : {
"name" : "City Best School",
"description" : "ICSE",
"street" : "West End",
"city" : "Meerut",
"state" : "UP",
"zip" : "250002",
"location" : [
28.9926174,
77.692485
],
"fees" : 3500,
"tags" : [
"fully computerized"
],
"rating" : "4.5"
}
}
]
},
"aggregations" : {
"avg_fees" : {
"value" : 2850.0
}
}
}カーディナリティー集約
この集計は、特定のフィールドの個別の値のカウントを提供します。
POST/schools/_search?size=0
{
"aggs":{
"distinct_name_count":{"cardinality":{"field":"fees"}}
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"distinct_name_count" : {
"value" : 2
}
}
}注-料金には2つの異なる値があるため、カーディナリティの値は2です。
拡張統計集約
この集約により、集約されたドキュメントの特定の数値フィールドに関するすべての統計が生成されます。
POST/schools/_search?size=0
{
"aggs" : {
"fees_stats" : { "extended_stats" : { "field" : "fees" } }
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 8,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"fees_stats" : {
"count" : 2,
"min" : 2200.0,
"max" : 3500.0,
"avg" : 2850.0,
"sum" : 5700.0,
"sum_of_squares" : 1.709E7,
"variance" : 422500.0,
"std_deviation" : 650.0,
"std_deviation_bounds" : {
"upper" : 4150.0,
"lower" : 1550.0
}
}
}
}最大集約
この集約は、集約されたドキュメント内の特定の数値フィールドの最大値を見つけます。
POST/schools/_search?size=0
{
"aggs" : {
"max_fees" : { "max" : { "field" : "fees" } }
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 16,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"max_fees" : {
"value" : 3500.0
}
}
}最小集約
この集約は、集約されたドキュメント内の特定の数値フィールドの最小値を見つけます。
POST/schools/_search?size=0
{
"aggs" : {
"min_fees" : { "min" : { "field" : "fees" } }
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"min_fees" : {
"value" : 2200.0
}
}
}総計
この集約は、集約されたドキュメント内の特定の数値フィールドの合計を計算します。
POST/schools/_search?size=0
{
"aggs" : {
"total_fees" : { "sum" : { "field" : "fees" } }
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 8,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"total_fees" : {
"value" : 5700.0
}
}
}地理的位置の目的で、地理的境界の集計や地理的重心の集計などの特別な場合に使用される他のメトリック集計がいくつかあります。
統計集約
集約されたドキュメントから抽出された数値の統計を計算する複数値メトリック集約。
POST/schools/_search?size=0
{
"aggs" : {
"grades_stats" : { "stats" : { "field" : "fees" } }
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"grades_stats" : {
"count" : 2,
"min" : 2200.0,
"max" : 3500.0,
"avg" : 2850.0,
"sum" : 5700.0
}
}
}集約メタデータ
メタタグを使用して、リクエスト時に集約に関するデータを追加し、応答で取得できます。
POST/schools/_search?size=0
{
"aggs" : {
"min_fees" : { "avg" : { "field" : "fees" } ,
"meta" :{
"dsc" :"Lowest Fees This Year"
}
}
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 0,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"aggregations" : {
"min_fees" : {
"meta" : {
"dsc" : "Lowest Fees This Year"
},
"value" : 2850.0
}
}
}Elasticsearch-インデックスAPI
これらのAPIは、設定、エイリアス、マッピング、インデックステンプレートなど、インデックスのすべての側面を管理します。
インデックス作成
このAPIは、インデックスの作成に役立ちます。 インデックスは、ユーザーがJSONオブジェクトをインデックスに渡すときに自動的に作成することも、その前に作成することもできます。 インデックスを作成するには、設定、マッピング、エイリアスを含むPUTリクエストを送信するか、本文のない単純なリクエストを送信するだけです。
PUT colleges上記のコードを実行すると、次のように出力が得られます-
{
"acknowledged" : true,
"shards_acknowledged" : true,
"index" : "colleges"
}また、上記のコマンドにいくつかの設定を追加することができます-
PUT colleges
{
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 2
}
}
}上記のコードを実行すると、次のように出力が得られます-
{
"acknowledged" : true,
"shards_acknowledged" : true,
"index" : "colleges"
}インデックスを削除
このAPIは、インデックスを削除するのに役立ちます。 その特定のインデックスの名前で削除リクエストを渡すだけです。
DELETE/colleges_allまたは*を使用するだけで、すべてのインデックスを削除できます。
インデックスを取得
このAPIは、1つまたは複数のインデックスにgetリクエストを送信するだけで呼び出すことができます。 これは、インデックスに関する情報を返します。
GET colleges上記のコードを実行すると、次のように出力が得られます-
{
"colleges" : {
"aliases" : {
"alias_1" : { },
"alias_2" : {
"filter" : {
"term" : {
"user" : "pkay"
}
},
"index_routing" : "pkay",
"search_routing" : "pkay"
}
},
"mappings" : { },
"settings" : {
"index" : {
"creation_date" : "1556245406616",
"number_of_shards" : "1",
"number_of_replicas" : "1",
"uuid" : "3ExJbdl2R1qDLssIkwDAug",
"version" : {
"created" : "7000099"
},
"provided_name" : "colleges"
}
}
}
}_allまたは*を使用して、すべてのインデックスの情報を取得できます。
インデックスが存在する
インデックスの存在は、getリクエストをそのインデックスに送信するだけで判断できます。 HTTP応答が200の場合、存在します。 404の場合、存在しません。
HEAD colleges上記のコードを実行すると、次のように出力が得られます-
200-OKインデックス設定
URLの最後に_settingsキーワードを追加するだけで、インデックス設定を取得できます。
GET/colleges/_settings上記のコードを実行すると、次のように出力が得られます-
{
"colleges" : {
"settings" : {
"index" : {
"creation_date" : "1556245406616",
"number_of_shards" : "1",
"number_of_replicas" : "1",
"uuid" : "3ExJbdl2R1qDLssIkwDAug",
"version" : {
"created" : "7000099"
},
"provided_name" : "colleges"
}
}
}
}インデックスの統計
このAPIは、特定のインデックスに関する統計を抽出するのに役立ちます。 最後にインデックスURLと_statsキーワードを使用してgetリクエストを送信するだけです。
GET/_stats上記のコードを実行すると、次のように出力が得られます-
………………………………………………
},
"request_cache" : {
"memory_size_in_bytes" : 849,
"evictions" : 0,
"hit_count" : 1171,
"miss_count" : 4
},
"recovery" : {
"current_as_source" : 0,
"current_as_target" : 0,
"throttle_time_in_millis" : 0
}
} ………………………………………………流す
インデックスのフラッシュプロセスにより、現在トランザクションログにのみ保存されているデータがLuceneにも永続的に保存されるようになります。 これにより、Luceneインデックスが開かれた後、トランザクションログからデータのインデックスを再作成する必要がないため、リカバリ時間が短縮されます。
POST colleges/_flush上記のコードを実行すると、次のように出力が得られます-
{
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
}
}Elasticsearch-Cat API
通常、さまざまなElasticsearch APIからの結果はJSON形式で表示されます。 ただし、JSONは常に読みやすいとは限りません。 そのため、Elasticsearchでcat API機能を使用すると、結果の印刷形式を読みやすく理解しやすくすることができます。 cat APIにはさまざまな目的で使用されるさまざまなパラメーターがあります。たとえば、Vという用語は出力を冗長にします。
この章では、cat APIについて詳しく説明します。
冗長
詳細出力では、catコマンドの結果が見やすく表示されます。 以下の例では、クラスターに存在するさまざまなインデックスの詳細を取得します。
GET/_cat/indices?v上記のコードを実行すると、次のように応答が得られます-
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open schools RkMyEn2SQ4yUgzT6EQYuAA 1 1 2 1 21.6kb 21.6kb
yellow open index_4_analysis zVmZdM1sTV61YJYrNXf1gg 1 1 0 0 283b 283b
yellow open sensor-2018-01-01 KIrrHwABRB-ilGqTu3OaVQ 1 1 1 0 4.2kb 4.2kb
yellow open colleges 3ExJbdl2R1qDLssIkwDAug 1 1 0 0 283b 283bヘッダ
ヘッダーとも呼ばれるhパラメーターは、コマンドで言及されている列のみを表示するために使用されます。
GET/_cat/nodes?h=ip,port上記のコードを実行すると、次のように応答が得られます-
127.0.0.1 9300Sort
sortコマンドは、クエリ内の指定された列でテーブルをソートできるクエリ文字列を受け入れます。 デフォルトのソートは昇順ですが、これは列に：descを追加することで変更できます。
以下の例は、フィールド化されたインデックスパターンの降順に並べられたテンプレートの結果を示しています。
GET _cat/templates?v&s=order:desc,index_patterns上記のコードを実行すると、次のように応答が得られます-
name index_patterns order version
.triggered_watches [.triggered_watches*] 2147483647
.watch-history-9 [.watcher-history-9*] 2147483647
.watches [.watches*] 2147483647
.kibana_task_manager [.kibana_task_manager] 0 7000099カウント
countパラメーターは、クラスター全体のドキュメントの総数のカウントを提供します。
GET/_cat/count?v上記のコードを実行すると、次のように応答が得られます-
epoch timestamp count
1557633536 03:58:56 17809Elasticsearch-クラスターAPI
クラスターAPIは、クラスターとそのノードに関する情報を取得し、それらを変更するために使用されます。 このAPIを呼び出すには、ノード名、アドレス、または_localを指定する必要があります。
GET/_nodes/_local上記のコードを実行すると、次のように応答が得られます-
………………………………………………
cluster_name" : "elasticsearch",
"nodes" : {
"FKH-5blYTJmff2rJ_lQOCg" : {
"name" : "ubuntu",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1",
"version" : "7.0.0",
"build_flavor" : "default",
"build_type" : "tar",
"build_hash" : "b7e28a7",
"total_indexing_buffer" : 106502553,
"roles" : [
"master",
"data",
"ingest"
],
"attributes" : {
………………………………………………クラスターの健全性
このAPIは、「health」キーワードを追加することにより、クラスターの状態に関するステータスを取得するために使用されます。
GET/_cluster/health上記のコードを実行すると、次のように応答が得られます-
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 7,
"active_shards" : 7,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 4,
"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" : 63.63636363636363
}クラスター状態
このAPIは、「状態」キーワードURLを追加することにより、クラスターに関する状態情報を取得するために使用されます。 状態情報には、バージョン、マスターノード、他のノード、ルーティングテーブル、メタデータ、ブロックが含まれます。
GET/_cluster/state上記のコードを実行すると、次のように応答が得られます-
………………………………………………
{
"cluster_name" : "elasticsearch",
"cluster_uuid" : "IzKu0OoVTQ6LxqONJnN2eQ",
"version" : 89,
"state_uuid" : "y3BlwvspR1eUQBTo0aBjig",
"master_node" : "FKH-5blYTJmff2rJ_lQOCg",
"blocks" : { },
"nodes" : {
"FKH-5blYTJmff2rJ_lQOCg" : {
"name" : "ubuntu",
"ephemeral_id" : "426kTGpITGixhEzaM-5Qyg",
"transport
}
………………………………………………クラスター統計
このAPIは、「stats」キーワードを使用してクラスターに関する統計を取得するのに役立ちます。 このAPIは、シャード番号、ストアサイズ、メモリ使用量、ノード数、ロール、OS、およびファイルシステムを返します。
GET/_cluster/stats上記のコードを実行すると、次のように応答が得られます-
………………………………………….
"cluster_name" : "elasticsearch",
"cluster_uuid" : "IzKu0OoVTQ6LxqONJnN2eQ",
"timestamp" : 1556435464704,
"status" : "yellow",
"indices" : {
"count" : 7,
"shards" : {
"total" : 7,
"primaries" : 7,
"replication" : 0.0,
"index" : {
"shards" : {
"min" : 1,
"max" : 1,
"avg" : 1.0
},
"primaries" : {
"min" : 1,
"max" : 1,
"avg" : 1.0
},
"replication" : {
"min" : 0.0,
"max" : 0.0,
"avg" : 0.0
}
………………………………………….クラスタ更新設定
このAPIを使用すると、「settings」キーワードを使用してクラスターの設定を更新できます。 設定には2つのタイプがあります-永続的（再起動全体に適用）と一時的（完全なクラスタ再起動に耐えられない）。
ノード統計
このAPIは、クラスターのもう1つのノードの統計を取得するために使用されます。 ノードの統計は、クラスターとほぼ同じです。
GET/_nodes/stats上記のコードを実行すると、次のように応答が得られます-
{
"_nodes" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"cluster_name" : "elasticsearch",
"nodes" : {
"FKH-5blYTJmff2rJ_lQOCg" : {
"timestamp" : 1556437348653,
"name" : "ubuntu",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"roles" : [
"master",
"data",
"ingest"
],
"attributes" : {
"ml.machine_memory" : "4112797696",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20"
},
………………………………………………………….ノードhot_threads
このAPIは、クラスター内の各ノードの現在のホットスレッドに関する情報を取得するのに役立ちます。
GET/_nodes/hot_threads上記のコードを実行すると、次のように応答が得られます-
:::{ubuntu}{FKH-5blYTJmff2rJ_lQOCg}{426kTGpITGixhEzaM5Qyg}{127.0.0.1}{127.0.0.1:9300}{ml.machine_memory=4112797696,
xpack.installed=true, ml.max_open_jobs=20}
Hot threads at 2019-04-28T07:43:58.265Z, interval=500ms, busiestThreads=3,
ignoreIdleThreads=true:Elasticsearch-DSLのクエリ
Elasticsearchでは、JSONに基づくクエリを使用して検索が実行されます。 クエリは2つの句で構成されています-
- Leaf Query Clauses -これらの句は、特定のフィールドで特定の値を検索する一致、用語、または範囲です。
- 複合クエリ句-これらのクエリは、目的の情報を抽出するためのリーフクエリ句と他の複合クエリの組み合わせです。
Elasticsearchは多数のクエリをサポートしています。 クエリはクエリキーワードで始まり、その後、JSONオブジェクトの形式で内部に条件とフィルターがあります。 さまざまな種類のクエリについては、以下で説明しています。
すべてに一致するクエリ
これは最も基本的なクエリです。すべてのコンテンツを返し、すべてのオブジェクトに対して1.0のスコアを返します。
POST/schools/_search
{
"query":{
"match_all":{}
}
}上記のコードを実行すると、次の結果が得られます-
{
"took" : 7,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "5",
"_score" : 1.0,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
},
{
"_index" : "schools",
"_type" : "school",
"_id" : "4",
"_score" : 1.0,
"_source" : {
"name" : "City Best School",
"description" : "ICSE",
"street" : "West End",
"city" : "Meerut",
"state" : "UP",
"zip" : "250002",
"location" : [
28.9926174,
77.692485
],
"fees" : 3500,
"tags" : [
"fully computerized"
],
"rating" : "4.5"
}
}
]
}
}全文クエリ
これらのクエリは、章やニュース記事などのテキスト全体を検索するために使用されます。 このクエリは、その特定のインデックスまたはドキュメントに関連付けられているアナライザーに従って機能します。 このセクションでは、さまざまなタイプの全文クエリについて説明します。
一致クエリ
このクエリは、テキストまたはフレーズを1つ以上のフィールドの値と一致させます。
POST/schools*/_search
{
"query":{
"match" : {
"rating":"4.5"
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 44,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.47000363,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "4",
"_score" : 0.47000363,
"_source" : {
"name" : "City Best School",
"description" : "ICSE",
"street" : "West End",
"city" : "Meerut",
"state" : "UP",
"zip" : "250002",
"location" : [
28.9926174,
77.692485
],
"fees" : 3500,
"tags" : [
"fully computerized"
],
"rating" : "4.5"
}
}
]
}
}マルチマッチクエリ
このクエリは、複数のフィールドを持つテキストまたはフレーズと一致します。
POST/schools*/_search
{
"query":{
"multi_match" : {
"query": "paprola",
"fields": [ "city", "state" ]
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 12,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.9808292,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "5",
"_score" : 0.9808292,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
"fees" : 2200,
"tags" : [
"Senior Secondary",
"beautiful campus"
],
"rating" : "3.3"
}
}
]
}
}クエリ文字列クエリ
このクエリは、クエリパーサーとquery_stringキーワードを使用します。
POST/schools*/_search
{
"query":{
"query_string":{
"query":"beautiful"
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 60,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
………………………………….用語レベルのクエリ
これらのクエリは、主に数値、日付、列挙などの構造化データを処理します。
POST/schools*/_search
{
"query":{
"term":{"zip":"176115"}
}
}上記のコードを実行すると、次のように応答が得られます-
……………………………..
hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "5",
"_score" : 0.9808292,
"_source" : {
"name" : "Central School",
"description" : "CBSE Affiliation",
"street" : "Nagan",
"city" : "paprola",
"state" : "HP",
"zip" : "176115",
"location" : [
31.8955385,
76.8380405
],
}
}
]
…………………………………………..範囲クエリ
このクエリは、指定された値の範囲内の値を持つオブジェクトを見つけるために使用されます。 このため、次のような演算子を使用する必要があります-
- gte -等しい
- gt -より大きい
- lte -より小さい
- lt -より小さい
たとえば、以下のコードを観察します-
POST/schools*/_search
{
"query":{
"range":{
"rating":{
"gte":3.5
}
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 24,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "schools",
"_type" : "school",
"_id" : "4",
"_score" : 1.0,
"_source" : {
"name" : "City Best School",
"description" : "ICSE",
"street" : "West End",
"city" : "Meerut",
"state" : "UP",
"zip" : "250002",
"location" : [
28.9926174,
77.692485
],
"fees" : 3500,
"tags" : [
"fully computerized"
],
"rating" : "4.5"
}
}
]
}
}次のような他のタイプの用語レベルのクエリも存在します-
- Exists query -特定のフィールドにnull以外の値がある場合。
- Missing query -これは、存在するクエリとはまったく反対です。このクエリは、特定のフィールドまたはnull値を持つフィールドのないオブジェクトを検索します。
- ワイルドカードまたは正規表現クエリ-このクエリは正規表現を使用してオブジェクトのパターンを検索します。
複合クエリ
これらのクエリは、and、or、not、異なるインデックス、または関数呼び出しなどのブール演算子を使用して互いにマージされた異なるクエリのコレクションです。
POST/schools/_search
{
"query": {
"bool" : {
"must" : {
"term" : { "state" : "UP" }
},
"filter": {
"term" : { "fees" : "2200" }
},
"minimum_should_match" : 1,
"boost" : 1.0
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 6,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 0,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
}
}ジオクエリ
これらのクエリは、ジオロケーションとジオポイントを処理します。 これらのクエリは、学校など、あらゆる場所に近い地理的オブジェクトを見つけるのに役立ちます。 ジオポイントデータタイプを使用する必要があります。
PUT/geo_example
{
"mappings": {
"properties": {
"location": {
"type": "geo_shape"
}
}
}
}上記のコードを実行すると、次のように応答が得られます-
{ "acknowledged" : true,
"shards_acknowledged" : true,
"index" : "geo_example"
}次に、上記で作成したインデックスにデータを投稿します。
POST/geo_example/_doc?refresh
{
"name": "Chapter One, London, UK",
"location": {
"type": "point",
"coordinates": [11.660544, 57.800286]
}
}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 1,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
"_index" : "geo_example",
"_type" : "_doc",
"_id" : "hASWZ2oBbkdGzVfiXHKD",
"_score" : 1.0,
"_source" : {
"name" : "Chapter One, London, UK",
"location" : {
"type" : "point",
"coordinates" : [
11.660544,
57.800286
]
}
}
}
}Elasticsearch-マッピング
マッピングは、インデックスに保存されているドキュメントの概要です。 動的に追加されるフィールドのマッピングを制御するために、geo_pointやstringなどのデータ型と、ドキュメントおよびルールに存在するフィールドの形式を定義します。
PUT bankaccountdetails
{
"mappings":{
"properties":{
"name": { "type":"text"}, "date":{ "type":"date"},
"balance":{ "type":"double"}, "liability":{ "type":"double"}
}
}
}上記のコードを実行すると、次のように応答が得られます-
{
"acknowledged" : true,
"shards_acknowledged" : true,
"index" : "bankaccountdetails"
}フィールドデータ型
Elasticsearchは、ドキュメント内のフィールドに対してさまざまなデータ型をサポートしています。 Elasticsearchでフィールドを保存するために使用されるデータ型については、ここで詳しく説明します。
コアデータタイプ
これらは、テキスト、キーワード、日付、long、double、boolean、またはipなどの基本的なデータ型であり、ほとんどすべてのシステムでサポートされています。
複雑なデータ型
これらのデータ型は、コアデータ型の組み合わせです。 これらには、配列、JSONオブジェクト、ネストされたデータ型が含まれます。 ネストされたデータ型の例を以下に示します＆minus
POST/tabletennis/_doc/1
{
"group" : "players",
"user" : [
{
"first" : "dave", "last" : "jones"
},
{
"first" : "kevin", "last" : "morris"
}
]
}上記のコードを実行すると、次のように応答が得られます-
{
"_index" : "tabletennis",
"_type" : "_doc",
"_id" : "1",
_version" : 2,
"result" : "updated",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1
}別のサンプルコードは以下に示されています-
POST/accountdetails/_doc/1
{
"from_acc":"7056443341", "to_acc":"7032460534",
"date":"11/1/2016", "amount":10000
}上記のコードを実行すると、次のように応答が得られます-
{ "_index" : "accountdetails",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1
}次のコマンドを使用して、上記のドキュメントを確認できます-
GET/accountdetails/_mappings?include_type_name=falseマッピングタイプの削除
Elasticsearch 7.0.0以降で作成されたインデックスは、_default_マッピングを受け入れなくなりました。 6.xで作成されたインデックスは、Elasticsearch 6.xで以前と同様に機能し続けます。 タイプは、7.0のAPIで非推奨になりました。
Elasticsearch-分析
検索操作中にクエリが処理されると、インデックスのコンテンツが分析モジュールによって分析されます。 このモジュールは、アナライザー、トークナイザー、トークンフィルター、および文字フィルターで構成されています。 アナライザーが定義されていない場合、デフォルトでは、組み込みのアナライザー、トークン、フィルター、およびトークナイザーが分析モジュールに登録されます。
次の例では、他のアナライザーが指定されていない場合に使用される標準アナライザーを使用します。 文法に基づいて文を分析し、文で使用される単語を生成します。
POST _analyze
{
"analyzer": "standard",
"text": "Today's weather is beautiful"
}上記のコードを実行すると、次のように応答が得られます-
{
"tokens" : [
{
"token" : "today's",
"start_offset" : 0,
"end_offset" : 7,
"type" : "",
"position" : 0
},
{
"token" : "weather",
"start_offset" : 8,
"end_offset" : 15,
"type" : "",
"position" : 1
},
{
"token" : "is",
"start_offset" : 16,
"end_offset" : 18,
"type" : "",
"position" : 2
},
{
"token" : "beautiful",
"start_offset" : 19,
"end_offset" : 28,
"type" : "",
"position" : 3
}
]
}標準アナライザーの構成
さまざまなパラメーターを使用して標準アナライザーを構成し、カスタム要件を取得できます。
次の例では、max_token_lengthが5になるように標準アナライザーを構成します。
このために、最初にmax_length_tokenパラメーターを持つアナライザーでインデックスを作成します。
PUT index_4_analysis
{
"settings": {
"analysis": {
"analyzer": {
"my_english_analyzer": {
"type": "standard",
"max_token_length": 5,
"stopwords": "_english_"
}
}
}
}
}次に、アナライザーに次のようなテキストを適用します。 トークンの先頭には2つのスペースがあり、末尾には2つのスペースがあるため、トークンは表示されないことに注意してください。 「is」という単語の場合、先頭にスペースがあり、末尾にスペースがあります。 それらすべてを取得すると、スペース付きの4文字になりますが、それは単語になりません。 カウント対象の単語にするために、少なくとも先頭または末尾にスペース以外の文字が必要です。
POST index_4_analysis/_analyze
{
"analyzer": "my_english_analyzer",
"text": "Today's weather is beautiful"
}上記のコードを実行すると、次のように応答が得られます-
{
"tokens" : [
{
"token" : "today",
"start_offset" : 0,
"end_offset" : 5,
"type" : "",
"position" : 0
},
{
"token" : "s",
"start_offset" : 6,
"end_offset" : 7,
"type" : "",
"position" : 1
},
{
"token" : "weath",
"start_offset" : 8,
"end_offset" : 13,
"type" : "",
"position" : 2
},
{
"token" : "er",
"start_offset" : 13,
"end_offset" : 15,
"type" : "",
"position" : 3
},
{
"token" : "beaut",
"start_offset" : 19,
"end_offset" : 24,
"type" : "",
"position" : 5
},
{
"token" : "iful",
"start_offset" : 24,
"end_offset" : 28,
"type" : "",
"position" : 6
}
]
}さまざまなアナライザーのリストとその説明は、以下に示す表に記載されています-
| S.No | Analyzer & Description |
|---|---|
| 1 |
Standard analyzer (standard) このアナライザーには、ストップワードとmax_token_length設定を設定できます。 デフォルトでは、ストップワードリストは空で、max_token_lengthは255です。 |
| 2 |
Simple analyzer (simple) このアナライザーは、小文字のトークナイザーで構成されています。 |
| 3 |
Whitespace analyzer (whitespace) このアナライザーは、空白トークナイザーで構成されています。 |
| 4 |
Stop analyzer (stop) stopwordsおよびstopwords_pathを構成できます。 デフォルトでは、ストップワードは英語のストップワードに初期化され、stopwords_pathにはストップワードを含むテキストファイルへのパスが含まれます。 |
トークナイザー
トークナイザーは、Elasticsearchのテキストからトークンを生成するために使用されます。 テキストは、空白またはその他の句読点を考慮してトークンに分割できます。 Elasticsearchには、カスタムアナライザーで使用できる組み込みのトークナイザーがたくさんあります。
文字ではない文字に出会うたびにテキストを用語に分割するトークナイザーの例は、すべての用語を小文字にします。
POST _analyze
{
"tokenizer": "lowercase",
"text": "It Was a Beautiful Weather 5 Days ago."
}上記のコードを実行すると、次のように応答が得られます-
{
"tokens" : [
{
"token" : "it",
"start_offset" : 0,
"end_offset" : 2,
"type" : "word",
"position" : 0
},
{
"token" : "was",
"start_offset" : 3,
"end_offset" : 6,
"type" : "word",
"position" : 1
},
{
"token" : "a",
"start_offset" : 7,
"end_offset" : 8,
"type" : "word",
"position" : 2
},
{
"token" : "beautiful",
"start_offset" : 9,
"end_offset" : 18,
"type" : "word",
"position" : 3
},
{
"token" : "weather",
"start_offset" : 19,
"end_offset" : 26,
"type" : "word",
"position" : 4
},
{
"token" : "days",
"start_offset" : 29,
"end_offset" : 33,
"type" : "word",
"position" : 5
},
{
"token" : "ago",
"start_offset" : 34,
"end_offset" : 37,
"type" : "word",
"position" : 6
}
]
}トークナイザーのリストとその説明は、以下の表に示されています-
| S.No | Tokenizer & Description |
|---|---|
| 1 |
Standard tokenizer (standard) これは、文法ベースのトークナイザーに基づいており、このトークナイザー用にmax_token_lengthを構成できます。 |
| 2 |
Edge NGram tokenizer (edgeNGram) min_gram、max_gram、token_charsなどの設定をこのトークナイザーに設定できます。 |
| 3 |
Keyword tokenizer (keyword) これにより、入力全体が出力として生成され、buffer_sizeを設定できます。 |
| 4 |
Letter tokenizer (letter) これは、文字以外が見つかるまで単語全体をキャプチャします。 |
Elasticsearch-モジュール
Elasticsearchは、その機能を担う多数のモジュールで構成されています。 これらのモジュールには、次の2種類の設定があります-
- 静的設定-これらの設定は、Elasticsearchを開始する前にconfig（elasticsearch.yml）ファイルで設定する必要があります。 これらの設定による変更を反映するには、クラスター内のすべての関係ノードを更新する必要があります。
- 動的設定-これらの設定はライブElasticsearchで設定できます。
この章の以降のセクションで、Elasticsearchのさまざまなモジュールについて説明します。
クラスタレベルのルーティングとシャード割り当て
クラスターレベルの設定により、異なるノードへのシャードの割り当てとクラスターの再分散のためのシャードの再割り当てが決定されます。 これらは、シャードの割り当てを制御する次の設定です。
クラスタレベルのシャード割り当て
設定
可能な値
説明
cluster.routing.allocation.enable
all
このデフォルト値により、すべての種類のシャードにシャードを割り当てることができます。
原色
これにより、プライマリシャードにのみシャードの割り当てが許可されます。
new_primaries
これにより、新しいインデックスのプライマリシャードにのみシャードを割り当てることができます。
none
これは、シャードの割り当てを許可しません。
cluster.routing.allocation .node_concurrent_recoveries
数値（デフォルトでは2）
これにより、同時シャード回復の数が制限されます。
cluster.routing.allocation .node_initial_primaries_recoveries
数値（デフォルトでは4）
これにより、並列初期プライマリリカバリの数が制限されます。
cluster.routing.allocation .same_shard.host
ブール値（デフォルトではfalse）
これにより、同じ物理ノード内の同じシャードの複数のレプリカの割り当てが制限されます。
indexs.recovery.concurrent _streams
数値（デフォルトでは3）
これは、ピアシャードからのシャードリカバリ時に、ノードごとのオープンネットワークストリームの数を制御します。
indexs.recovery.concurrent _small_file_streams
数値（デフォルトでは2）
これにより、断片回復時のサイズが5 MB未満の小さなファイルのノードあたりのオープンストリーム数が制御されます。
cluster.routing.rebalance.enable
all
このデフォルト値により、すべての種類のシャードのバランスを取ることができます。
原色
これにより、プライマリシャードに対してのみシャードバランシングが可能になります。
レプリカ
これにより、レプリカシャードに対してのみシャードバランシングが可能になります。
none
これは、あらゆる種類のシャードバランシングを許可しません。
cluster.routing.allocation .allow_rebalance
常に
このデフォルト値は常にリバランスを許可します。
indexs_primaries _active
これにより、クラスター内のすべてのプライマリシャードが割り当てられたときにリバランスが可能になります。
Indices_all_active
これにより、すべてのプライマリシャードとレプリカシャードが割り当てられたときにリバランスが可能になります。
cluster.routing.allocation.cluster _concurrent_rebalance
数値（デフォルトでは2）
これにより、クラスター内の同時シャードバランシングの数が制限されます。
cluster.routing.allocation .balance.shard
浮動小数点値（デフォルトでは0.45f）
これにより、すべてのノードに割り当てられたシャードの重み係数が定義されます。
cluster.routing.allocation .balance.index
浮動小数点値（デフォルトでは0.55f）
これは、特定のノードに割り当てられたインデックスごとの断片数の比率を定義します。
cluster.routing.allocation .balance.threshold
非負の浮動小数点値（デフォルトでは1.0f）
これは、実行する必要がある操作の最小最適化値です。
ディスクベースのシャード割り当て
| Setting | Possible value | Description |
|---|---|---|
| cluster.routing.allocation.disk.threshold_enabled | Boolean value (by default true) | This enables and disables disk allocation decider. |
| cluster.routing.allocation.disk.watermark.low | String value(by default 85%) | This denotes maximum usage of disk; after this point, no other shard can be allocated to that disk. |
| cluster.routing.allocation.disk.watermark.high | String value (by default 90%) | This denotes the maximum usage at the time of allocation; if this point is reached at the time of allocation, then Elasticsearch will allocate that shard to another disk. |
| cluster.info.update.interval | String value (by default 30s) | This is the interval between disk usages checkups. |
| cluster.routing.allocation.disk.include_relocations | Boolean value (by default true) | This decides whether to consider the shards currently being allocated, while calculating disk usage. |
発見
このモジュールは、クラスターがその中のすべてのノードの状態を検出および維持するのに役立ちます。 クラスターの状態は、ノードが追加または削除されると変化します。 クラスター名の設定は、異なるクラスター間の論理的な違いを作成するために使用されます。 クラウドベンダーが提供するAPIを使用するのに役立つモジュールがいくつかあり、それらは以下のとおりです-
- Azureディスカバリー
- EC2ディスカバリー
- Googleコンピューティングエンジンの検出 *禅の発見
ゲートウェイ
このモジュールは、クラスターの完全な再起動にわたってクラスターの状態と断片データを維持します。 以下は、このモジュールの静的設定です-
| Setting | Possible value | Description |
|---|---|---|
| gateway.expected_nodes | numeric value (by default 0) | The number of nodes that are expected to be in the cluster for the recovery of local shards. |
| gateway.expected_master_nodes | numeric value (by default 0) | The number of master nodes that are expected to be in the cluster before start recovery. |
| gateway.expected_data_nodes | numeric value (by default 0) | The number of data nodes expected in the cluster before start recovery. |
| gateway.recover_after_time | String value (by default 5m) | This is the interval between disk usages checkups. |
| cluster.routing.allocation. disk.include_relocations | Boolean value (by default true) |
This specifies the time for which the recovery process will wait to start regardless of the number of nodes joined in the cluster. gateway.recover_ after_nodes gateway.recover_after_master_nodes gateway.recover_after_data_nodes |
HTTP
このモジュールは、HTTPクライアントとElasticsearch API間の通信を管理します。 このモジュールを無効にするには、http.enabledの値をfalseに変更します。
以下は、このモジュールを制御するための設定です（elasticsearch.ymlで設定されています）-
| S.No | Setting & Description |
|---|---|
| 1 |
これはElasticsearchにアクセスするためのポートで、9200〜9300の範囲です。 |
| 2 |
http.publish_port このポートはhttpクライアント用であり、ファイアウォールの場合にも役立ちます。 |
| 3 |
http.bind_host これは、httpサービスのホストアドレスです。 |
| 4 |
http.publish_host これは、httpクライアントのホストアドレスです。 |
| 5 |
http.max_content_length これは、httpリクエストのコンテンツの最大サイズです。 デフォルト値は100mbです。 |
| 6 |
http.max_initial_line_length これはURLの最大サイズであり、デフォルト値は4kbです。 |
| 7 |
http.max_header_size これは、httpヘッダーの最大サイズであり、デフォルト値は8kbです。 |
| 8 |
http.compression これにより、圧縮のサポートが有効または無効になり、デフォルト値はfalseです。 |
| 9 |
http.pipelinig これにより、HTTPパイプラインが有効または無効になります。 |
| 10 |
http.pipelining.max_events これにより、HTTP要求を閉じる前にキューに入れるイベントの数が制限されます。 |
指標
このモジュールは、すべてのインデックスに対してグローバルに設定される設定を維持します。 以下の設定は、主にメモリ使用量に関連しています-
サーキットブレーカー
これは、操作がOutOfMemroyErrorを引き起こさないようにするために使用されます。 この設定は、主にJVMヒープサイズを制限します。 たとえば、indexes.breaker.total.limit設定は、デフォルトでJVMヒープの70％に設定されます。
フィールドデータキャッシュ
これは、主にフィールドで集計するときに使用されます。 割り当てるのに十分なメモリを確保することをお勧めします。 フィールドデータキャッシュに使用されるメモリ量は、indexes.fielddata.cache.size設定を使用して制御できます。
ノードクエリキャッシュ
このメモリは、クエリ結果をキャッシュするために使用されます。 このキャッシュは、最長時間未使用（LRU）エビクションポリシーを使用します。 Indices.queries.cahce.size設定は、このキャッシュのメモリサイズを制御します。
インデックスバッファ
このバッファは、新しく作成されたドキュメントをインデックスに保存し、バッファがいっぱいになるとそれらをフラッシュします。 index.memory.index_buffer_sizeのように設定すると、このバッファーに割り当てられるヒープの量が制御されます。
シャードリクエストキャッシュ
このキャッシュは、すべてのシャードのローカル検索データを保存するために使用されます。 キャッシュは、インデックスの作成中に有効にするか、URLパラメーターを送信して無効にすることができます。
Disable cache - ?request_cache = true
Enable cache "index.requests.cache.enable": true指数回復
回復プロセス中にリソースを制御します。 以下は設定です-
| Setting | Default value |
|---|---|
| indices.recovery.concurrent_streams | 3 |
| indices.recovery.concurrent_small_file_streams | 2 |
| indices.recovery.file_chunk_size | 512kb |
| indices.recovery.translog_ops | 1000 |
| indices.recovery.translog_size | 512kb |
| indices.recovery.compress | true |
| indices.recovery.max_bytes_per_sec | 40mb |
TTL間隔
存続時間（TTL）間隔は、ドキュメントが削除されるまでの時間を定義します。 以下は、このプロセスを制御するための動的設定です-
| Setting | Default value |
|---|---|
| indices.ttl.interval | 60s |
| indices.ttl.bulk_size | 1000 |
Node
各ノードには、データノードであるかどうかのオプションがあります。 node.data 設定を変更することにより、このプロパティを変更できます。 値を false に設定すると、ノードがデータノードではないことを定義します。
Elasticsearch-インデックスモジュール
これらは、すべてのインデックスに対して作成され、インデックスの設定と動作を制御するモジュールです。 たとえば、インデックスが使用できるシャードの数や、プライマリシャードがそのインデックスに対して保持できるレプリカの数などです。 インデックス設定には2種類あります-
- 静的-これらは、インデックス作成時または閉じたインデックスでのみ設定できます。
- 動的-これらはライブインデックスで変更できます。
静的インデックス設定
次の表は、静的インデックス設定のリストを示しています-
| Setting | Possible value | Description |
|---|---|---|
| index.number_of_shards | Defaults to 5, Maximum 1024 | The number of primary shards that an index should have. |
| index.shard.check_on_startup | Defaults to false. Can be True | Whether or not shards should be checked for corruption before opening. |
| index.codec | LZ4 compression. | Type of compression used to store data. |
| index.routing_partition_size | 1 | The number of shards a custom routing value can go to. |
| index.load_fixed_bitset_filters_eagerly | false | Indicates whether cached filters are pre-loaded for nested queries |
動的インデックス設定
次の表は、動的インデックス設定のリストを示しています-
| Setting | Possible value | Description |
|---|---|---|
| index.number_of_replicas | Defaults to 1 | The number of replicas each primary shard has. |
| index.auto_expand_replicas | A dash delimited lower and upper bound (0-5) | Auto-expand the number of replicas based on the number of data nodes in the cluster. |
| index.search.idle.after | 30seconds | How long a shard cannot receive a search or get request until it’s considered search idle. |
| index.refresh_interval | 1 second | How often to perform a refresh operation, which makes recent changes to the index visible to search. |
Elasticsearch-IngestNode
| index.blocks.read_only | 1 true/false | Set to true to make the index and index metadata read only, false to allow writes and metadata changes. |
インデックスを作成する前にドキュメントを変換する必要がある場合があります。 たとえば、ドキュメントからフィールドを削除するか、フィールドの名前を変更してからインデックスを作成します。 これは、取り込みノードによって処理されます。
クラスター内のすべてのノードには取り込み機能がありますが、特定のノードのみが処理するようにカスタマイズすることもできます。
関与するステップ
取り込みノードの動作に関係する2つのステップがあります-
- パイプラインを作成する
- ドキュメントを作成する
パイプラインを作成する
以下に示すように、最初にプロセッサを含むパイプラインを作成し、次にパイプラインを実行します-
PUT _ingest/pipeline/int-converter
{
"description": "converts the content of the seq field to an integer",
"processors" : [
{
"convert" : {
"field" : "seq",
"type": "integer"
}
}
]
}上記のコードを実行すると、次の結果が得られます-
{
"acknowledged" : true
}ドキュメントを作成する
次に、パイプラインコンバーターを使用してドキュメントを作成します。
PUT/logs/_doc/1?pipeline=int-converter
{
"seq":"21",
"name":"finddevguides",
"Addrs":"Hyderabad"
}上記のコードを実行すると、次のように応答が得られます-
{
"_index" : "logs",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}次に、以下に示すようにGETコマンドを使用して、上記で作成したドキュメントを検索します-
GET/logs/_doc/1上記のコードを実行すると、次の結果が得られます-
{
"_index" : "logs",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"_seq_no" : 0,
"_primary_term" : 1,
"found" : true,
"_source" : {
"Addrs" : "Hyderabad",
"name" : "finddevguides",
"seq" : 21
}
}上記のように、21が整数になっていることがわかります。
パイプラインなし
次に、パイプラインを使用せずにドキュメントを作成します。
PUT/logs/_doc/2
{
"seq":"11",
"name":"Tutorix",
"Addrs":"Secunderabad"
}
GET/logs/_doc/2上記のコードを実行すると、次の結果が得られます-
{
"_index" : "logs",
"_type" : "_doc",
"_id" : "2",
"_version" : 1,
"_seq_no" : 1,
"_primary_term" : 1,
"found" : true,
"_source" : {
"seq" : "11",
"name" : "Tutorix",
"Addrs" : "Secunderabad"
}
}上記のように、11はパイプラインが使用されていない文字列であることがわかります。
Elasticsearch-インデックスライフサイクルの管理
インデックスライフサイクルの管理には、シャードサイズやパフォーマンス要件などの要因に基づいて管理アクションを実行することが含まれます。 インデックスライフサイクル管理（ILM）APIを使用すると、インデックスを長期にわたって管理する方法を自動化できます。
この章では、ILM APIとその使用法のリストを示します。
ポリシー管理API
| API Name | Purpose | Example |
|---|---|---|
| Create lifecycle policy. | Creates a lifecycle policy. If the specified policy exists, the policy is replaced and the policy version is incremented. | PUT_ilm/policy/policy_id |
| Get lifecycle policy. | Returns the specified policy definition. Includes the policy version and last modified date. If no policy is specified, returns all defined policies. | GET_ilm/policy/policy_id |
| Delete lifecycle policy | Deletes the specified lifecycle policy definition. You cannot delete policies that are currently in use. If the policy is being used to manage any indices, the request fails and returns an error. | DELETE_ilm/policy/policy_id |
インデックス管理API
| API Name | Purpose | Example |
|---|---|---|
| Move to lifecycle step API. | Manually moves an index into the specified step and executes that step. | POST_ilm/move/index |
| Retry policy. | Sets the policy back to the step where the error occurred and executes the step. | POST index/_ilm/retry |
| Remove policy from index API edit. | Removes the assigned lifecycle policy and stops managing the specified index. If an index pattern is specified, removes the assigned policies from all matching indices. | POST index/_ilm/remove |
運用管理API
| API Name | Purpose | Example |
|---|---|---|
| Get index lifecycle management status API. | Returns the status of the ILM plugin. The operation_mode field in the response shows one of three states: STARTED, STOPPING, or STOPPED. | GET/_ilm/status |
| Start index lifecycle management API. | Starts the ILM plugin if it is currently stopped. ILM is started automatically when the cluster is formed. | POST/_ilm/start |
| Stop index lifecycle management API. | Halts all lifecycle management operations and stops the ILM plugin. This is useful when you are performing maintenance on the cluster and need to prevent ILM from performing any actions on your indices. | POST/_ilm/stop |
| Explain lifecycle API. | Retrieves information about the index’s current lifecycle state, such as the currently executing phase, action, and step. Shows when the index entered each one, the definition of the running phase, and information about any failures. | GET index/_ilm/explain |
Elasticsearch-SQLアクセス
SQLに似たクエリをElasticsearchに対してリアルタイムで実行できるようにするコンポーネントです。 Elasticsearch SQLは、SQLとElasticsearchの両方を理解し、Elasticsearch機能を活用して大規模なリアルタイムでのデータの読み取りと処理を容易にするトランスレーターと考えることができます。
Elasticsearch SQLの利点
- ネイティブ統合-基礎となるストレージに従って、関連するノードに対してすべてのクエリが効率的に実行されます。
- 外部部品なし-追加のハードウェア、プロセス、ランタイム、または Elasticsearchを照会するライブラリ。
- 軽量で効率的-SQLを受け入れて公開し、リアルタイムで適切な全文検索を可能にします。
例
PUT/schoollist/_bulk?refresh
{"index":{"_id": "CBSE"}}
{"name": "GleanDale", "Address": "JR. Court Lane", "start_date": "2011-06-02",
"student_count": 561}
{"index":{"_id": "ICSE"}}
{"name": "Top-Notch", "Address": "Gachibowli Main Road", "start_date": "1989-
05-26", "student_count": 482}
{"index":{"_id": "State Board"}}
{"name": "Sunshine", "Address": "Main Street", "start_date": "1965-06-01",
"student_count": 604}上記のコードを実行すると、次のように応答が得られます-
{
"took" : 277,
"errors" : false,
"items" : [
{
"index" : {
"_index" : "schoollist",
"_type" : "_doc",
"_id" : "CBSE",
"_version" : 1,
"result" : "created",
"forced_refresh" : true,
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1,
"status" : 201
}
},
{
"index" : {
"_index" : "schoollist",
"_type" : "_doc",
"_id" : "ICSE",
"_version" : 1,
"result" : "created",
"forced_refresh" : true,
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1,
"status" : 201
}
},
{
"index" : {
"_index" : "schoollist",
"_type" : "_doc",
"_id" : "State Board",
"_version" : 1,
"result" : "created",
"forced_refresh" : true,
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 2,
"_primary_term" : 1,
"status" : 201
}
}
]
}SQLクエリ
次の例は、SQLクエリをフレーム化する方法を示しています-
POST/_sql?format=txt
{
"query": "SELECT * FROM schoollist WHERE start_date < '2000-01-01'"
}上記のコードを実行すると、次のように応答が得られます-
Address | name | start_date | student_count
--------------------+---------------+------------------------+---------------
Gachibowli Main Road|Top-Notch |1989-05-26T00:00:00.000Z|482
Main Street |Sunshine |1965-06-01T00:00:00.000Z|604注-上記のSQLクエリを変更することにより、異なる結果セットを取得できます。
Elasticsearch-モニタリング
クラスターの状態を監視するために、監視機能は各ノードからメトリックを収集し、Elasticsearch Indicesに格納します。 Elasticsearchのモニタリングに関連するすべての設定は、各ノードのelasticsearch.ymlファイル、または可能であれば動的クラスター設定で設定する必要があります。
監視を開始するには、クラスタ設定を確認する必要があります。これは、次の方法で実行できます-
GET _cluster/settings
{
"persistent" : { },
"transient" : { }
}スタック内の各コンポーネントは、それ自体を監視し、それらのドキュメントをルーティングとインデックス作成（ストレージ）の両方のためにElasticsearch実稼働クラスターに転送します。 Elasticsearchのルーティングおよびインデックス作成プロセスは、コレクターおよびエクスポーターと呼ばれるものによって処理されます。
コレクター
コレクターは収集間隔ごとに1回実行され、ElasticsearchのパブリックAPIから監視対象として選択したデータを取得します。 データの収集が完了すると、データは一括してエクスポーターに渡され、監視クラスターに送信されます。
収集されるデータタイプごとに1つのコレクターのみがあります。 各コレクターは、ゼロ個以上の監視ドキュメントを作成できます。
輸出業者
エクスポーターは、Elastic Stackソースから収集されたデータを取得し、モニタリングクラスターにルーティングします。 複数のエクスポーターを構成することは可能ですが、一般的なデフォルトのセットアップでは単一のエクスポーターを使用します。 エクスポーターは、ノードレベルとクラスターレベルの両方で構成可能です。
Elasticsearchには2種類のエクスポーターがあります-
- local -このエクスポーターはデータを同じクラスターにルーティングします
- http -優先エクスポーター。HTTPを介してアクセス可能なサポートされているElasticsearchクラスターにデータをルーティングするために使用できます。
輸出業者は、モニタリングデータをルーティングする前に、特定のElasticsearchリソースをセットアップする必要があります。 これらのリソースには、テンプレートと取り込みパイプラインが含まれます
Elasticsearch-ロールアップデータ
ロールアップジョブは、インデックスパターンで指定されたインデックスのデータを要約し、それを新しいインデックスにロールする定期的なタスクです。 次の例では、異なるタイムスタンプを持つsensorという名前のインデックスを作成します。 次に、cronジョブを使用してこれらのインデックスから定期的にデータをロールアップするロールアップジョブを作成します。
PUT/sensor/_doc/1
{
"timestamp": 1516729294000,
"temperature": 200,
"voltage": 5.2,
"node": "a"
}上記のコードを実行すると、次の結果が得られます-
{
"_index" : "sensor",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}次に、他のドキュメントにも同様に2番目のドキュメントを追加します。
PUT/sensor-2018-01-01/_doc/2
{
"timestamp": 1413729294000,
"temperature": 201,
"voltage": 5.9,
"node": "a"
}ロールアップジョブを作成する
PUT _rollup/job/sensor
{
"index_pattern": "sensor-*",
"rollup_index": "sensor_rollup",
"cron": "*/30 * * * * ?",
"page_size" :1000,
"groups" : {
"date_histogram": {
"field": "timestamp",
"interval": "60m"
},
"terms": {
"fields": ["node"]
}
},
"metrics": [
{
"field": "temperature",
"metrics": ["min", "max", "sum"]
},
{
"field": "voltage",
"metrics": ["avg"]
}
]
}cronパラメーターは、ジョブをアクティブにするタイミングと頻度を制御します。 ロールアップジョブのcronスケジュールがトリガーされると、最後のアクティベーション後に中断したところからロールアップが開始されます
ジョブが実行され、データが処理されたら、DSLクエリを使用して検索を実行できます。
GET/sensor_rollup/_rollup_search
{
"size": 0,
"aggregations": {
"max_temperature": {
"max": {
"field": "temperature"
}
}
}
}Elasticsearch-凍結指数
頻繁に検索されるインデックスは、それらを再構築して効率的な検索を行うのに時間がかかるため、メモリに保持されます。 一方、めったにアクセスしないインデックスがあるかもしれません。 これらのインデックスはメモリを占有する必要はなく、必要に応じて再構築できます。 このようなインデックスは、凍結インデックスと呼ばれます。
Elasticsearchは、シャードが検索されるたびに、凍結インデックスの各シャードの一時的なデータ構造を構築し、検索が完了するとすぐにこれらのデータ構造を破棄します。 Elasticsearchはこれらの一時的なデータ構造をメモリに保持しないため、凍結されたインデックスは通常のインデックスよりもはるかに少ないヒープを消費します。 これにより、他の方法で可能になるよりもはるかに高いディスク/ヒープ比が可能になります。
凍結および凍結解除の例
次の例では、インデックスをフリーズおよびフリーズ解除します-
POST/index_name/_freeze
POST/index_name/_unfreeze凍結されたインデックスの検索は、ゆっくり実行されると予想されます。 凍結されたインデックスは、高い検索負荷を対象としていません。 同じ検索がミリ秒単位で完了し、インデックスが凍結されていない場合でも、凍結されたインデックスの検索が完了するまでに数秒または数分かかることがあります。
凍結インデックスの検索
ノードごとに同時にロードされる凍結インデックスの数は、search_throttledスレッドプール内のスレッドの数によって制限されます。デフォルトでは1です。 凍結インデックスを含めるには、クエリパラメータ-_ignore_throttled = false._を使用して検索リクエストを実行する必要があります
GET/index_name/_search?q=user:tpoint&ignore_throttled=false凍結指数の監視
凍結インデックスは、検索スロットルとメモリ効率の高いシャード実装を使用する通常のインデックスです。
GET/_cat/indices/index_name?v&h=i,sthElasticsearch-テスト
Elasticsearchはjarファイルを提供します。これは任意のJava IDEに追加でき、Elasticsearchに関連するコードをテストするために使用できます。 Elasticsearchが提供するフレームワークを使用して、さまざまなテストを実行できます。 この章では、これらのテストについて詳しく説明します-
- 単体テスト
- 統合テスト *無作為化試験
前提条件
テストを開始するには、Elasticsearchテストの依存関係をプログラムに追加する必要があります。 この目的のためにmavenを使用でき、pom.xmlに以下を追加できます。
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<version>2.1.0</version>
</dependency>EsSetupは初期化され、Elasticsearchノードを開始および停止し、インデックスを作成します。
EsSetup esSetup = new EsSetup();createIndexを指定したesSetup.execute（）関数はインデックスを作成します。設定、タイプ、データを指定する必要があります。
単体テスト
ユニットテストは、JUnitとElasticsearchテストフレームワークを使用して実行されます。 ノードとインデックスはElasticsearchクラスを使用して作成でき、テストメソッドではテストの実行に使用できます。 このテストには、ESTestCaseクラスとESTokenStreamTestCaseクラスが使用されます。
統合テスト
統合テストでは、クラスター内の複数のノードを使用します。 ESIntegTestCaseクラスは、このテストに使用されます。 テストケースの準備作業を簡単にするさまざまな方法があります。
| S.No | Method & Description |
|---|---|
| 1 |
クラスター内のすべてのインデックスが更新されます |
| 2 |
ensureGreen() 緑のヘルスクラスター状態を保証します |
| 3 |
ensureYellow() 黄色のヘルスクラスター状態を保証します |
| 4 |
createIndex(name) このメソッドに渡された名前でインデックスを作成します |
| 5 |
flush() クラスター内のすべてのインデックスがフラッシュされます |
| 6 |
flushAndRefresh() flush（）およびrefresh（） |
| 7 |
indexExists(name) 指定されたインデックスの存在を確認します |
| 8 |
clusterService() クラスタサービスのJavaクラスを返します |
| 9 |
cluster() テストクラスタクラスを返します |
クラスターメソッドのテスト
| S.No | Method & Description |
|---|---|
| 1 |
ensureAtLeastNumNodes(n) クラスター内のノードの最小数が指定された数以上であることを確認します。 |
| 2 |
ensureAtMostNumNodes(n) クラスター内の最大ノード数が指定された数以下になるようにします。 |
| 3 |
stopRandomNode() クラスター内のランダムノードを停止するには |
| 4 |
stopCurrentMasterNode() マスターノードを停止するには |
| 5 |
stopRandomNonMaster() マスターノードではないクラスター内のランダムノードを停止します。 |
| 6 |
buildNode() 新しいノードを作成する |
| 7 |
startNode(settings) 新しいノードを開始します |
| 8 |
nodeSettings() ノード設定を変更するには、このメソッドをオーバーライドします。 |
クライアントへのアクセス
クライアントは、クラスター内の異なるノードにアクセスし、何らかのアクションを実行するために使用されます。 ESIntegTestCase.client（）メソッドは、ランダムクライアントを取得するために使用されます。 Elasticsearchは、クライアントにアクセスする他のメソッドも提供し、これらのメソッドにはESIntegTestCase.internalCluster（）メソッドを使用してアクセスできます。
| S.No | Method & Description |
|---|---|
| 1 |
iterator() これにより、利用可能なすべてのクライアントにアクセスできます。 |
| 2 |
masterClient() これにより、マスターノードと通信しているクライアントが返されます。 |
| 3 |
nonMasterClient() これにより、マスターノードと通信していないクライアントが返されます。 |
| 4 |
clientNodeClient() これは、クライアントノードで現在稼働しているクライアントを返します。 |
無作為化試験
このテストは、すべての可能なデータでユーザーのコードをテストするために使用されるため、将来どのタイプのデータでもエラーが発生することはありません。 このテストを実行するには、ランダムデータが最適なオプションです。
ランダムデータの生成
このテストでは、RandomizedクラスはRandomizedTestによって提供されるインスタンスによってインスタンス化され、さまざまなタイプのデータを取得するための多くのメソッドを提供します。
| Method | Return value |
|---|---|
| getRandom() | Instance of random class |
| randomBoolean() | Random boolean |
| randomByte() | Random byte |
| randomShort() | Random short |
| randomInt() | Random integer |
| randomLong() | Random long |
| randomFloat() | Random float |
| randomDouble() | Random double |
| randomLocale() | Random locale |
| randomTimeZone() | Random time zone |
| randomFrom() | Random element from array |
アサーション
ElasticsearchAssertionsおよびElasticsearchGeoAssertionsクラスには、テスト時に一般的なチェックを実行するために使用されるアサーションが含まれています。 たとえば、ここで与えられたコードを観察します-
SearchResponse seearchResponse = client().prepareSearch();
assertHitCount(searchResponse, 6);
assertFirstHit(searchResponse, hasId("6"));
assertSearchHits(searchResponse, "1", "2", "3", "4",”5”,”6”);Elasticsearch-Kibanaダッシュボード
Kibanaダッシュボードは、視覚化と検索のコレクションです。 ダッシュボードのコンテンツを配置、サイズ変更、編集してから、ダッシュボードを保存して共有できます。 この章では、ダッシュボードを作成および編集する方法を説明します。
ダッシュボードの作成
Kibanaホームページから、以下に示すように、左側のコントロールバーからダッシュボードオプションを選択します。 これにより、新しいダッシュボードを作成するように求められます。
ダッシュボードに視覚化を追加するには、[追加]メニューを選択し、利用可能な事前に構築された視覚化から選択します。 リストから次の視覚化オプションを選択しました。
上記の視覚化を選択すると、次のようなダッシュボードが表示されます。 後でダッシュボードを追加および編集して、要素を変更し、新しい要素を追加できます。
要素の検査
視覚化パネルメニューを選択し、 Inspect を選択することにより、ダッシュボード要素を検査できます。 これにより、ダウンロード可能な要素の背後にあるデータが表示されます。
共有ダッシュボード
以下に示すように、共有メニューを選択し、ハイパーリンクを取得するオプションを選択して、ダッシュボードを共有できます-
Elasticsearch-フィールドによるフィルタリング
Kibanaホームページで利用可能な検出機能により、さまざまな角度からデータセットを探索できます。 選択したインデックスパターンのデータを検索およびフィルタリングできます。 データは通常、一定期間にわたる値の分布という形で利用できます。
eコマースデータのサンプルを調べるには、下の図に示すように、 Discover アイコンをクリックします。 これにより、チャートとともにデータが表示されます。
時間によるフィルタリング
特定の時間間隔でデータを除外するには、以下に示すように時間フィルターオプションを使用します。 デフォルトでは、フィルターは15分に設定されています。
フィールドによるフィルタリング
以下に示すように、 Add Filter オプションを使用して、データセットをフィールドでフィルタリングすることもできます。 ここで、1つ以上のフィールドを追加し、フィルターが適用された後に対応する結果を取得します。 この例では、 day_of_week フィールドを選択し、そのフィールドの演算子を is として、値を Sunday として選択します。
次に、上記のフィルター条件で[保存]をクリックします。 適用されたフィルター条件を含む結果セットを以下に示します。
Elasticsearch-データ表
データテーブルは、合成された集計の生データを表示するために使用される視覚化の一種です。 データテーブルを使用して表示されるさまざまな種類の集計があります。 データテーブルを作成するには、ここで詳しく説明する手順を実行する必要があります。
視覚化
Kibanaのホーム画面には、Elasticsearchに保存されているインデックスから視覚化と集計を作成できる視覚化オプション名があります。 次の画像はオプションを示しています。
データテーブルを選択
次に、使用可能なさまざまな視覚化オプションの中から[データテーブル]オプションを選択します。 オプションは次の画像に示されています＆miuns;
指標を選択
次に、データテーブルの視覚化の作成に必要なメトリックを選択します。 この選択により、使用する集計のタイプが決まります。 このためのeコマースデータセットから、以下に示す特定のフィールドを選択します。
データテーブルの上記の構成を実行すると、ここの画像に示すような結果が得られます-
Elasticsearch-地域マップ
地域マップは、地理マップ上のメトリックを示します。 さまざまな強度で異なる地理的領域に固定されたデータを見るのに役立ちます。 通常、濃い色合いは高い値を示し、明るい色合いは低い値を示します。
この視覚化を作成する手順は、次のように詳細に説明されています-
視覚化
このステップでは、Kibanaホーム画面の左側のバーにある視覚化ボタンに移動し、新しい視覚化を追加するオプションを選択します。
次の画面は、地域マップオプションの選択方法を示しています。
指標を選択してください
次の画面では、地域マップの作成に使用されるメトリックを選択するよう求められます。 ここでは、メトリックとして平均価格を選択し、視覚化の作成に使用されるバケットのフィールドとしてcountry_iso_codeを選択します。
以下の最終結果は、選択を適用した後の地域マップを示しています。 ラベルに記載されている色の濃淡とその値に注意してください。
Elasticsearch-円グラフ
円グラフは、最も単純で有名な視覚化ツールの1つです。 それぞれ異なる色の円のスライスとしてデータを表します。 ラベルとパーセンテージデータ値を円とともに表示できます。 円はドーナツの形を取ることもできます。
視覚化
Kibanaのホーム画面には、Elasticsearchに保存されているインデックスから視覚化と集計を作成できる視覚化オプションがあります。 新しいビジュアライゼーションを追加し、以下に示すオプションとして円グラフを選択します。
指標を選択してください
次の画面では、円グラフの作成に使用されるメトリックの選択を求められます。 ここでは、メトリックとして基本単価のカウントを選択し、ヒストグラムとしてバケット集約を選択します。 また、最小間隔は20として選択されます。 したがって、価格は20を範囲とする値のブロックとして表示されます。
以下の結果は、選択を適用した後の円グラフを示しています。 ラベルに記載されている色の濃淡とその値に注意してください。
円グラフのオプション
円グラフの下のオプションタブに移動すると、円グラフのデータ表示の配置だけでなく、外観を変更するためのさまざまな構成オプションが表示されます。 次の例では、円グラフはドーナツとして表示され、ラベルは上部に表示されます。
Elasticsearch-エリアおよび棒グラフ
面グラフは、折れ線グラフと軸の間の領域がいくつかの色で強調表示される折れ線グラフの拡張です。 棒グラフは、値の範囲に編成されたデータを表し、軸に対してプロットされます。 水平バーまたは垂直バーで構成できます。
この章では、Kibanaを使用して作成されたこれら3種類のグラフをすべて表示します。 前の章で説明したように、引き続きeコマースインデックスのデータを使用します。
エリアチャート
Kibanaのホーム画面には、Elasticsearchに保存されているインデックスから視覚化と集計を作成できる視覚化オプションがあります。 新しいビジュアライゼーションを追加し、下の画像に示されているオプションとして面グラフを選択します。
指標を選択してください
次の画面では、面グラフの作成に使用されるメトリックの選択を求められます。 ここでは、集計メトリックのタイプとして合計を選択します。 次に、メトリックとして使用するフィールドとしてtotal_quantityフィールドを選択します。 X軸で、order_dateフィールドを選択し、指定されたメトリックでシリーズをサイズ5に分割します。
上記の構成を実行すると、次の面グラフが出力として取得されます-
横棒グラフ
同様に、横棒グラフでは、Kibanaホーム画面から新しい視覚化を選択し、横棒のオプションを選択します。 次に、下の画像に示すようにメトリックを選択します。 ここでは、提出された名前付き製品数量の集計としてSumを選択します。 次に、フィールドオーダーの日付の日付ヒストグラムを持つバケットを選択します。
上記の構成を実行すると、次のように水平棒グラフが表示されます-
縦棒グラフ
縦棒グラフでは、Kibanaホーム画面から新しい視覚化を選択し、縦棒のオプションを選択します。 次に、下の画像に示すようにメトリックを選択します。
ここでは、製品数量というフィールドの集計としてSumを選択します。 次に、週ごとの間隔でフィールドオーダーの日付の日付ヒストグラムを持つバケットを選択します。
上記の構成を実行すると、以下に示すようにグラフが生成されます-
Elasticsearch-時系列
時系列は、特定の時系列でのデータのシーケンスの表現です。 たとえば、月の初日から最終日までの各日のデータ。 データポイント間の間隔は一定のままです。 時間コンポーネントを含むデータセットは、時系列として表すことができます。
この章では、サンプルのeコマースデータセットを使用し、各日の注文数のカウントをプロットして時系列を作成します。
指標を選択
最初に、時系列の作成に使用されるインデックスパターン、データフィールド、および間隔を選択します。 サンプルのeコマースデータセットから、フィールドとしてorder_dateを選択し、間隔として1dを選択します。 これらの選択には、[パネルオプション]タブを使用します。 また、このタブの他の値をデフォルトのままにして、時系列のデフォルトの色と形式を取得します。
*Data* タブで、集計オプションとしてcountを選択し、オプションとしてすべてをグループ化して、時系列チャートのラベルを付けます。結果
この構成の最終結果は次のようになります。 このグラフでは、 Month to Date の期間を使用していることに注意してください。 期間が異なると、結果も異なります。
Elasticsearch-タグクラウド
タグクラウドは、ほとんどが視覚的に魅力的な形式のキーワードとメタデータであるテキストを表します。 それらは異なる角度で配置され、異なる色とフォントサイズで表されます。 データ内の最も顕著な用語を見つけるのに役立ちます。 プロミネンスは、用語の頻度、タグの一意性などの1つまたは複数の要因によって、または特定の用語に付けられた重みに基づいて決定できます。 以下に、タグクラウドを作成する手順を示します。
視覚化
Kibanaのホーム画面には、Elasticsearchに保存されているインデックスから視覚化と集計を作成できる視覚化オプションがあります。 新しいビジュアライゼーションを追加することを選択し、以下に示すオプションとしてタグクラウドを選択します-
指標を選択してください
次の画面では、タグクラウドの作成に使用されるメトリックの選択を求められます。 ここでは、集計メトリックのタイプとしてカウントを選択します。 次に、タグとして使用するキーワードとしてproductnameフィールドを選択します。
ここに示す結果は、選択を適用した後の円グラフを示しています。 ラベルに記載されている色の濃淡とその値に注意してください。
タグクラウドオプション
タグクラウドの[オプション]タブに移動すると、タグクラウドのデータ表示の配置だけでなく、外観を変更するためのさまざまな構成オプションが表示されます。 次の例では、タグクラウドが表示され、タグは水平方向と垂直方向の両方に広がっています。
Elasticsearch-ヒートマップ
ヒートマップは、さまざまな色の濃淡がグラフのさまざまな領域を表す視覚化の一種です。 値は連続的に変化する可能性があるため、色のr色の濃淡は値とともに変化します。 連続的に変化するデータと離散データの両方を表すのに非常に便利です。
この章では、sample_data_flightsという名前のデータセットを使用してヒートマップチャートを作成します。 その中で、フライトの出発国と到着国という名前の変数を考慮し、カウントします。
Kibanaのホーム画面には、Elasticsearchに保存されているインデックスから視覚化と集計を作成できる視覚化オプションがあります。 新しいビジュアライゼーションを追加し、下に示すオプションとしてヒートマップを選択します＆mimus;
指標を選択してください
次の画面では、ヒートマップチャートの作成に使用されるメトリックの選択を求められます。 ここでは、集計メトリックのタイプとしてカウントを選択します。 次に、Y軸のバケットについて、フィールドOriginCountryの集計として用語を選択します。 X軸については、使用するフィールドとしてDestCountryと同じ集計を選択します。 どちらの場合も、バケットのサイズを5に選択します。
上記の構成を実行すると、ヒートマップチャートが次のように生成されます。
注-グラフが1年間のデータを収集して効果的なヒートマップチャートを生成できるように、日付範囲を今年とする必要があります。
Elasticsearch-キャンバス
CanvasアプリケーションはKibanaの一部であり、動的なマルチページおよびピクセル完璧なデータ表示を作成できます。 チャートやメトリックだけでなく、インフォグラフィックを作成する機能がユニークで魅力的です。 この章では、キャンバスのさまざまな機能と、キャンバスのワークパッドの使用方法について説明します。
キャンバスを開く
Kibanaのホームページに移動して、下の図に示されているオプションを選択します。 キャンバスのワークパッドのリストが開きます。 この調査では、eコマースの収益追跡を選択します。
ワークパッドの複製
調査で使用する [eCommerce] Revenue Tracking ワークパッドのクローンを作成します。 それを複製するには、このワークパッドの名前で行を強調表示し、下の図に示すように複製ボタンを使用します-
上記のクローンの結果として、 [eCommerce] Revenue Tracking – Copy という名前の新しいワークパッドが取得されます。これには、開始時に以下のインフォグラフィックが表示されます。
カテゴリごとの総売上高と収益を、素敵な写真とチャートとともに説明します。
ワークパッドの変更
右側のタブにあるオプションを使用して、ワークパッドのスタイルと図を変更できます。 ここでは、下図に示すように異なる色を選択することにより、ワークパッドの背景色を変更することを目指しています。 色の選択はすぐに有効になり、次のように結果が得られます-
Elasticsearch-ログUI
Kibanaは、さまざまなソースからのログデータの視覚化にも役立ちます。 ログは、インフラストラクチャの健全性、パフォーマンスニーズ、セキュリティ違反分析などの重要な分析ソースです。 Kibanaは、Webサーバーログ、elasticsearchログ、cloudwatchログなどのさまざまなログに接続できます。
Logstashログ
Kibanaでは、可視化のためにlogstashログに接続できます。 最初に、以下に示すようにKibanaホーム画面から[ログ]ボタンを選択します-
次に、「ソース構成の変更」オプションを選択します。これにより、Logstashをソースとして選択するオプションが表示されます。 以下の画面には、ログソースとして使用できる他のタイプのオプションも表示されます。
ライブログテーリングのデータをストリーミングしたり、ストリーミングを一時停止して履歴ログデータに集中したりできます。 ログをストリーミングしている場合、最新のログがコンソールの下部に表示されます。
詳細については、リンク：/logstash/index [Logstash]チュートリアルを参照してください。
