devkuma – Elasticsearch

Elasticsearch の基本概念

kc@example.com (kc kim) — Fri, 03 Sep 2021 09:09:00 +0900

Elasticsearch

Elasticsearch は Apache Lucene を基盤とし、Java で開発されたオープンソースの検索エンジンである。
Elasticsearch は、複数のドキュメントやファイルから特定の文字列を検索する分散エンジンである。
Inverted Index 構造でデータを保存するため、全文検索時に RDBMS より優れた性能を発揮する。
通常は単独で使うよりも、ELK スタックとして Logstash、Kibana、Beats を追加して使用する。
データ保存、ドキュメント検索、位置検索、機械学習ベースの検索、ログ分析、セキュリティ検査分析など、さまざまな用途で使用される。

全文検索

複数のドキュメントやファイルから特定の文字列を検索することを全文検索という。

全文検索技術には grep 型とインデックス型があり、Elasticsearch は複数のコンピューターにインデックス型の全文検索を分散して高速な検索を提供する。

grep 型

複数のファイルを順番に検索する方法である。検索対象が増えるほど検索速度が大きく低下する。UNIX の文字列検索コマンド grep がこれに該当する。

インデックス型

本の索引と同じように、複数のドキュメントにあらかじめインデックスを作成して検索速度を高める方法である。インデックス型の全文検索を利用した例は次のとおりである。

Elasticsearch ドキュメント検索
Google 検索: 複数のドキュメント（Web ページ）から特定の文字列を検索
GitHub コード検索: 複数のドキュメント（ソースコード）から特定の文字列を検索

ここでは、次の 2 つのドキュメントを例にインデックスを作成した場合を紹介する。

ドキュメント 1: I Like search engine.
ドキュメント 2: I search keywords by google.

上記のドキュメントで、単語が含まれる場合を 1、含まれない場合を 0 とすると、次のようなインデックスが作成される。

インデックス (Index)

	I	like	search	engine	keywords	by	google
ドキュメント 1	1	1	1	1	0	0	0
ドキュメント 2	1	0	1	0	1	1	1

しかし、このインデックスは左から右への行単位でしか検索できない。そのため、google という単語を使うドキュメントを探すには、すべての行をスキャンする必要がある。

そこで Elasticsearch は、逆インデックス（Inverted index）というインデックスを使用する。逆インデックスは、次のようにインデックスの行と列を入れ替えた逆行列である。

逆インデックス (Inverted index)

	ドキュメント 1	ドキュメント 2
I	1	1
like	1	0
search	1	1
engine	1	0
keywords	0	1
by	0	1
google	0	1

逆インデックスでは、google という単語が登場するインデックスを検索するには、google の 1 行だけをスキャンすればよい。

インデックスと逆インデックス

Elasticsearch での index は、RDBMS の database に対応する概念である。

インデックス (index)
- キーワードを見つけやすいように並べた一覧を指す。
逆インデックス (Inverted Index)
- キーワードを通じてドキュメントを探し出す方式を指す。

逆インデックス構造の利点は、検索が非常に速いことである。簡単に言えば、本の先頭にある目次が Index に相当し、本の末尾でキーワードごとに探せる索引が Inverted index に相当する。Elasticsearch はテキストを解析して検索語辞書を作成し、逆インデックス方式でテキストを保存する。

Elasticsearch の特徴

Elasticsearch には次のような特徴がある。

Scale out
- シャードによって水平方向に規模を拡張できる。
可用性 (Availability)
- Replica によってデータの安定性を保証する。
Schema Free
- JSON ドキュメントを通じてデータ検索を行うため、スキーマの概念がない。
RESTful
- データの CRUD 操作は HTTP RESTful API を通じて行う。

Elasticsearch の用途（活用事例）

内部および外部ドキュメント検索

社内文書やサービス文書などを検索するために使用する。企業での活用事例は次のとおりである。

Wemakeprice: 販売製品を検索できるオンライン Web ストア（製品カタログ、在庫保存、自動補完など）
- [公開 SW 活用成功事例 203] Wemakeprice - 公開 SW で提供される「ホットディール」
GitHub: ソースコード検索
- GitHub uses Elasticsearch to index over 8 million code repositories | Elastic Customers

異常検知

アクセスログなどから異常を検知する。企業での活用事例は次のとおりである。

Wemakeprice: 機械学習による非定型脅威検知
- Wemakeprice: AWS クラウド環境の非定型脅威検知のための機械学習導入
11 番街: モニタリングおよび異常検知
- Elasticsearch による注文、決済のモニタリングおよび異常検知への Alert と機械学習適用事例
Netflix: セキュリティログモニタリング
- Elasticsearch in Netflix from Danny Yuan

Elasticsearch と RDBMS の比較

リレーショナル DB とは次のように対応する。

Relational Database	Elasticsearch
Database	Index
Table	Type
Row	Document
Column	Field
Index	Analyze
Primary key	_id
Schema	Mapping
Physical partition	Shard
Logical partition	Route
Relational	Parent/Child Nested
SQL	Query DSL

出典: https://www.slideshare.net/deview/2d1elasticsearch

インデックス構造の違い

Elasticsearch
- Inverted-Index 構造でデータを保存する。
- 本の索引のように、特定の単語が含まれるドキュメントを保存する方式である。
RDBMS
- B-Tree またはそれに類似したインデックスを使用する。

Elastic Stack

Elastic Stack は、Elasticsearch と次の 3 つのオープンソースプロジェクトで構成される。Elasticsearch は検索のために単独で使用されることもあるが、ELK スタックとして使用されることが多い。

Logstash、Kibana とともに使用され、一時期 ELK Stack（Elasticsearch、Logstash、Kibana）として広く知られるようになった Elastic は、2013 年に Logstash、Kibana プロジェクトを正式に取り込み、同じ屋根の下で一緒に開発を進めている。2015 年には会社名を Elasticsearch から Elastic に変更し、ELK Stack の代わりに製品名を Elastic Stack と正式に命名しながら、モニタリング、クラウドサービス、機械学習などの機能を継続して開発、拡張している。公式文書からの抜粋

Logstash

Elasticsearch に送るデータ形式を変換するツールである。ETL ツールの Transform、Load 部分を担当する。
アプリケーションサーバーから Elasticsearch サーバーへログを転送するとき、適切なデータ形式に変換するために使用される。
- さまざまなソース（DB、CSV ファイルなど）のログまたはトランザクションデータを収集、集計、解析し、Elasticsearch へ渡す。

Beats

