第 3 章 Elasticsearch の基本機能
バージョン 8.X をベースに、Kibana ソフトウェアによる基本的な操作を説明します。
3.1 インデックス操作
3.1.1 インデックスの作成
ES ソフトウェアのインデックスは、MySQL のテーブルの概念にたとえることができ、インデックスの作成はテーブルの作成と似ています。
クエリが完了すると、Kibana は右側に応答結果とリクエストのステータスを返します。
繰り返しインデックスを作成すると、Kibana は右側にエラー情報を含む応答を返します。
3.1.2 指定したインデックスをクエリする
インデックス名に従って指定したインデックスをクエリし、見つかった場合はインデックスの詳細情報を返します。
クエリされたインデックスが存在しない場合は、エラー メッセージが返されます
3.1.3 すべてのインデックスのクエリ
便宜上、現在のすべてのインデックス データをクエリできます。ここでのリクエスト パスの _cat は表示を意味し、インデックスはインデックスを意味するため、全体的な意味は、
MySQL で
テーブルを表示するのと同じように、現在の ES サーバーのすべてのインデックスを表示することです
。ここでのクエリ結果は、インデックスのステータス情報を順番に表します。
3.1.4 インデックスの削除指定
した既存のインデックスを削除します
存在しないインデックスを削除するとエラーメッセージが返されます。
3.2 ドキュメントの操作ドキュメントは、ES ソフトウェアがデータを検索するための最小単位であり、あらかじめ定義されたパターンに依存しないため、テーブル内の JSON 型データ
の行にたとえることができます。
リレーショナル データベースでは、フィールドを使用する前に事前に定義する必要があることはわかっていますが、 Elasticsearch では、
フィールドは非常に柔軟であり、場合によってはフィールドを無視したり、新しいフィールドを動的に追加したりすることができます。
3.2.1 ドキュメントの作成
インデックスが作成されましたので、次にドキュメントを作成し、データを追加していきます。
ここでのドキュメントはリレーショナルデータベースのテーブルデータに相当し、追加されるデータ形式はJSON
形式ですが、ここではデータ一意性識別子が指定されていないため、PUTリクエストは利用できず、POSTリクエストのみ利用可能です。データ
はランダムな一意識別子によって生成されます。それ以外の場合は、エラー メッセージが返されます
データ作成時に一意の識別子が指定されている場合、リクエスト パラダイムは POST または PUT にすることができます
3.2.2 ドキュメントのクエリ.
一意の識別子に従って、対応するドキュメントをクエリできます
3.2.3ドキュメントを変更します。
ドキュメントの変更は、基本的に新規追加と同じです。ドキュメントは同じです。存在する場合は変更し、存在しない場合は追加します。 3.2.4 ドキュメントの削除 ドキュメントを削除しても、ドキュメントは削除されませ
ん
。ディスクをすぐに削除すると、削除済みとしてマークされるだけです (論理削除)。
3.2.5 すべてのドキュメントをクエリする
3.3 データ検索
デモンストレーションを容易にするために、事前に複数のデータを準備します
3.3.1 すべてのドキュメントをクエリする
3.3.2 クエリ文書の照合
ここでのクエリは、文書データ内の JSON オブジェクト データの name 属性が zhangsan であることを示しています。
3.3.3 クエリフィールドの照合
デフォルトでは、Elasticsearch はドキュメント内の _source に保存されているすべてのフィールドを検索結果として返します。
一部のフィールドのみを取得したい場合は、_source フィルタリングを追加できます
3.4 集計検索
集計を使用すると、リレーショナル データベースのグループ化と同様に、ユーザーは es ドキュメントに対して統計分析を実行できます。もちろん、他にも
多くの最大値、平均値などを取得します。
3.4.1 平均値
3.4.2 合計
3.4.3 最大値
3.4.4 TopN
3.5 インデックス テンプレート
以前にインデックスの構成情報をいくつか設定しましたが、それらはすべて単一のインデックスに設定されました。実際の開発では
、複数のインデックスを作成する必要がある場合がありますが、各インデックスには多かれ少なかれ共通点があります。たとえば、
リレーショナル データベースを設計する場合、通常、作成時刻、更新時刻
、コメント情報など、テーブル構造ごとによく使用されるフィールドをいくつか設計します。elasticsearch がインデックスを作成するとき、テンプレートの概念が導入されます。最初にいくつかの一般的なテンプレートを設定できます。
インデックスを作成するとき、elasticsearch は最初に、作成したテンプレートに従ってインデックスを設定します。
Elasticsearch には多くのデフォルト設定テンプレートが用意されているため、新しいドキュメントを作成するときに、
いくつかの情報を自動的に設定したり、フィールド変換を行ったりすることができます。
インデックスは、インデックス テンプレートと呼ばれる事前定義されたテンプレートを使用して作成できます。テンプレート設定には設定
とマッピングが含まれます。
3.5.1 テンプレートの作成
# 模板名称小写
PUT _template/mytemplate
{
"index_patterns" : [
"my*"
],
"settings" : {
"index" : {
"number_of_shards" : "1"
}
},
"mappings" : {
"properties" : {
"now": {
"type" : "date",
"format" : "yyyy/MM/dd"
}
}
}
}
3.5.2 テンプレートの表示
# GET /_template/mytemplate
3.5.3 テンプレートが存在するかどうかを確認する
#
HEAD /_template/mytemplate
3.5.4 インデックスの作成
#
PUT testindex
#
PUT mytest
3.5.5 テンプレートの削除
#
DELETE /_template/mytemplate
3.6 中国語の単語の分割
Elasticsearch の公式のデフォルトの単語の分割プラグインを使用すると、中国語の単語の分割に対する効果が良くなく、
単語の分割後の効果が期待どおりではないことがよくあります。
GET _analyze
{
"analyzer": "chinese",
"text": ["我是一个学生"]
}
中国語の検索とクエリをより適切に行うには、優れた単語セグメンター プラグインを Elasticsearch に統合する必要があります。IK
単語セグメンターは中国語をサポートするプラグインです。
3.6.1 統合された IK ワード セグメンター
3.6.1.1 ダウンロード
ダウンロード アドレス: https://github.com/medcl/elasticsearch-analysis-ik/releases
注: ダウンロード用に選択したバージョンは、Elasticsearch のバージョンに対応している必要があります。ここでは8.1.0を選択します
3.6.1.2 インストール
インストール ディレクトリの plugins ディレクトリで、ダウンロードした圧縮パッケージを直接解凍します
Elasticsearch サービスを再起動します
3.6.2 IK ワード セグメンタの使用
IK ワード セグメンタは 2 つのワード セグメンテーション アルゴリズムを提供します:
➢ ik_smart: minimumセグメンテーション
➢ Ik_max_word: 最も細かいセグメンテーション
次に、ik_smart アルゴリズムを使用して前の中国語コンテンツをセグメント化します。デフォルトのセグメンテーションとの違いが明らかにわかります
。
GET _analyze
{
"analyzer": "ik_smart",
"text": ["我是一个学生"]
}
次に、単語分割の効果を ik_max_word アルゴリズムと比較します
3.6.3 カスタマイズされた単語分割
の効果 IK 単語分割ツールを使用すると、単語分割の効果が期待したものと異なる場合があり、一部の
特殊なたとえば、上記の中国語の「学生」を開きたい場合はどうすればよいでしょうか? 実際、IK プラグインは
カスタムの単語分割辞書を提供するので、保持したい単語を追加できます。
次に、構成ファイル IKAnalyzer.cfg.xml を変更します。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>IK Analyzer 扩展配置</comment>
<!--用户可以在这里配置自己的扩展字典 -->
<entry key="ext_dict">test.dic</entry>
<!--用户可以在这里配置自己的扩展停止词字典-->
<entry key="ext_stopwords"></entry>
<!--用户可以在这里配置远程扩展字典 -->
<!-- <entry key="remote_ext_dict">words_location</entry> -->
<!--用户可以在这里配置远程扩展停止词字典-->
<!-- <entry key="remote_ext_stopwords">words_location</entry> -->
</properties>
Elasticsearch サーバーを再起動して効果を確認します
GET _analyze
{
"analyzer": "ik_smart",
"text": ["我是一个学生"]
}
3.7 ドキュメント スコア
Lucene と ES のスコアリング メカニズムは、TF-IDF 式と呼ばれる、単語頻度と逆文書単語頻度に基づく式です。式はクエリを入力として受け取り、さまざまな手段を使用して各ドキュメントのスコアを決定し
ます. 各要素は最後に、
式を通じて結合され、ドキュメントの最終スコアが返されます。
この総合的検討プロセスは、まず関係書類を返却していただくことを期待する検討プロセスでございます。Lucene と ES では、この相関関係をスコアと呼びます。
クエリのコンテンツとドキュメントの関係は比較的複雑であることを考慮すると、式に入力する必要があるパラメーターと条件が多数あります。しかし、
より重要なのは、実際には 2 つのアルゴリズム メカニズムです
➢ TF (用語頻度)
用語頻度: 検索テキスト内の各用語 (用語) がクエリ テキストに出現する回数。出現回数が多いほど、関連性が高くなります
。高
➢ IDF (Inverse Document Frequency)
逆ドキュメント頻度: 検索テキスト内の各用語が
インデックス全体のすべてのドキュメントに出現する回数。出現回数が多ければ多いほど、その重要性は低くなり、重要度も低くなります。関連性はありますが、スコアは比較的低いです。
3.7.1 スコアリングのメカニズム
次に、例を使用してドキュメントのスコアリングのメカニズムを簡単に分析してみましょう。
- まずは基礎データを用意しましょう
# 创建索引
PUT /atguigu
# 增加文档数据
# 此时索引中只有这一条数据
PUT /atguigu/_doc/1
{
"text":"hello"
}
2) 查询匹配条件的文档数据
#
GET /atguigu/_search
{
"query": {
"match": {
"text": "hello"
}
}
}
ここでのドキュメントのスコアは 0.2876821 です。この時点でインデックスにドキュメント データが 1 つしかないのに、そのドキュメント データがクエリ条件に直接一致する可能性があるのは奇妙です。スコアがこれほど低いのはなぜですか? これが計算式の計算結果です
3) 文書データのスコアリングプロセスの分析を見てみましょう
# 增加分析参数
GET /atguigu/_search?explain=true
{
"query": {
"match": {
"text": "hello"
}
}
}
実行後、スコアリング メカニズムには 2 つの重要な段階があることがわかります: TF 値の計算と IDF 値の計算。最終スコアは次のとおりです:
4
) TF 値の計算
5) IDF 値の計算
注: ここでの対数は底 e の対数です。
6) 計算ドキュメントスコア
7) 新しいドキュメント、テストスコアを追加
⚫ 無関係なドキュメントを追加
# 增加文档
PUT /atguigu/_doc/2
{
"text" : "spark"
}
# 因为新文档无词条相关信息，所以匹配的文档数据得分就应该较高：
# 0.6931741
GET /atguigu/_search
{
"query": {
"match": {
"text": "hello"
}
}
}
⚫ 同一のドキュメントを追加する
# 增加文档
PUT /atguigu/_doc/2
{
"text" : "hello"
}
# 因为新文档含词条相关信息，且多个文件含有词条，所以显得不是很重要，得分会变低
# 0.18232156
GET /atguigu/_search
{
"query": {
"match": {
"text": "hello"
}
}
}
⚫ エントリを含むが、より多くのコンテンツを含むドキュメントを追加します。
# 增加文档
PUT /atguigu/_doc/2
"text" : "hello elasticsearch"
}
# 因为新文档含词条相关信息，但只是其中一部分，所以查询文档的分数会变得更低一些。
# 0.14874382
GET /atguigu/_search
{
"query": {
"match": {
"text": "hello"
}
}
}
3.7.2 ケース
要件:
ドキュメントのタイトルに「Hadoop」、「Elasticsearch」、および「Spark」を含むコンテンツをクエリします。
「Spark」コンテンツを優先する
1) 准备数据
# 准备数据
PUT /testscore/_doc/1001
{
"title" : "Hadoop is a Framework",
"content" : "Hadoop 是一个大数据基础框架"
}
PUT /testscore/_doc/1002
{
"title" : "Hive is a SQL Tools",
"content" : "Hive 是一个 SQL 工具"
}
PUT /testscore/_doc/1003
{
"title" : "Spark is a Framework",
"content" : "Spark 是一个分布式计算引擎"
}
2) 查询数据
# 查询文档标题中含有“Hadoop”,“Elasticsearch”,“Spark”的内容
GET /testscore/_search?explain=true
{
"query": {
"bool": {
"should": [
{
"match": {
"title": {
"query": "Hadoop", "boost": 1}
}
},
{
"match": {
"title": {
"query": "Hive", "boost": 1}
}
},
{
"match": {
"title": {
"query": "Spark", "boost": 1}
}
}
]
}
}
}
この時点で、Spark の結果が前面に配置されないことがわかります。
この時点で、Spark クエリの重みパラメータ ブーストを変更して、クエリ結果の違いを確認できます。
# 查询文档标题中含有“Hadoop”,“Elasticsearch”,“Spark”的内容
GET /testscore/_search?explain=true
{
"query": {
"bool": {
"should": [
{
"match": {
"title": {
"query": "Hadoop", "boost": 1}
}
},
{
"match": {
"title": {
"query": "Hive", "boost": 1}
}
},
{
"match": {
"title": {
"query": "Spark", "boost": 2}
}
}
]
}
}
}