データを転送する Shipper である。ETL の Extract を担当する。
アプリケーションサーバーから Logstash または Elasticsearch へデータを送る。

Elasticsearch

Logstash から受け取ったデータを検索、集計し、必要な関心情報を取得する。

Kibana

Elasticsearch の高速検索を通じてデータを可視化、モニタリングする。
Elasticsearch のドキュメントを可視化する、いわゆる BI ツールである。

Elasticsearch アーキテクチャ

Elasticsearch のアーキテクチャは、次の 2 つに分けられる。

論理的概念（ソフトウェア観点の用語）
物理的概念（ハードウェア観点の用語）

論理的概念

Elasticsearch の論理的概念の全体図は次のとおりである。

論理的概念図

次に各用語について説明する。

フィールド (Field)

項目名（Key）と値（Value）の組である。ファイルシステムでいう「ファイルの内容」に相当する。それぞれの Key は型（Type）を持つ。

文字列を表す text 型
時間を表す date 型など

ドキュメント (Document)

フィールドの集合をドキュメントという。ファイルシステムでいう「ファイル」に相当する。ドキュメントは JSON オブジェクトである。

インデックス (Index)

ドキュメントの集合をインデックスという。ファイルシステムでいう「フォルダー」に相当する。ドキュメントをインデックスに保存するとき、逆インデックスを作成する。

マッピング (Mapping)

各フィールドの Key に対する値のデータ型などを定義するものである。マッピングは 1 つのインデックスに 1 つ存在する。

上記の「論理的概念図」で説明されたマッピングでは、Content キーが Text 型として定義されているため、Content キーの値は常に Text 型の文字列になる。

物理的概念

Elasticsearch の物理的概念の全体図は次のとおりである。また、論理的概念であるインデックスとの関係もあわせて表現されている。

物理的概念と論理的概念の関連

ノード (Node)

ノードは Elasticsearch を構成する 1 つの単位プロセスを意味し、1 つの Elasticsearch サーバーである。

1 つの OS 上で複数の Elasticsearch ノードを起動できる。

ノードには役割に応じて次の 4 種類の属性があり、1 つのノードが複数の属性を持つことも可能である。

マスターノード (Master Node)
- クラスターメタデータなどを管理するノードである。
- マスターノードはクラスターごとに 1 つだけ存在する。
- マスターノードへ昇格可能なノードは Master-eligible と呼ばれるが、Master ノードではない。
データノード (Data Node)
- 実データを保存するノードである。
- リクエスト処理（検索および集計など）を実行する。
- リクエストを他のノードへルーティングする（例: 他のノードにシャードがある場合）。
インジェストノード (Ingest Node)
- データ変換および加工を行い、Data ノードに保存する。
- Logstash と同じ役割を担う。
コーディネートノード (Coordinating Node)
- リクエストルーティング（Data ノードでも可能）の役割を担う。
- Data ノードにルーティング作業の負荷をかけたくない場合に、ルーティング処理専用ノードとして用意するノードである。

クラスター (Cluster)

Elasticsearch でクラスターは最大のシステム単位を意味し、少なくとも 1 つ以上のノードからなるノード群である。クラスターに検索処理リクエストを投げると、各ノードに検索処理が分散される。

異なるクラスターはデータのアクセスや交換ができない独立したシステムとして維持され、複数台のサーバーが 1 つのクラスターを構成することも、1 台のサーバーに複数のクラスターが存在することもできる。

コンピュータークラスターとは、複数台のコンピューターが接続され、1 つのシステムのように動作するコンピューター群をいう。

シャード (Shard)

論理的概念として紹介した「インデックス」のデータを分割し、ノードに保存したデータである。これにより、検索プロセスを各ノードに分散できる。シャードの実体は Lucene インデックスファイルである。

シャードには次の 2 種類が存在する。

プライマリシャード (Primary shard)
- データの原本である。
- 最初に更新処理を行うシャードである。
レプリカシャード (Replica shard)
- プライマリシャードのコピーである。
- プライマリシャードの更新が終わると複製される。
- 検索負荷の分散やデータのバックアップとして使用される。

シャード (Shard) とレプリカ (Replica)

シャードとレプリカは Elasticsearch だけに存在する概念ではなく、分散データベースシステムにも存在する概念である。

シャード (Shard)
- シャーディングはデータを分散して保存する方法を意味する。つまり、スケールアウトのために index を複数の shard に分割する。
- 基本的に 1 つ以上存在し、検索性能向上のためにクラスターのシャード数を調整するチューニングを行うこともある。
- 単一ノードに保存できるデータ量には制限がある。
- クラスターで単一インデックスのデータを分割し、クラスターのストレージ、メモリ、処理容量を自然に活用できる。
- デフォルトではシャード数は 5 に設定され、インデックス作成時点でインデックスのデータを分割するシャード数を指定できる。インデックスを作成した後は、シャード数を変更できない。
レプリカ (Replica)
- Replica は別の形の Shard と見なすことができる。
- 障害発生時にも問題なく実行できるよう Replica（コピー）を用意し、障害を解決できる。つまり、ノードを失った場合のデータ信頼性のためにシャードを複製する。そのため、Replica は異なるノードに存在することが推奨される。
- インデックスの各シャードは 0 個以上のレプリカを持つことができる。
まとめ
- Elasticsearch の最小単位はノードであり、このノードはデータを保存してクエリを実行する。
- ノードが 1 つ以上集まってクラスターを構成する。
- ノード内部ではシャードによってデータをより効率的に管理でき、障害状況の発生を考慮してレプリカを追加構成することで、フェイルオーバーおよびデータ可用性を高められる。
  - 高可用性（Availability）とは、サーバー、ネットワーク、プログラムなどの情報システムが正常に使用可能な程度をいう。稼働率と似た意味である。

参考

Elasticsearch、Kibana、Cerebro のインストール

kc@example.com (kc kim) — Fri, 03 Sep 2021 00:00:00 +0000

ダウンロードしてインストール

Java のインストール

Elasticsearch は JVM 上で動作するため、Java 8（JDK）がインストールされている必要がある。

インストールされていない場合は、まず JDK からインストールしよう。

Java 8（JDK）ランタイムのインストール

$ sudo yum install java-1.8.0-openjdk -y

Java 8（JDK）開発環境のインストール

$ sudo yum install java-1.8.0-openjdk-devel -y

Java バージョンを確認する。

$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)

Elasticsearch のインストール

それでは Elasticsearch をインストールしてみよう。

まずインストールファイルをダウンロードする。

$ wget https://artifacts.elastic.co/downloads/kibana/kibana-7.14.1-linux-x86_64.tar.gz

ダウンロードしたファイルを展開する。

$ tar xvfz elasticsearch-7.14.1-linux-x86_64.tar.gz

ディレクトリ名を使いやすいように短く変更する。

$ mv files/elasticsearch-7.14.1-linux-x86_64/ es-714

bin ディレクトリへ移動する。

$ cd es-714/bin/

起動ファイルを実行する。

$ ./elasticsearch

[kimkc@localhost bin]$ ./elasticsearch
[2021-09-02T21:45:57,952][INFO ][o.e.n.Node               ] [localhost.localdomain] version[7.14.1], pid[116654], build[default/tar/66b55ebfa59c92c15db3f69a335d500018b3331e/2021-08-26T09:01:05.390870785Z], OS[Linux/4.18.0-338.el8.x86_64/amd64], JVM[Eclipse Foundation/OpenJDK 64-Bit Server VM/16.0.2/16.0.2+7]
[2021-09-02T21:45:57,957][INFO ][o.e.n.Node               ] [localhost.localdomain] JVM home [/home/kimkc/es-714/jdk], using bundled JDK [true]
[2021-09-02T21:45:57,958][INFO ][o.e.n.Node               ] [localhost.localdomain] JVM arguments [-Xshare:auto, -Des.networkaddress.cache.ttl=60, -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, --add-opens=java.base/java.io=ALL-UNNAMED, -XX:+UseG1GC, -Djava.io.tmpdir=/tmp/elasticsearch-1671236956648459411, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Xms166m, -Xmx166m, -XX:MaxDirectMemorySize=87031808, -XX:G1HeapRegionSize=4m, -XX:InitiatingHeapOccupancyPercent=30, -XX:G1ReservePercent=15, -Des.path.home=/home/kimkc/es-714, -Des.path.conf=/home/kimkc/es-714/config, -Des.distribution.flavor=default, -Des.distribution.type=tar, -Des.bundled_jdk=true]
[2021-09-02T21:46:00,777][INFO ][o.e.p.PluginsService     ] [localhost.localdomain] loaded module [aggs-matrix-stats]
[2021-09-02T21:46:00,778][INFO ][o.e.p.PluginsService     ] [localhost.localdomain] loaded module [analysis-common]
[2021-09-02T21:46:00,778][INFO ][o.e.p.PluginsService     ] [localhost.localdomain] loaded module [constant-keyword]
[2021-09-02T21:46:00,779][INFO ][o.e.p.PluginsService     ] [localhost.localdomain] loaded module [frozen-indices]
[2021-09-02T21:46:00,779][INFO ][o.e.p.PluginsService     ] [localhost.localdomain] loaded module [ingest-common]

... 以下省略 ...

接続できるか確認する。

$ curl -XGET localhost:9200

$ curl -XGET localhost:9200
{
  "name" : "es-714",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "8mO5vPIJQS-Eqa3PUvBVcA",
  "version" : {
    "number" : "7.14.1",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "66b55ebfa59c92c15db3f69a335d500018b3331e",
    "build_date" : "2021-08-26T09:01:05.390870785Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
[kimkc@es-714 ~]$

上記のように実行できれば、無事にインストールできている。

Kibana のインストール

インストールファイルをダウンロードする。

$ wget https://artifacts.elastic.co/downloads/kibana/kibana-7.14.1-linux-x86_64.tar.gz

ダウンロードしたファイルを展開する。

$ tar xvfz kibana-7.14.1-linux-x86_64.tar.gz

ディレクトリ名を使いやすいように短く変更する。

$ mv files/kibana-7.14.1-linux-x86_64/ kb-714

bin ディレクトリへ移動する。

$ cd kb-714/bin/

起動ファイルを実行する。

$ ./kibana

Docker にインストール

簡単な学習や試用が目的であれば、Docker を使用してインストールする方法をおすすめする。

Elasticsearch Docker インストール

Elasticsearch Docker イメージをダウンロード

次のコマンドを実行して Elasticsearch Docker イメージをダウンロードする。ここではバージョン 7.14.0 を使用する。

docker pull docker.elastic.co/elasticsearch/elasticsearch:7.14.0

実行結果は次のとおりである。

% docker pull docker.elastic.co/elasticsearch/elasticsearch:7.14.0
7.14.0: Pulling from elasticsearch/elasticsearch
ddf49b9115d7: Pull complete
693712dd4782: Pull complete
e1843b23879c: Pull complete
43b0526f3562: Pull complete
395a8174c4c5: Pull complete
671bce37ebcd: Pull complete
7b0bb020b357: Pull complete
Digest: sha256:46815a329dfdf633cac9261e287c8440512db13554cbcb4fa89842dde58e74b2
Status: Downloaded newer image for docker.elastic.co/elasticsearch/elasticsearch:7.14.0
docker.elastic.co/elasticsearch/elasticsearch:7.14.0

Elasticsearch Docker コンテナの作成と実行

次のコマンドを実行する。ここでは Docker コンテナ名を es714 とした。

docker run -d -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --name es714 docker.elastic.co/elasticsearch/elasticsearch:7.14.0

実行結果は次のとおりである。

% docker run -d -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --name es714 [docker.elastic.co/elasticsearch/elasticsearch:7.14.0](http://docker.elastic.co/elasticsearch/elasticsearch:7.14.0)
a3b75abf13c211cadf86637fe1c457b4b465556fc231a9a243362da49b117952

Elasticsearch Docker コンテナの実行確認

次のコマンドを実行してコンテナの実行を確認する。

docker ps

実行結果は次のとおりである。

% docker ps
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED              STATUS              PORTS                                                                                  NAMES
a3b75abf13c2   docker.elastic.co/elasticsearch/elasticsearch:7.14.0   "/bin/tini -- /usr/l..."   About a minute ago   Up About a minute   0.0.0.0:9200->9200/tcp, :::9200->9200/tcp, 0.0.0.0:9300->9300/tcp, :::9300->9300/tcp   es714

Elasticsearch Docker 設定の確認

次のコマンドを実行して設定を確認する。

docker exec -i -t es714 cat /usr/share/elasticsearch/config/elasticsearch.yml

実行結果は次のとおりである。

% docker exec -i -t es714 cat /usr/share/elasticsearch/config/elasticsearch.yml
cluster.name: "docker-cluster"
network.host: 0.0.0.0

Kibana Docker インストール

Kibana Docker イメージの取得

次のコマンドを実行して Kibana Docker イメージを取得する。バージョンは Elasticsearch と同じ 7.14.0 を使用する。

docker pull docker.elastic.co/kibana/kibana:7.14.0

実行結果は次のとおりである。

% docker pull docker.elastic.co/kibana/kibana:7.14.0
7.14.0: Pulling from kibana/kibana
ddf49b9115d7: Already exists
b62151c99641: Pull complete
d11b460fe76c: Pull complete
1078fcc7cd25: Pull complete
c74f7ca3ab86: Pull complete
2fb0a75edcfc: Pull complete
339c3eb65140: Pull complete
c359ec1d1586: Pull complete
7c0bddf401bf: Pull complete
59df587bba1b: Pull complete
34afeb086a05: Pull complete
4de583c3a000: Pull complete
961084329244: Pull complete
Digest: sha256:6408b11743abb2855e62406edb3cfd53848b97e48c65c0f4d843c427ccb3bb90
Status: Downloaded newer image for docker.elastic.co/kibana/kibana:7.14.0
docker.elastic.co/kibana/kibana:7.14.0

Kibana Docker コンテナの作成と実行

次のコマンドを実行する。

docker run -d --link es714:elasticsearch -p 5601:5601 --name kb714 docker.elastic.co/kibana/kibana:7.14.0

実行結果は次のとおりである。

% docker run -d --link es714:elasticsearch -p 5601:5601 --name kb714 docker.elastic.co/kibana/kibana:7.14.0
becb75fdb608c119407ea37e1f75f54898d64683fdb76674b08e8c875e1fca77

Kibana Docker コンテナの実行確認

以下のコマンドを実行する。

docker ps

実行結果は次のとおりである。

% docker ps
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED             STATUS             PORTS                                                                                  NAMES
becb75fdb608   docker.elastic.co/kibana/kibana:7.14.0                 "/bin/tini -- /usr/l..."   13 seconds ago      Up 12 seconds      0.0.0.0:5601->5601/tcp, :::5601->5601/tcp                                              kb714
a3b75abf13c2   docker.elastic.co/elasticsearch/elasticsearch:7.14.0   "/bin/tini -- /usr/l..."   About an hour ago   Up About an hour   0.0.0.0:9200->9200/tcp, :::9200->9200/tcp, 0.0.0.0:9300->9300/tcp, :::9300->9300/tcp   es714

Kibana 設定の確認

次のコマンドを実行する。

docker exec -i -t kb714 cat /usr/share/kibana/config/kibana.yml

実行結果は次のとおりである。

% docker exec -i -t kb714 cat /usr/share/kibana/config/kibana.yml
#
# ** THIS IS AN AUTO-GENERATED FILE **
#

# Default Kibana configuration for docker target
server.host: "0"
server.shutdownTimeout: "5s"
elasticsearch.hosts: [ "http://elasticsearch:9200" ]
monitoring.ui.container.elasticsearch.enabled: true%

Kibana 接続確認

以下の URL をブラウザに入力する。

http://localhost:5601/

次のように画面が表示されれば、正しくインストールできている。

Cerebro Docker インストール

Cerebro は Elasticsearch を GUI で確認できる別のツールである。

Cerebro Docker イメージの取得

次のコマンドを実行して Cerebro Docker イメージを取得する。

docker pull lmenezes/cerebro

実行結果は次のとおりである。

% docker pull lmenezes/cerebro
Using default tag: latest
latest: Pulling from lmenezes/cerebro
f7ec5a41d630: Pull complete
faf4c47c8c61: Pull complete
810072571faf: Pull complete
395682a2fa05: Pull complete
635a13f1552d: Pull complete
Digest: sha256:95b02e46ec91c00ab33ce21f4d23bf6083d3c900257b9371a56ea218737462e5
Status: Downloaded newer image for lmenezes/cerebro:latest
docker.io/lmenezes/cerebro:latest

Cerebro Docker コンテナの実行

以下のコマンドを実行する。

docker run -d -p 9000:9000 --link es714:localhost --name cerebro -e "CEREBRO_PORT=9000" -e "ELASTICSEARCH_HOST=http://localhost:9200" lmenezes/cerebro

実行結果は次のとおりである。

% docker run -d -p 9000:9000 --link es714:localhost --name cerebro -e "CEREBRO_PORT=9000" -e "ELASTICSEARCH_HOST=http://localhost:9200" lmenezes/cerebro
4f1c86c5e3156891cb129a841579f1ff6446c271c4fa53141c23c3d0004613f7

Cerebro 実行確認

以下の URL をブラウザに入力する。

http://localhost:9000

次のような画面が表示されたら、Node address 欄に http://localhost:9200 を入力する。

次のような画面が表示されれば、正しくインストールできている。

まとめて制御する

docker-compose ファイル作成

docker-compose-elastic.yml ファイルを作成し、次のように記述する。

version: '3.6'
services:
  elasticsearch:
    image: 'docker.elastic.co/elasticsearch/elasticsearch:7.14.0'
    container_name: es714
    ports:
      - "9200:9200"
      - "9300:9300"
    environment:
      - node.name="es01"
      - cluster.name="es-docker-cluster"
      - bootstrap.memory_lock=true
      - discovery.type=single-node
      - "ES_JAVA_OPTS=-Xms4g -Xmx4g"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    networks:
      - elastic

  kibana:
    image: 'docker.elastic.co/kibana/kibana:7.14.0'
    container_name: kb714
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_HOSTS=["http://es714:9200"]
    depends_on:
      - elasticsearch
    networks:
      - elastic

  cerebro:
    image: 'lmenezes/cerebro'
    container_name: 'cerebro'
    ports:
      - "9000:9000"
    environment:
      - "CEREBRO_PORT=9000"
      - "ELASTICSEARCH_HOST=http://es714:9200"
    networks:
      - elastic

volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local

networks:
  elastic:
    driver: bridge

すべての実行、停止、削除

実行コマンド

% docker-compose -f docker-compose-elastic.yml up -d

停止コマンド

% docker-compose -f docker-compose-elastic.yml stop

削除コマンド

% docker-compose -f docker-compose-elastic.yml rm

各サービスの接続確認

Elasticsearch の起動有無を確認する。

% chrome 127.0.0.1:9200

Kibana の起動有無を確認する。

% chrome 127.0.0.1:5601

Cerebro の起動有無を確認する。

% chrome 127.0.0.1:9000

Elasticsearch CRUD 操作 + Bulk API

kc@example.com (kc kim) — Tue, 14 Dec 2021 09:00:00 +0900

Elasticsearch は、次のようなプログラムから REST API を呼び出して操作できる。

Kibana Dev Tools
cURL
その他

CRUD 操作 + Bulk API

Elasticsearch の REST API では、ドキュメントに対して次の CRUD 操作が可能である。

REST API	対応する CRUD	説明
Index API	Create	ドキュメントをインデックスに追加
Get API	Read	ドキュメントを照会
Update API	Update	ドキュメントを変更
Delete API	Delete	ドキュメントを削除

これらは Single document APIs と呼ばれ、1 回の API 呼び出しで 1 つのドキュメントを処理する。

1 回の API 呼び出しで複数のドキュメントを処理するには Bulk API を使用する。

Index API (Create)

Index API を使用して Elasticsearch インデックスにドキュメントを追加する。

Index API の使い方は次のとおりである。

Index API 使用 (curl 使用)

curl "localhost:9200/2021-12-tweet/_doc/1?pretty" -XPUT -H "Content-Type: application/json" -d '
{
  "date":"2021/12/13 09:00 KST",
  "Tweet":"트위터를 시작했습니다.",
  "User ID":"devkuma"
}'

Index API 使用 (Kibana 使用)

PUT /2021-12-tweet/_doc/1
{
  "date":"2021/12/13 09:00 KST",
  "Tweet":"트위터를 시작했습니다.",
  "User ID":"devkuma"
}

Kibana の Dev Tools を使用する場合は、上記のコマンドを貼り付け、右上の三角ボタンを押す。

データストリームにドキュメントを追加する場合

データストリームとは、複数のインデックスを 1 つにまとめたものである。

データストリームの詳細は、以下の公式ドキュメントを参照してほしい。

Data streams | Elasticsearch Guide [7.16] | Elastic

データストリームにドキュメントを追加するには、次のように REST API を使用する。

Index API 使用 (Kibana 使用)

PUT /tweet/_create/1
{
  "date" : "2021/12/13 09:00 KST",
  "Tweet" : "트위터를 시작했습니다.",
  "User ID" : "devkuma"
}

Get API (Read)

Get API を使用して作成したドキュメントを照会する。

Get API 使用 (curl 使用)

curl "localhost:9200/2021-12-tweet/_doc/1?pretty"

Get API 使用 (Kibana 使用)

GET /2021-12-tweet/_doc/1

上記コマンドの応答

{
  "_index" : "2021-12-tweet",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "date" : "2021/12/13 09:00 KST",
    "Tweet" : "트위터를 시작했습니다.",
    "User ID" : "devkuma"
  }
}

Update API (Update)

Update API を使用してドキュメントを修正する。

Update API 使用 (curl 使用)

curl "localhost:9200/2021-12-tweet/_update/1?pretty" -XPOST -H "Content-Type: application/json" -d '
{
  "doc" : {
    "date" : "2021/12/13 09:00 KST",
    "Tweet" : "문서를 업데이트했습니다.",
    "User ID" : "devkuma" 
  }
}'

Update API 使用 (Kibana 使用)

POST /2021-12-tweet/_update/1
{
  "doc" : {
    "date" : "2021/12/13 09:00 KST",
    "Tweet" : "문서를 업데이트했습니다.",
    "User ID" : "devkuma" 
  }
}

修正結果を Get API で確認する。

Update 結果確認 (curl 使用)

curl "localhost:9200/2021-12-tweet/_doc/1?pretty"

Update 結果確認 (Kibana 使用)

GET /2021-12-tweet/_doc/1

上記コマンドの応答

{
  "_index" : "2021-12-tweet",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 2,
  "_seq_no" : 1,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "date" : "2021/12/13 09:00 KST",
    "Tweet" : "문서를 업데이트했습니다.",
    "User ID" : "devkuma"
  }
}

Delete API (Delete)

Delete API でドキュメントを削除する。

Delete API 使用 (curl 使用)

curl "localhost:9200/2021-12-tweet/_doc/1?pretty" -XDELETE

Delete API 使用 (Kibana 使用)

DELETE /2021-12-tweet/_doc/1

ドキュメントが削除されたことを Get API で確認する。

Delete 結果確認 (curl 使用)

curl "localhost:9200/2021-12-tweet/_doc/1?pretty"

Delete 結果確認 (Kibana 使用)

GET /2021-12-tweet/_doc/1

上記コマンドの応答

{
  "_index" : "2021-12-tweet",
  "_type" : "_doc",
  "_id" : "1",
  "found" : false
}

Bulk API（一括処理）

ここまでは REST API で一度に 1 つのドキュメントだけを処理した。

Bulk API を使用すると、REST API で一度に複数のドキュメントを一括処理できる。

Bulk API の使用方法は次のとおりである。

bulk.json の内容

{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_id" : "2" } }
{ "create" : { "_index" : "test", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : { "_id" : "1", "_index" : "test" } }
{ "doc" : { "field2" : "value2" } }

Bulk API 使用 (curl 使用)

curl "localhost:9200/_bulk?pretty" -XPOST --data-binary @bulk.json -H "Content-Type: application/json"

Bulk API 使用 (Kibana 使用)

POST /_bulk 
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_id" : "2" } }
{ "create" : { "_index" : "test", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : { "_id" : "1", "_index" : "test" } }
{ "doc" : { "field2" : "value2" } }

Create、Index、Update の違いは次のとおりである。

Create: インデックスにドキュメントがない場合に作成する。
Index: インデックスのドキュメントを置き換える。
Update: インデックスのドキュメントの一部を変更する。

参照

4.2 CRUD - 入力、照会、修正、削除

Elasticsearch マッピング管理 + テンプレート

kc@example.com (kc kim) — Tue, 14 Dec 2021 09:09:00 +0900

マッピング管理 + テンプレート

マッピング（Mapping）は、前述のとおりフィールドの Key の形を定義したものである。一度作成したマッピングは、フィールド追加を除いて修正できない。修正するにはインデックスを作り直す必要がある。

マッピングを作成および追加する方法は、次の 4 つである。

自動でマッピングを作成する
手動でマッピングを作成する
テンプレートでマッピングを作成する
既存のマッピングにフィールドを追加する

自動でマッピングを作成する

Elasticsearch は、次のようにインデックスにドキュメントを作成するとき、自動でマッピングを作成する。

mapping_test インデックスにドキュメントを作成

PUT /mapping_test/_doc/1
{
  "date":"2021/12/01 09:00:00+0900",
  "Tweet":"This is a mapping test."
}

マッピング確認

GET /mapping_test

マッピング内容

GET /mapping_test
{
  "mapping_test" : {
    "aliases" : { },
    "mappings" : {
      "properties" : {
        "Tweet" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "date" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    },

// ... 以下省略 ...

上記の結果を見ると、次のようなマッピングが定義されたことがわかる。text 型と keyword 型の違いについては次のとおりである。

date、Tweet キーは text 型
date.keyword、text.keyword キーは keyword 型

上記で作成したマッピングの date キーは text 型として登録されているが、date 型として登録しなければならない場合がある。そのような場合は、手動でマッピングを作成する必要がある。

手動でマッピングを作成する

手動でマッピングを作成する方法は次のとおりである。

手動マッピングを作成

PUT /mapping_test2
{
  "mappings": {
    "properties": {
      "date":    { 
        "type": "date",
        "format": "yyyy/MM/dd HH:mm:ssZ"
      },  
      "tweet":  {
        "type": "text",
        "fields": {
          "keyword":{
            "type":"keyword"
          }
        }
      }
    }
  }
}

手動でマッピングを作成した結果

GET /mapping_test2

手動で作成したマッピング内容

GET /mapping_test2
{
  "mapping_test2" : {
    "aliases" : { },
    "mappings" : {
      "properties" : {
        "date" : {
          "type" : "date",
          "format" : "yyyy/MM/dd HH:mm:ssZ"
        },
        "tweet" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword"
            }
          }
        }
      }
    },

... 以下省略 ...

正しく作成できていれば、date キーが date 型としてマッピングされていることがわかる。

マッピングで指定したフォーマットと異なる場合

マッピングで指定した形式と異なるドキュメントを作成するとエラーが発生する。

実行してみると、date フィールドのフォーマットは "yyyy/MM/dd HH:mm:ssZ" だが、別フォーマットとして "yyyy/MM/dd HH:mm:Z"（秒を指定していない）データを入れてみる。

マッピングで指定したフォーマットと異なるドキュメントを作成

PUT /mapping_test2/_doc/1
{
  "date":"2021/12/01 09:00+0900",
  "tweet":"This is a mapping test."
}

エラーメッセージ

{
  "error" : {
    "root_cause" : [
      {
        "type" : "mapper_parsing_exception",
        "reason" : "failed to parse field [date] of type [date] in document with id '1'. Preview of field's value: '2021/12/01 09:00+0900'"
      }
    ],

... 以下省略 ...

予想どおり、date フィールドを解析できないというメッセージが表示される。

マッピングで指定したフォーマットと同じ場合

今度は正しいフォーマットでドキュメントを作成してみる。

マッピングのフォーマットどおりにドキュメントを作成

PUT /mapping_test2/_doc/2
{
  "date":"2020/11/01 09:00:00+0900",
  "tweet":"This is a mapping test."
}

正しいフォーマットでドキュメントを作成すると成功することがわかる。

テンプレートでマッピングを作成する

インデックスごとに同じマッピングを何度も作成するのは手間がかかる。これを解決するのがテンプレートである。

テンプレートは、指定した名前のインデックスが作成されたときに、テンプレートのマッピングを使ってインデックスを作成する。テンプレートを作成するには template API を使用する。

_template API を使用する。

PUT /_template/test_template
{
  "index_patterns": "test*",
  "mappings": {
    "properties": {
      "date":    { 
        "type": "date",
        "format": "yyyy/MM/dd HH:mm:ssZ"
      },  
      "tweet":  {
        "type": "text",
        "fields": {
          "keyword":{
            "type":"keyword"
          }
        }
      }
    }
  }
}

上記のテンプレートでは、"index_patterns": "test*" と指定しているため、インデックス名の接頭辞に "test" がある場合、指定したマッピングを作成する。

テンプレートの動作を確認してみよう。

test インデックスを作成

PUT /test

test インデックスのマッピング確認

GET /test

test インデックスのマッピング結果確認

GET /test
{
  "test" : {
    "aliases" : { },
    "mappings" : {
      "properties" : {
        "date" : {
          "type" : "date",
          "format" : "yyyy/MM/dd HH:mm:ssZ" // テンプレートで指定した format で date フィールドが登録される
        },
        "tweet" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword"
            }
          }
        }
      }
    },

... 以下省略 ...

テンプレートで指定した format で date フィールドが登録されたことがわかる。

既存マッピングにフィールドを追加する

既存マッピングに新しいフィールドを追加するには mapping API を使用する。

additional_field フィールドを mapping_test2 インデックスのマッピングに追加してみる。

mapping_test2 の内容

GET /mapping_test2
{
  "mapping_test2" : {
    "aliases" : { },
    "mappings" : {
      "properties" : {
        "date" : {
          "type" : "date",
          "format" : "yyyy/MM/dd HH:mm:ssZ"
        },
        "tweet" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword"
            }
          }
        }
      }
    },
... 以下省略 ...

マッピングにフォーマットを追加

PUT /mapping_test2/_mapping
{
  "properties":{
    "additional_field":{
      "type":"text"
    }
  }
}

additional_field フォーマットが追加されたことを確認

GET /mapping_test2

additional_field フォーマットが追加された結果確認

{
  "mapping_test2" : {
    "aliases" : { },
    "mappings" : {
      "properties" : {
        "additional_field" : { // additional_field フィールドが追加された
          "type" : "text"
        },
        "date" : {
          "type" : "date",
          "format" : "yyyy/MM/dd HH:mm:ssZ"
        },
        "tweet" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword"
            }
          }
        }
      }
    },
... 以下省略 ...

additional_field フィールドが追加されたことを確認できた。

Elasticsearch Analyzer（文章分析）

kc@example.com (kc kim) — Thu, 16 Dec 2021 08:12:00 +0900

Analyzer

Analyzer は文章を単語（term）単位に分割する。

この章では、次の項目について説明する。

Analyzer の構成要素
nori 韓国語形態素解析器
Custom Analyzer（Analyzer のカスタマイズ）

なぜ Analyzer を使って単語に分割する必要があるのか

「ドキュメントを正確に検索できないから」が答えだが、もう少し具体的に例を見ながら確認してみよう。

検索用文章の準備

POST demo_standard_analyzer/_doc
{
  "text":"올해 서울시 예산이 결정되었다."
}

上記の文書に対して、서울 という単語で検索してみる。

GET demo_standard_analyzer/_search
{
  "query" : {
     "match" : {
       "text" : "서울"
    }
  }
}

検索結果は次のようにヒットしない。

{
  "took" : 3,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

서울 という単語では 서울시 の文書がヒットしない。서울시 の 서울 部分だけでは検索できないためである。

analyze API を使うと、文書文字列が Analyzer によってどのように分解され、逆インデックスに保存されているかを確認できるため、原因を調べてみる。

基本 Standard Analyzer で文章分解

POST demo_standard_analyzer/_analyze
{
  "text": "올해 서울시 예산이 결정되었다."
}

基本 Standard Analyzer で文章分解した結果

{
  "tokens" : [
    {
      "token" : "올해",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "<HANGUL>",
      "position" : 0
    },
    {
      "token" : "서울시",
      "start_offset" : 3,
      "end_offset" : 6,
      "type" : "<HANGUL>",
      "position" : 1
    },
    {
      "token" : "예산이",
      "start_offset" : 7,
      "end_offset" : 10,
      "type" : "<HANGUL>",
      "position" : 2
    },
    {
      "token" : "결정되었다",
      "start_offset" : 11,
      "end_offset" : 16,
      "type" : "<HANGUL>",
      "position" : 3
    }
  ]
}

token キーの値を見ると、Standard Analyzer は文章をこのように分割して逆インデックスに保存していることがわかる。

そのため、正しく検索するには、韓国語に対応した Analyzer で文章を単語に分解する必要がある。

Analyzer の構成要素

Analyzer は次の 3 つの要素で構成される。

Char Filter: 文章変換
Tokenizer: 文章を Token（単語）に分割
Token filter: Token（単語）変換

Analyzer は 3 つの要素を上から順に処理し、文章を Token（単語）に分解して逆インデックスを作成する。

Char Filter: 文章変換の例

HTML Strip Character Filter
- HTML タグを削除する。
- <p>foo</p> –(変換)–> foo

Tokenizer: 文章を Token（単語）に分割する例

Standard Tokenizer（基本トークナイザー）
Nori Tokenizer（nori トークナイザー）

Token filter: Token（単語）変換の例

Lower case Token Filter
- トークンの文字をすべて小文字に変換する。
- Google と google を同じトークンとして扱いたいときに使用する。
Stop Token Filter
- 使用しないトークンを削除する。
- 助詞削除などに利用される。
Stemmer Token Filter
- ステミング処理を行う。
- 즐겁게 と 즐겁다 を 즐거움 に変換する。
Synonym Token Filter
- 同義語を正規化する。
- 구글 と 검색 を同じ 검색 に変換する。

nori 韓国語形態素解析器

Elasticsearch の基本 Standard Analyzer は韓国語をサポートしない。

韓国語検索を正しく行うには、nori Analysis Plugin という韓国語形態素解析用プラグインを使って、文章を単語に分割する必要がある。

nori Analysis Plugin のインストール

nori Analysis Plugin インストールコマンド

bin/elasticsearch-plugin install analysis-nori

以下は Docker で実行した内容である。

sh-4.4# bin/elasticsearch-plugin install analysis-nori
-> Installing analysis-nori
-> Downloading analysis-nori from elastic
[=================================================] 100%?? 
-> Installed analysis-nori
-> Please restart Elasticsearch to activate any plugins installed
sh-4.4#

参考までに、逆にプラグインを削除する方法は次のとおりである。 nori Analysis Plugin 削除コマンド

bin/elasticsearch-plugin remove analysis-nori

インストール後は、nori プラグインを使用するため Elasticsearch を再起動する必要がある。

systemctl コマンドを使用する方法は次のとおりである。

systemctl restart elasticsearch

再起動方法はインストール環境によって異なるため、それぞれの環境に合わせて再起動してほしい。

Nori Analyzer 構成

Char Filter
- なし
Tokenizer
- nori_tokenizer
Token filter
- nori_part_of_speech
- nori_readingform

Nori Tokenizer の使い方

文字列だけを nori トークン分解してみる。

Nori Tokenizer で文章分析

GET _analyze
{
  "tokenizer": "nori_tokenizer",
  "text": [
    "올해 서울시 예산이 결정되었다."
  ]
}

Nori Tokenizer で文章分析した結果

{
  "tokens" : [
    {
      "token" : "올",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "해",
      "start_offset" : 1,
      "end_offset" : 2,
      "type" : "word",
      "position" : 1
    },
    {
      "token" : "서울",
      "start_offset" : 3,
      "end_offset" : 5,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "시",
      "start_offset" : 5,
      "end_offset" : 6,
      "type" : "word",
      "position" : 3
    },
    {
      "token" : "예산",
      "start_offset" : 7,
      "end_offset" : 9,
      "type" : "word",
      "position" : 4
    },
    {
      "token" : "이",
      "start_offset" : 9,
      "end_offset" : 10,
      "type" : "word",
      "position" : 5
    },
    {
      "token" : "결정",
      "start_offset" : 11,
      "end_offset" : 13,
      "type" : "word",
      "position" : 6
    },
    {
      "token" : "되",
      "start_offset" : 13,
      "end_offset" : 14,
      "type" : "word",
      "position" : 7
    },
    {
      "token" : "었",
      "start_offset" : 14,
      "end_offset" : 15,
      "type" : "word",
      "position" : 8
    },
    {
      "token" : "다",
      "start_offset" : 15,
      "end_offset" : 16,
      "type" : "word",
      "position" : 9
    }
  ]
}

Nori Analyzer の使い方

実際に demo_analyzer インデックスで Nori Analyzer を設定してみる。

analyzer に nori を指定

PUT demo_analyzer
{
  "mappings" : {
     "properties" : {
       "text" :{
         "type" : "text" ,
         "analyzer" : "nori"
      }
    }
  }
}

次に demo_analyzer インデックスへドキュメントを作成し、韓国語検索を実行してみる。

ドキュメント作成

POST demo_analyzer/_doc
{
  "text": "올해 서울시 예산이 결정되었다."
}

울시 検索

GET demo_analyzer/_search
{
  "query" : {
     "match" : {
       "text" : "울시"
    }
  }
}

울시 検索結果

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

울시 という単語では 서울시 がヒットしない。まったく別の単語として認識されているようだ。

nori Analyzer ではどのような逆インデックスが生成されるのか確認してみる。

nori Analyzer で形態素分析

GET demo_analyzer/_analyze
{
  "analyzer" : "nori", 
  "text" : "올해 서울시 예산이 결정되었다."
}

nori Analyzer で形態素分析した結果

{
  "tokens" : [
    {
      "token" : "올",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "해",
      "start_offset" : 1,
      "end_offset" : 2,
      "type" : "word",
      "position" : 1
    },
    {
      "token" : "서울",
      "start_offset" : 3,
      "end_offset" : 5,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "시",
      "start_offset" : 5,
      "end_offset" : 6,
      "type" : "word",
      "position" : 3
    },
    {
      "token" : "예산",
      "start_offset" : 7,
      "end_offset" : 9,
      "type" : "word",
      "position" : 4
    },
    {
      "token" : "결정",
      "start_offset" : 11,
      "end_offset" : 13,
      "type" : "word",
      "position" : 6
    }
  ]
}

서울 と 시 に分析してくれるようだ。そのため、서울시 に対して 울시 はヒットしない。

Custom Analyzer（Analyzer のカスタマイズ）

Analyzer は次の 3 つの要素を組み合わせて、自由にカスタム作成できる。

Char Filter
Tokenizer
Token filter

たとえば、次のような Custom Analyzer を作成する。

Custom Analyzer 作成

PUT custome_analyze
{
  "settings" : {
     "analysis" : {
       "analyzer" : {
         "original_analyze" :{
           "char_filter" :[ "html_strip" ],
           "tokenizer" : "nori_tokenizer" ,
           "filter" :[ "my_stop" ]
        }
      },
      "filter" :{
         "my_stop" :{
           "type" : "stop" ,
           "stopwords" :[ "올", "해" , "이" ]  
        }
      }
    }
  }
}

作成した Analyzer で文章分析してみよう。

Custom Analyzer 使用

POST custome_analyze/_analyze
{
  "analyzer" : "original_analyze",
  "text" : "<p>올해 서울시 예산이 결정되었다</p>"
}

Custom Analyzer を使用した結果

{
  "tokens" : [
    {
      "token" : "서울",
      "start_offset" : 6,
      "end_offset" : 8,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "시",
      "start_offset" : 8,
      "end_offset" : 9,
      "type" : "word",
      "position" : 3
    },
    {
      "token" : "예산",
      "start_offset" : 10,
      "end_offset" : 12,
      "type" : "word",
      "position" : 4
    },
    {
      "token" : "결정",
      "start_offset" : 14,
      "end_offset" : 16,
      "type" : "word",
      "position" : 6
    },
    {
      "token" : "되",
      "start_offset" : 16,
      "end_offset" : 17,
      "type" : "word",
      "position" : 7
    },
    {
      "token" : "었",
      "start_offset" : 17,
      "end_offset" : 18,
      "type" : "word",
      "position" : 8
    },
    {
      "token" : "다",
      "start_offset" : 18,
      "end_offset" : 19,
      "type" : "word",
      "position" : 9
    }
  ]
}

出力結果には、Custom Analyzer original_analyze に定義した次の処理が反映されている。

html_strip は HTML の <p> タグを削除する。
nori_tokenizer で文章を Token（単語）に変換する。
my_stop で定義した stopwords により、"올"、"해"、"이" を削除する。

参照

6.7.2 nori 韓国語形態素解析器

Elasticsearch Aggregation（集計、分類）

kc@example.com (kc kim) — Fri, 17 Dec 2021 08:55:00 +0900

Aggregation（集計、分類）

Elasticsearch では次の Aggregation クエリを実行できる。

まず Aggregation クエリを実行するために、demo_agg インデックスを作成する。

demo_agg インデックス作成

POST /_bulk
{ "index" : { "_index" : "demo_agg" , "_id" : "1" }}
{ "text" : "This is Elasticsearch test." , "type" : 1 }
{ "index" : { "_index" : "demo_agg" , "_id" : "2" }}
{ "text" : "Elasticsearch is God." , "type" : 2 }
{ "index" : { "_index" : "demo_agg" , "_id" : "3" }}
{ "text" : "This is a pen." , "type" : 3 }
{ "index" : { "_index" : "demo_agg" , "_id" : "4" }}
{ "text" : "I have a pen." , "type" : 2 }

集計（Metrics）

demo_agg インデックスに対して集計を行う。まず、avg クエリを使って値の平均を求める。

avg クエリ

GET demo_agg/_search
{
  "size": 0,
  "aggs": {
    "hoge_name": {
      "avg": {
        "field":"type"
      }
    }
  }
}

avg クエリ結果

{
  "took" : 3,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 4,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "hoge_name" : {
      "value" : 2.0
    }
  }
}

value は 2.0 である。ここで平均を求めた type の値は [1,2,3,2] なので、この平均は 2 となり正しい結果であることがわかる。

また、"size": 0 は _search API の検索結果を 0 件表示する、つまり表示しないことを意味する。この値を増やすと、平均を求めるために使用した検索結果を確認できる。

その他にも、以下の集計を行うことができる。

sum: 合計値を取得する。
max: 最大値を取得する。
min: 最小値を取得する。
stats: 上記すべての値を取得する。
cardinary: 値の種類を取得する。たとえば [1,2,3,2] の場合は、1、2、3 の 3 種類となる。

分類（Buckets）

以下のように指定した条件ごとに Buckets を作成し、該当するドキュメントを Buckets に入れることができる。

範囲（range）で分類

Buckets 作成

GET demo_agg/_search
{
  "size": 0,
  "aggs": {
    "bucket_name": {
      "range": {
        "field":"type",
        "ranges": [
          {
            "from": 0, 
            "to":2
          },
          {
            "from": 2
          }
        ]
      }
    }
  }
}

Buckets 作成結果

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 4,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "bucket_name" : {
      "buckets" : [
        {
          "key" : "0.0-2.0",
          "from" : 0.0,
          "to" : 2.0,
          "doc_count" : 1
        },
        {
          "key" : "2.0-*",
          "from" : 2.0,
          "doc_count" : 3
        }
      ]
    }
  }
}

実行結果から次のことを確認できる。

"type" フィールドの値が 0 以上 2 未満の Bucket には、1 つのドキュメントが含まれる。(type=[1])
"type" フィールドの値が 2 以上の Bucket には、3 つのドキュメントが含まれる。(type=[2,3,2])

同じ間隔（histogram）で分類

このほかにも、histogram クエリを使って値を同じ間隔で分類できる。

histogram クエリ

GET demo_agg/_search
{
  "size" : 0 ,
   "aggs" : {
     "bucket_name" : {
       "histogram" : {
         "field" : "type" ,
         "interval" : 1
      }
    }
  }
}

histogram クエリ実行結果

{
  "took" : 9,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 4,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "bucket_name" : {
      "buckets" : [
        {
          "key" : 1.0,
          "doc_count" : 1
        },
        {
          "key" : 2.0,
          "doc_count" : 2
        },
        {
          "key" : 3.0,
          "doc_count" : 1
        }
      ]
    }
  }
}

上記のように、入力した間隔値である 1 ごとにドキュメントがそれぞれ Buckets に分類されたことがわかる。