【入門者向け】Elasticsearch API の使い方：知っておきたい基礎知識

By /

【入門者向け】Elasticsearch API の使い方：知っておきたい基礎知識

はじめに

Elasticsearch は、強力な検索エンジン、分析プラットフォーム、および分散型データストアとして、多くのアプリケーションで利用されています。ログ分析、リアルタイムモニタリング、全文検索、ビジネスインテリジェンスなど、その用途は多岐にわたります。Elasticsearch の可能性を最大限に引き出すためには、その核となる API を理解し、使いこなすことが不可欠です。

しかし、Elasticsearch は機能が豊富であるため、どこから手を付けて良いか分からないと感じる入門者の方も多いかもしれません。特に API は様々な種類があり、どのような操作を、どのような形式で行えば良いのか、最初は戸惑うこともあるでしょう。

この記事は、そのような入門者の方を対象に、Elasticsearch API の基本的な使い方と、それを理解するために必要な基礎知識を、詳細かつ分かりやすく解説することを目的としています。この記事を読むことで、Elasticsearch API を使ってデータの登録、取得、検索、削除といった基本的な操作ができるようになり、さらに高度な機能へとステップアップするための土台を築くことができるでしょう。

API 学習の前に、Elasticsearch がどのようにデータを扱うか（インデックス、ドキュメントなどの概念）や、RESTful API の基本的な考え方（HTTPメソッド、エンドポイントなど）について軽く理解しておくと、学習がスムーズに進みます。もしこれらの概念に自信がない場合でも、記事の中で関連する部分については簡単に触れていきますのでご安心ください。

さあ、Elasticsearch API の世界への扉を開きましょう。

Elasticsearch API の全体像：RESTful な操作

Elasticsearch は、RESTful API を通じて操作されます。これは、HTTP プロトコルを使って、リソース（この場合は Elasticsearch クラスタ内のデータや設定など）に対してアクション（作成、読み取り、更新、削除など）を行う標準的な方法です。

RESTful API は、以下の要素で構成されます。

  1. エンドポイント (Endpoint): 操作対象のリソースを識別する URL です。Elasticsearch のエンドポイントは、通常 / で始まり、操作の種類や対象となるインデックス、ドキュメントなどをパスとして含みます。
  2. HTTP メソッド (HTTP Method): リソースに対して行いたいアクションを示します。主なメソッドには GET, POST, PUT, DELETE, HEAD などがあります。
  3. リクエストヘッダー (Request Headers): リクエストに関するメタ情報（データ形式、認証情報など）を含みます。Elasticsearch API では Content-Type: application/json などがよく使われます。
  4. リクエストボディ (Request Body): POST や PUT メソッドなどで、サーバーに送信するデータ本体を含みます。Elasticsearch API では、インデクシングするドキュメントや、詳細な検索クエリ（Query DSL）などを JSON 形式で指定します。
  5. レスポンスステータスコード (Response Status Code): サーバーからの応答結果を示します。200 OK (成功), 201 Created (作成成功), 400 Bad Request (リクエストエラー), 404 Not Found (リソース見つからず), 500 Internal Server Error (サーバー内部エラー) などがあります。
  6. レスポンスボディ (Response Body): サーバーからの応答データを含みます。Elasticsearch API の応答は、通常 JSON 形式で返されます。

Elasticsearch API のエンドポイントは、以下の構造を持つことが多いです。

/{index_name}/_doc/{id}
/{index_name}/_search
/_cluster/health
/_cat/indices

  • {index_name}: 操作対象のインデックス名です。インデックスはリレーショナルデータベースにおけるテーブルのようなものと考えてください。
  • {id}: 操作対象のドキュメント ID です。ドキュメントはリレーショナルデータベースにおける行（レコード）のようなものです。
  • _doc: ドキュメント関連の操作を示すエンドポイントの一部です。
  • _search: 検索操作を示すエンドポイントです。
  • _cluster: クラスタ全体に関する操作を示すエンドポイントです。
  • _cat: クラスタの状態を人間が読みやすい形式で表示するためのエンドポイント群です。

HTTP メソッドと Elasticsearch API の役割:

  • GET: リソースの取得。クラスタ情報、インデックス情報、ドキュメントの取得、検索などに使われます。
  • PUT: リソースの作成または置換。インデックスの作成、特定の ID を持つドキュメントの新規作成または更新（上書き）に使われます。
  • POST: リソースの作成またはアクションの実行。自動生成 ID でのドキュメント新規作成、部分更新、一括操作（Bulk API）、検索（リクエストボディを使う場合）などに使われます。
  • DELETE: リソースの削除。インデックスやドキュメントの削除に使われます。
  • HEAD: リソースの存在確認。ドキュメントやインデックスが存在するかどうかを、ボディなしで確認するのに使われます。

API を実行するためのツールとしては、curl コマンドラインツール、Kibana Dev Tools、各種プログラミング言語用の Elasticsearch クライアントライブラリなどがあります。入門段階では、手軽に試せる curl や Kibana Dev Tools を使うのがおすすめです。この記事では主に curl コマンド形式で API の例を示しますが、Kibana Dev Tools でも同様に実行できます。

基本的な API の操作

ここでは、Elasticsearch API を使ってクラスタの状態確認、インデックスの作成・削除、ドキュメントの登録・取得・更新・削除といった基本的な操作を行う方法を学びます。

Elasticsearch がローカルで実行されている場合、通常 localhost:9200 でアクセスできます。以下の例では、このアドレスを前提とします。

1. クラスタヘルス確認

Elasticsearch クラスタが正常に動作しているかを確認する最も基本的な API です。

リクエスト:

bash
GET /_cluster/health

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/_cluster/health?pretty"

  • -X GET: HTTP メソッドとして GET を指定します。
  • "localhost:9200/_cluster/health?pretty": エンドポイント URL です。?pretty はレスポンスの JSON を整形して見やすくするためのクエリパラメータです。API 例では特に断りがなければ ?pretty をつけて説明します。

レスポンス例:

json
{
"cluster_name": "elasticsearch",
"status": "green",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_gid_count": 0
}

レスポンスの中で最も重要なのは "status" フィールドです。

  • green: すべてのプライマリシャードとレプリカシャードが利用可能で正常な状態です。
  • yellow: すべてのプライマリシャードは利用可能ですが、一部のレプリカシャードが割り当てられていない状態です。機能は使えますが、冗長性が低下しています。
  • red: 一部のプライマリシャードが利用できない状態です。データの損失が発生している可能性があり、クラスタの一部または全体が利用できません。

入門段階では、少なくとも yellow または green であることを確認しましょう。

2. ノード情報取得

クラスタ内のノードに関する情報を取得します。_cat API は、人間が読みやすい表形式のレスポンスを返すため、簡単な状態確認に便利です。

リクエスト:

bash
GET /_cat/nodes?v

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/_cat/nodes?v"

  • ?v: ヘッダー行（カラム名）を表示するためのクエリパラメータです。

レスポンス例:

ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1 12 54 0 0.00 0.01 0.05 dilmrt * my-node

この出力から、ノードの IP アドレス、ヒープメモリ使用率、RAM 使用率、CPU 負荷、ロール、マスターノードかどうか、ノード名などの情報を読み取ることができます。

3. インデックスの操作

インデックスは、同じ種類のドキュメントをまとめて管理する論理的なコンテナです。リレーショナルデータベースのテーブルに相当します。

インデックスの作成

新しいインデックスを作成します。特に設定を指定しない場合、デフォルト設定で作成されます。

リクエスト:

bash
PUT /my_first_index

curl コマンドで実行する場合:

bash
curl -X PUT "localhost:9200/my_first_index?pretty"

レスポンス例:

json
{
"acknowledged": true,
"shards_acknowledged": true,
"index": "my_first_index"
}

"acknowledged": true は、クラスタがインデックス作成リクエストを受け付けたことを示します。

設定を指定してインデックスを作成（マッピング含む）

インデックス作成時に、シャード数、レプリカ数、そして重要な「マッピング」を設定できます。マッピングは、ドキュメント内の各フィールドがどのようなデータ型で、どのようにインデックスされるべきかを定義するスキーマのようなものです。

リクエスト:

bash
PUT /my_index_with_mapping
{
"settings": {
"index": {
"number_of_shards": 1,
"number_of_replicas": 1
}
},
"mappings": {
"properties": {
"title": {
"type": "text"
},
"publish_date": {
"type": "date"
},
"views": {
"type": "integer"
}
}
}
}

curl コマンドで実行する場合（リクエストボディを指定するには -H "Content-Type: application/json" ヘッダーと -d オプションを使います）:

bash
curl -X PUT "localhost:9200/my_index_with_mapping?pretty" -H "Content-Type: application/json" -d'
{
"settings": {
"index": {
"number_of_shards": 1,
"number_of_replicas": 1
}
},
"mappings": {
"properties": {
"title": {
"type": "text"
},
"publish_date": {
"type": "date"
},
"views": {
"type": "integer"
}
}
}
}
'

  • settings: インデックスの設定を指定します。number_of_shards はプライマリシャード数、number_of_replicas はレプリカシャード数です。本番環境ではこれらを適切に設定することが重要です。
  • mappings: マッピングを定義します。properties の中に、フィールド名とそのデータ型を指定します。
    • text: 全文検索に適した型です。内部でアナライザー（テキストを検索可能な単語に分解する処理）が適用されます。
    • keyword: 完全一致検索やソート、アグリゲーションに適した型です。アナライザーは適用されません。
    • date: 日付型です。範囲検索などに使えます。
    • integer, long, float, double: 数値型です。
    • boolean: 真偽値型です。
    • object: JSON オブジェクトをそのまま格納し、その内部フィールドもインデックスします。
    • nested: オブジェクトの配列を扱う際に、配列内の各オブジェクトを独立したドキュメントとしてインデックスするための型です。
    • その他、様々な型があります。

マッピングを明示的に定義しない場合、Elasticsearch は投入されたドキュメントの構造を見て自動的にマッピングを推測します（ダイナミックマッピング）。これは便利ですが、意図しないマッピングになる可能性もあるため、特に本番環境では重要なフィールドのマッピングは明示的に定義することが推奨されます。

インデックスの一覧表示

クラスタ内のすべてのインデックスとその基本的な情報を一覧表示します。_cat API を使います。

リクエスト:

bash
GET /_cat/indices?v

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/_cat/indices?v"

レスポンス例:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open .apm-custom-link T9g2kL-bSQe7-m3r0Qf95Q 1 0 0 0 208b 208b
green open .kibana_task_manager L4pW5b67Q3W0u8v6u8Jk8w 1 0 2 0 8.8kb 8.8kb
green open my_first_index Y-g4Yv23QfO1u9e3u1Iq0A 1 1 0 0 416b 208b
green open my_index_with_mapping Vm_iU2s_Qj2a6t4f1yZc1A 1 1 0 0 416b 208b

この出力から、各インデックスのヘルス状態、ステータス (open または close)、ドキュメント数、サイズなどを確認できます。

単一インデックスの情報取得

特定のインデックスの詳細情報（設定、マッピングなど）を取得します。

リクエスト:

bash
GET /my_index_with_mapping

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping?pretty"

レスポンス例:

json
{
"my_index_with_mapping": {
"aliases": {},
"mappings": {
"properties": {
"publish_date": {
"type": "date"
},
"title": {
"type": "text"
},
"views": {
"type": "integer"
}
}
},
"settings": {
"index": {
"creation_date": "1678886400000",
"number_of_shards": "1",
"number_of_replicas": "1",
"uuid": "Vm_iU2s_Qj2a6t4f1yZc1A",
"version": {
"created": "7090299"
},
"provided_name": "my_index_with_mapping"
}
}
}
}

このレスポンスから、インデックス作成時に設定したシャード数やレプリカ数、そしてマッピングが正しく反映されているかを確認できます。

インデックスの削除

指定したインデックスを削除します。削除されたデータは復旧できませんので注意が必要です。

リクエスト:

bash
DELETE /my_first_index

curl コマンドで実行する場合:

bash
curl -X DELETE "localhost:9200/my_first_index?pretty"

レスポンス例:

json
{
"acknowledged": true
}

"acknowledged": true で削除リクエストが受け付けられたことを示します。

4. ドキュメントの操作

ドキュメントは、Elasticsearch に格納される個々のデータ単位です。JSON 形式で表現され、インデックスの中に格納されます。リレーショナルデータベースの行（レコード）に相当しますが、スキーマレス（厳密には柔軟なスキーマ）である点が異なります。

ドキュメントのインデクシング（新規作成または更新）

ドキュメントをインデックスに登録します。指定した ID のドキュメントが既に存在すれば更新（上書き）、存在しなければ新規作成となります。

リクエスト:

bash
PUT /my_index_with_mapping/_doc/1
{
"title": "Elasticsearch API 入門",
"publish_date": "2023-03-15",
"views": 150
}

curl コマンドで実行する場合:

bash
curl -X PUT "localhost:9200/my_index_with_mapping/_doc/1?pretty" -H "Content-Type: application/json" -d'
{
"title": "Elasticsearch API 入門",
"publish_date": "2023-03-15",
"views": 150
}
'

  • /_doc/1: インデックス名 my_index_with_mapping の下の、ID が 1 のドキュメントを操作対象とします。_doc はドキュメント操作を示すパスです。

レスポンス例:

json
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}

  • _index, _type, _id: 登録されたドキュメントの場所と ID を示します。バージョン 7.x 以降では、_type は _doc に固定されることが推奨されています。
  • _version: ドキュメントのバージョンです。更新されるたびにインクリメントされます。
  • result: 操作結果を示します。新規作成なら "created", 更新なら "updated" となります。
  • _shards: シャードに関する情報です。
  • _seq_no, _primary_term: ドキュメントの楽観的ロックやレプリケーションに使われるシーケンス番号とプライマリタームです。
ドキュメントのインデクシング（自動 ID 生成）

ID を指定せずにドキュメントを登録することもできます。この場合、Elasticsearch が一意な ID を自動生成します。POST メソッドを使います。

リクエスト:

bash
POST /my_index_with_mapping/_doc
{
"title": "分散システムの基礎",
"publish_date": "2023-04-01",
"views": 80
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/my_index_with_mapping/_doc?pretty" -H "Content-Type: application/json" -d'
{
"title": "分散システムの基礎",
"publish_date": "2023-04-01",
"views": 80
}
'

レスポンス例:

json
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "abcXYZ...", # 自動生成された ID
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"_seq_no": 1,
"_primary_term": 1
}

_id フィールドに自動生成された ID が格納されていることがわかります。

ドキュメントの取得

指定した ID のドキュメントを取得します。

リクエスト:

bash
GET /my_index_with_mapping/_doc/1

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping/_doc/1?pretty"

レスポンス例:

json
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_version": 1,
"_seq_no": 0,
"_primary_term": 1,
"found": true,
"_source": {
"title": "Elasticsearch API 入門",
"publish_date": "2023-03-15",
"views": 150
}
}

  • found: ドキュメントが見つかったかどうかを示します。true なら見つかり、false なら見つかりません（この場合、ステータスコードは 404 Not Found となります）。
  • _source: 取得したドキュメントの元の JSON データです。デフォルトではこれが返されます。
ドキュメントの更新（部分更新）

既存のドキュメントの一部だけを更新したい場合に使います。POST メソッドと _update エンドポイントを使用します。

リクエスト:

ID が 1 のドキュメントの views フィールドを更新します。

bash
POST /my_index_with_mapping/_update/1
{
"doc": {
"views": 200
}
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/my_index_with_mapping/_update/1?pretty" -H "Content-Type: application/json" -d'
{
"doc": {
"views": 200
}
}
'

  • _update: 部分更新操作を示すエンドポイントです。
  • "doc": {...}: doc フィールドの中に、更新したいフィールドとその新しい値を指定します。指定したフィールドだけが更新され、他のフィールドは変更されません。

レスポンス例:

json
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_version": 2, # バージョンがインクリメントされている
"result": "updated", # 結果が "updated" になっている
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"_seq_no": 2,
"_primary_term": 1
}

部分更新ではなく、ドキュメント全体を置き換えたい場合は、同じ ID で PUT /{index_name}/_doc/{id} を実行すれば良いです。

ドキュメントの削除

指定した ID のドキュメントを削除します。

リクエスト:

bash
DELETE /my_index_with_mapping/_doc/1

curl コマンドで実行する場合:

bash
curl -X DELETE "localhost:9200/my_index_with_mapping/_doc/1?pretty"

レスポンス例:

json
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_version": 3, # 削除も新しいバージョンとして記録される
"result": "deleted", # 結果が "deleted"
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"_seq_no": 3,
"_primary_term": 1
}

"result": "deleted" で削除されたことを示します。存在しないドキュメントを削除しようとした場合、"result": "not_found" となり、ステータスコードは 404 になります。

ドキュメントの存在確認

ドキュメントを取得せずに、指定した ID のドキュメントが存在するかどうかだけを確認したい場合に HEAD メソッドを使います。レスポンスボディは返されず、ステータスコードで判断します。

リクエスト:

bash
HEAD /my_index_with_mapping/_doc/1

curl コマンドで実行する場合:

bash
curl -X HEAD -I "localhost:9200/my_index_with_mapping/_doc/1"

  • -I: curl でレスポンスヘッダーのみを表示するオプションです。

レスポンス:

  • ドキュメントが存在する場合: ステータスコード 200 OK
  • ドキュメントが存在しない場合: ステータスコード 404 Not Found

5. 基本的な検索

Elasticsearch の最も強力な機能の一つが検索です。ここでは、最も基本的な検索方法を紹介します。

URI 検索

簡単なクエリを指定する場合、URL のクエリパラメータとして検索条件を指定できます。手軽ですが、複雑なクエリには向きません。

リクエスト:

インデックス my_index_with_mapping から、title フィールドに “Elasticsearch” という単語を含むドキュメントを検索します。

bash
GET /my_index_with_mapping/_search?q=title:Elasticsearch&pretty

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping/_search?q=title:Elasticsearch&pretty"

  • _search: 検索操作を示すエンドポイントです。
  • ?q=...: URI 検索でクエリを指定するクエリパラメータです。フィールド名:検索語 の形式で指定します。複数の条件は AND, OR, NOT で結合できます。

レスポンス例:

json
{
"took": 1, # 検索にかかった時間（ミリ秒）
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 1, # ヒットしたドキュメント総数
"relation": "eq"
},
"max_score": 0.28768216, # 最も関連性の高いドキュメントのスコア
"hits": [ # ヒットしたドキュメントのリスト
{
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_score": 0.28768216, # ドキュメントの関連性スコア
"_source": { # 取得したドキュメントの元データ
"title": "Elasticsearch API 入門",
"publish_date": "2023-03-15",
"views": 150
}
}
]
}
}

レスポンスの hits セクションに検索結果が含まれます。

  • hits.total.value: 検索条件に一致したドキュメントの総数です。
  • hits.hits: 検索結果のドキュメントリストです。デフォルトでは最初の 10 件が返されます。各ドキュメントには _index, _type, _id, _score, _source が含まれます。
  • _score: ドキュメントと検索クエリとの関連性を示すスコアです。このスコアが高いほど、クエリとの関連性が高いと判断されます。デフォルトでは、結果はこのスコアの高い順にソートされます。
  • _source: 検索結果として取得したいドキュメントの元データです。デフォルトではドキュメント全体が返されますが、必要なフィールドだけを選択して取得することもできます（詳しくは後述の Query DSL で触れます）。
リクエストボディ検索 (Query DSL の基本)

より柔軟で強力な検索を行うには、リクエストボディに JSON 形式で検索条件を指定します。これを Query DSL (Domain Specific Language) と呼びます。ほとんどの検索は Query DSL を使って行われます。

リクエスト:

URI 検索と同じ条件を Query DSL で指定します。

bash
GET /my_index_with_mapping/_search
{
"query": {
"match": {
"title": "Elasticsearch"
}
}
}

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping/_search?pretty" -H "Content-Type: application/json" -d'
{
"query": {
"match": {
"title": "Elasticsearch"
}
}
}
'

  • "query": {...}: 検索条件を指定するためのルートフィールドです。
  • "match": {...}: テキストフィールドに対して、アナライズされた単語を含むドキュメントを検索する最も基本的なクエリ句です。

レスポンス:

URI 検索の場合と同様の形式のレスポンスが返されます。

Query DSL の利点は、単に単語を検索するだけでなく、複数の条件を組み合わせたり（AND, OR, NOT）、特定の範囲内の値を検索したり、曖昧一致や正規表現を使ったり、集計（Aggregation）を行ったりと、非常に複雑な検索・分析要件に対応できる点です。

Query DSL (検索クエリ) の基礎

Query DSL は Elasticsearch の検索の心臓部です。JSON 形式で検索条件を表現し、様々なクエリ句を組み合わせて使います。ここでは、入門者が知っておくべき基本的な Query DSL の構造と代表的なクエリ句を紹介します。

Query DSL の基本的な構造は以下のようになります。

json
{
"query": {
// クエリ句 (検索結果のスコアリングに影響)
},
"sort": [
// ソート条件
],
"from": 0, # スキップするドキュメント数
"size": 10, # 取得するドキュメント数
"_source": [ # 取得したいフィールド
"field1", "field2"
],
"aggregations": {
// 集計条件 (アグリゲーション)
}
}

query オブジェクトの中に、実際の検索条件となる様々な「クエリ句」を記述します。

Query DSL の構造

query オブジェクトの中には、通常一つまたは複数のクエリ句が含まれます。クエリ句には大きく分けて以下の種類があります。

  • リーフクエリ (Leaf Query): 単一のフィールドに対して特定の条件を指定するクエリ句（例: match, term, range）。
  • 複合クエリ (Compound Query): 複数のクエリ句を組み合わせて、AND, OR, NOT のような論理演算を行うクエリ句（例: bool）。

代表的なクエリ句

フルテキストクエリ (Full-text Queries)

テキストフィールドに対して、アナライズ（形態素解析など）された単語を検索します。関連性に基づいてスコアリングが行われます。

  • match クエリ:
    最も一般的なフルテキストクエリです。検索語をアナライズし、フィールドをアナライズした結果と比較します。

    json
    {
    "query": {
    "match": {
    "title": "Elasticsearch API"
    }
    }
    }
    このクエリは、title フィールドをアナライズした結果に “Elasticsearch” または “API” という単語が含まれるドキュメントを検索します。単語間の関係（AND か OR か）や許容する誤字脱字（fuzziness オプション）なども指定できます。

  • match_phrase クエリ:
    検索語がアナライズされた単語の「フレーズ」（連続した並び）として出現するドキュメントを検索します。単語の出現順序と近接性が重要になります。

    json
    {
    "query": {
    "match_phrase": {
    "title": "Elasticsearch API"
    }
    }
    }
    このクエリは、title フィールドに “Elasticsearch” の直後に “API” という単語が出現するドキュメントを検索します。

タームレベルクエリ (Term-level Queries)

フィールドの正確な値（アナライズされていない、または keyword 型などでインデックスされた値）を検索します。スコアリングは行われず、単に一致するかしないかで判断されます（したがって、filter コンテキストで使うのが一般的）。

  • term クエリ:
    単一の正確な値を検索します。テキストフィールドに使うと、指定した検索語をアナライズせずにフィールドの正確な値と比較するため、期待通りに動作しないことが多いです（テキストフィールドはアナライズされて複数の単語になるため）。keyword, numeric, date 型などのフィールドに使うのが適切です。

    json
    {
    "query": {
    "term": {
    "views": 150
    }
    }
    }
    views フィールドの値が 150 と正確に一致するドキュメントを検索します。

  • terms クエリ:
    複数の正確な値のいずれかに一致するドキュメントを検索します（OR 条件）。

    json
    {
    "query": {
    "terms": {
    "views": [150, 80]
    }
    }
    }
    views フィールドの値が 150 または 80 のドキュメントを検索します。

  • range クエリ:
    数値や日付の範囲を指定して検索します。

    json
    {
    "query": {
    "range": {
    "publish_date": {
    "gte": "2023-01-01", # 以上 (Greater Than or Equal to)
    "lte": "2023-12-31" # 以下 (Less Than or Equal to)
    }
    }
    }
    }
    publish_date が 2023 年中のドキュメントを検索します。gt (より大きい), lt (より小さい), gte, lte が使えます。

  • exists クエリ:
    特定のフィールドが存在するドキュメントを検索します。

    json
    {
    "query": {
    "exists": {
    "field": "views"
    }
    }
    }
    views フィールドを持つドキュメントを検索します。

  • missing クエリ (非推奨、exists + bool/must_not を推奨):
    特定のフィールドが存在しないドキュメントを検索します。現在は bool クエリと exists クエリを組み合わせて must_not 条件を使うのが推奨されています。

    json
    {
    "query": {
    "bool": {
    "must_not": {
    "exists": {
    "field": "views"
    }
    }
    }
    }
    }
    views フィールドを持たないドキュメントを検索します。

複合クエリ (Compound Queries)

複数のクエリ句を論理的に組み合わせるために使われます。

  • bool クエリ:
    最も重要でよく使われる複合クエリです。以下の要素を組み合わせて複雑な条件を表現できます。

    • must: 子クエリすべてが一致する必要がある（AND 条件）。スコアリングに影響します。
    • filter: 子クエリすべてが一致する必要がある（AND 条件）。スコアリングには影響しません（高速なフィルタリングに適しています）。
    • should: 子クエリのいずれかに一致する必要がある（OR 条件）。スコアリングに影響します。一致した should クエリが多いほどスコアが高くなります。
    • must_not: 子クエリのいずれも一致してはならない（NOT 条件）。スコアリングには影響しません。

    例: タイトルに “Elasticsearch” または “API” を含み、かつ views が 100 より大きいドキュメントを検索。

    json
    {
    "query": {
    "bool": {
    "should": [
    { "match": { "title": "Elasticsearch" } },
    { "match": { "title": "API" } }
    ],
    "minimum_should_match": 1, # should のうち最低いくつ一致する必要があるか
    "filter": [
    {
    "range": {
    "views": {
    "gt": 100
    }
    }
    }
    ]
    }
    }
    }

    must と filter の使い分けは重要です。検索結果の関連性（スコア）に基づいてランキングしたい場合は must を使い、単に条件に合致するドキュメントを絞り込みたいだけでスコアは不要な場合は filter を使います。filter はキャッシュされるため、同じフィルタ条件が繰り返し使われる場合にパフォーマンス上有利です。

  • dis_max クエリ:
    複数のクエリを実行し、そのうち最高のスコアを持つクエリのスコアを採用します。異なるフィールドに対して同じ検索語で検索し、いずれかのフィールドで強く一致するドキュメントを優先したい場合などに使われます。

フィルタコンテキスト vs クエリコンテキスト

bool クエリの must, should と filter, must_not の違いで触れましたが、Elasticsearch の検索には「クエリコンテキスト」と「フィルタコンテキスト」という重要な概念があります。

  • クエリコンテキスト (Query Context): ドキュメントが検索条件に「一致するかどうか」と「どの程度一致するか（スコア）」の両方を考慮します。関連性スコアに基づいて結果をランク付けしたい場合に用います（例: match, match_phrase, bool の must, should）。
  • フィルタコンテキスト (Filter Context): ドキュメントが検索条件に「一致するかどうか」だけを考慮します。スコアリングは行われず、単に一致するドキュメントを絞り込むために用います。結果の順序はスコアに依存しません。フィルタコンテキストで実行されるクエリはキャッシュされやすいため、パフォーマンスが向上する可能性があります（例: term, terms, range, exists, bool の filter, must_not）。

パフォーマンスの観点から、可能な限りフィルタコンテキストを使用することが推奨されます。例えば、「カテゴリが ‘A’ で、かつタイトルに ‘Elasticsearch’ を含むドキュメント」を検索する場合、「カテゴリが ‘A’」という条件はフィルタコンテキスト (bool の filter) で、「タイトルに ‘Elasticsearch’ を含む」という条件はクエリコンテキスト (bool の must または should) で記述すると効率的です。

スコアリング (_score)

検索結果に含まれる _score は、各ドキュメントが検索クエリにどの程度関連しているかを示す値です。デフォルトでは、検索結果はこのスコアの高い順に並べられます。

スコアの計算方法は、使用するクエリ句やフィールドのマッピング（特にアナライザー）によって異なりますが、一般的には TF-IDF (Term Frequency-Inverse Document Frequency) や BM25 といったアルゴリズムに基づいています。これは、検索語がドキュメント内で多く出現するほど、また検索語がインデックス全体ではあまり出現しない（珍しい）ほど、そのドキュメントのスコアが高くなる傾向があるという考え方です。

タームレベルクエリやフィルタコンテキストで実行されるクエリは、スコアリングを行わないため、一致するドキュメントのスコアは通常 0 または 1 のような固定値になります（ブースト指定がない場合など）。

その他の Query DSL オプション

Query DSL では、検索条件だけでなく、検索結果の表示方法や追加情報についても細かく制御できます。

  • size: 返すドキュメントの最大数を指定します（デフォルト: 10）。
  • from: 結果の何件目から返すかを指定します（デフォルト: 0）。ページネーションに使います (from = (ページ番号 - 1) * size)。

  • _source: 結果に含めるドキュメントのソースフィールドを指定します。文字列の配列で指定します。省略するとすべてのフィールドが含まれます。false にするとソースフィールドは含まれません。

    json
    {
    "_source": ["title", "publish_date"],
    "query": {
    "match": {
    "title": "Elasticsearch"
    }
    }
    }

  • sort: 検索結果を特定のフィールドでソートします。デフォルトは _score の降順です。

    json
    {
    "query": {
    "match": {
    "title": "Elasticsearch"
    }
    },
    "sort": [
    { "views": { "order": "desc" } }, # views の降順
    { "publish_date": { "order": "asc" } } # publish_date の昇順
    ]
    }
    _score でソートしたい場合は "_score" を指定します。注意点として、text 型フィールドはデフォルトでソートできません（ソートにはフィールドの正確な値が必要なため）。ソートしたい場合は、マッピングで fielddata: true を有効にするか、keyword サブフィールドを作成する必要があります（fielddata: true はメモリを多く消費するため注意が必要です）。

  • highlight: 検索語がヒットした部分をハイライトして結果に含めます。

    json
    {
    "query": {
    "match": {
    "title": "Elasticsearch"
    }
    },
    "highlight": {
    "fields": {
    "title": {}
    }
    }
    }
    レスポンスの hits.hits 内に highlight フィールドが追加され、ハイライトされたテキスト断片が含まれます。

これらは Query DSL の一部ですが、これらを組み合わせることで、ほとんどの基本的な検索要件を満たすことができます。

その他の重要な API

基本的な操作と検索以外にも、Elasticsearch には多くの便利な API があります。ここでは、入門者が次に知っておきたいいくつかの重要な API を紹介します。

1. Bulk API

複数のドキュメント操作（インデクシング、更新、削除）を単一のリクエストでまとめて実行するための API です。個別の API コールを繰り返すよりもはるかに効率的で、大量のデータを扱う際には必須です。

リクエスト:

Bulk API のリクエストボディは特殊な形式です。各行が JSON オブジェクトであり、奇数行にアクションとメタデータ、偶数行にドキュメント本体（インデクシングや更新の場合）を記述します。各行は改行文字 (\n) で区切られます。

POST /_bulk
{ "index" : { "_index" : "my_index_with_mapping", "_id" : "2" } }
{ "title" : "Elasticsearch Aggregations", "publish_date": "2023-05-01", "views": 50 }
{ "create" : { "_index" : "my_index_with_mapping", "_id" : "3" } }
{ "title" : "Elasticsearch Mapping", "publish_date": "2023-05-10", "views": 60 }
{ "update" : {"_index" : "my_index_with_mapping", "_id" : "1"} }
{ "doc" : {"views" : 250} }
{ "delete" : { "_index" : "my_index_with_mapping", "_id" : "abcXYZ..." } } # 自動生成IDのドキュメント

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/_bulk?pretty" -H "Content-Type: application/json" --data-binary @bulk_data.json

または、ヒアドキュメントを使う場合:

bash
curl -X POST "localhost:9200/_bulk?pretty" -H "Content-Type: application/json" --data-binary '
{ "index" : { "_index" : "my_index_with_mapping", "_id" : "2" } }
{ "title" : "Elasticsearch Aggregations", "publish_date": "2023-05-01", "views": 50 }
{ "create" : { "_index" : "my_index_with_mapping", "_id" : "3" } }
{ "title" : "Elasticsearch Mapping", "publish_date": "2023-05-10", "views": 60 }
{ "update" : {"_index" : "my_index_with_mapping", "_id" : "1"} }
{ "doc" : {"views" : 250} }
{ "delete" : { "_index" : "my_index_with_mapping", "_id" : "abcXYZ..." } }
'

  • --data-binary: curl でリクエストボディを送信する際に、改行などをそのまま送信するために使います。
  • 各行の末尾には必ず改行文字が必要です。ファイルから読み込む --data-binary @filename がよく使われます。

レスポンス例:

レスポンスも JSON 形式で、各操作の結果がリストで返されます。

json
{
"took": 21,
"errors": false, # エラーが発生したかどうか
"items": [ # 各操作の結果リスト
{
"index": {
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "2",
"_version": 1,
"result": "created",
"_shards": { ... },
"_seq_no": 4,
"_primary_term": 1,
"status": 201 # HTTP ステータスコード
}
},
{
"create": {
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "3",
"_version": 1,
"result": "created",
"_shards": { ... },
"_seq_no": 5,
"_primary_term": 1,
"status": 201
}
},
{
"update": {
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "1",
"_version": 4,
"result": "updated",
"_shards": { ... },
"_seq_no": 6,
"_primary_term": 1,
"status": 200
}
},
{
"delete": {
"_index": "my_index_with_mapping",
"_type": "_doc",
"_id": "abcXYZ...",
"_version": 2,
"result": "deleted",
"_shards": { ... },
"_seq_no": 7,
"_primary_term": 1,
"status": 200
}
}
]
}
"errors": false であっても、個別の操作でエラーが発生している可能性があるので、items リスト内の各操作の結果を確認する必要があります。各結果オブジェクト内の "status" フィールドがその操作の HTTP ステータスコードを示します。

2. Mapping API

インデックスのマッピングを確認したり、既存のマッピングに新しいフィールドを追加したりする際に使用します。既存フィールドのマッピングは原則変更できません。

マッピングの取得

指定したインデックスのマッピング情報を取得します。

リクエスト:

bash
GET /my_index_with_mapping/_mapping?pretty

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping/_mapping?pretty"

レスポンス例:

インデックス作成時に設定したマッピング情報が返されます。

json
{
"my_index_with_mapping": {
"mappings": {
"properties": {
"publish_date": {
"type": "date"
},
"title": {
"type": "text"
},
"views": {
"type": "integer"
}
}
}
}
}

新しいフィールドのマッピング追加

既存のインデックスに新しいフィールドのマッピングを追加します。

リクエスト:

インデックス my_index_with_mapping に tags フィールド（keyword 型）を追加します。

bash
PUT /my_index_with_mapping/_mapping
{
"properties": {
"tags": {
"type": "keyword"
}
}
}

curl コマンドで実行する場合:

bash
curl -X PUT "localhost:9200/my_index_with_mapping/_mapping?pretty" -H "Content-Type: application/json" -d'
{
"properties": {
"tags": {
"type": "keyword"
}
}
}
'

レスポンス例:

json
{
"acknowledged": true
}

これで、以降このインデックスに投入されるドキュメントに含まれる tags フィールドは keyword 型として扱われるようになります（以前に投入されたドキュメントには影響しませんが、その後の更新や再インデクシングで反映されます）。

3. Analyze API

指定したテキストが、特定のアナライザーによってどのようにトークン（検索可能な単語）に分解されるかを確認できる便利なツールです。マッピングで指定したアナライザーや、組み込みのアナライザーの挙動をデバッグするのに役立ちます。

リクエスト:

デフォルトのアナライザー（スタンダードアナライザー）で “Quick Brown Fox!” というテキストを分析します。

bash
POST /_analyze
{
"text": "Quick Brown Fox!"
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/_analyze?pretty" -H "Content-Type: application/json" -d'
{
"text": "Quick Brown Fox!"
}
'

  • _analyze: Analyze API のエンドポイントです。

レスポンス例:

json
{
"tokens": [
{
"token": "quick",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "brown",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "fox",
"start_offset": 12,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 2
}
]
}
テキストが “quick”, “brown”, “fox” の 3 つのトークンに分解され、すべて小文字化されていることがわかります。句読点も取り除かれています。

特定インデックスの特定フィールドに設定されているアナライザーを使いたい場合は、以下のように指定します。

bash
POST /_analyze
{
"field": "my_index_with_mapping.title", # インデックス名.フィールド名
"text": "Elasticsearch API 入門"
}

これにより、そのフィールドに実際に設定されているアナライザー（text 型フィールドのデフォルトはスタンダードアナライザー）での分析結果を確認できます。

4. Count API

検索を実行せずに、検索条件に一致するドキュメントの数を高速に取得できます。

リクエスト:

インデックス my_index_with_mapping のドキュメント総数を取得します。

bash
GET /my_index_with_mapping/_count?pretty

curl コマンドで実行する場合:

bash
curl -X GET "localhost:9200/my_index_with_mapping/_count?pretty"

Query DSL を使って特定の条件に一致するドキュメント数を取得することもできます。

bash
POST /my_index_with_mapping/_count?pretty
{
"query": {
"range": {
"views": {
"gt": 100
}
}
}
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/my_index_with_mapping/_count?pretty" -H "Content-Type: application/json" -d'
{
"query": {
"range": {
"views": {
"gt": 100
}
}
}
}
'

レスポンス例:

json
{
"count": 2, # 条件に一致するドキュメント数
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
}
}

検索 API (_search) も hits.total.value で件数を返しますが、Count API は件数だけを返すため、検索結果の取得が不要な場合は Count API の方が高速です。

5. Update By Query / Delete By Query API

指定した検索クエリに一致する複数のドキュメントを、一括で更新または削除します。Bulk API とは異なり、更新/削除対象のドキュメント ID を事前に知っている必要がなく、クエリで指定できる点が便利です。

リクエスト:

インデックス my_index_with_mapping で、views が 100 より小さいすべてのドキュメントの views フィールドに 50 を加算します。

bash
POST /my_index_with_mapping/_update_by_query?pretty
{
"script": {
"source": "ctx._source.views += 50", # Painless スクリプトで更新処理を記述
"lang": "painless"
},
"query": {
"range": {
"views": {
"lt": 100
}
}
}
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/my_index_with_mapping/_update_by_query?pretty" -H "Content-Type: application/json" -d'
{
"script": {
"source": "ctx._source.views += 50",
"lang": "painless"
},
"query": {
"range": {
"views": {
"lt": 100
}
}
}
}
'

  • _update_by_query: クエリによる一括更新のエンドポイントです。
  • script: 更新処理を記述します。Elasticsearch のスクリプト言語である Painless がよく使われます。ctx._source で現在のドキュメントのソースデータにアクセスできます。
  • query: 更新対象のドキュメントを指定するクエリ句です。

リクエスト:

インデックス my_index_with_mapping で、publish_date が 2022 年よりも前のすべてのドキュメントを削除します。

bash
POST /my_index_with_mapping/_delete_by_query?pretty
{
"query": {
"range": {
"publish_date": {
"lt": "2022-01-01"
}
}
}
}

curl コマンドで実行する場合:

bash
curl -X POST "localhost:9200/my_index_with_mapping/_delete_by_query?pretty" -H "Content-Type: application/json" -d'
{
"query": {
"range": {
"publish_date": {
"lt": "2022-01-01"
}
}
}
}
'

  • _delete_by_query: クエリによる一括削除のエンドポイントです。
  • query: 削除対象のドキュメントを指定するクエリ句です。

これらの API は、クエリに一致するドキュメントが多い場合、処理に時間がかかることがあります。非同期で実行することも可能です。

実践的な考慮事項

Elasticsearch API を実際に利用する上で、いくつか知っておくと良い実践的な考慮事項があります。

エラーハンドリング

API コールが常に成功するとは限りません。リクエストの形式が誤っている、対象のインデックスやドキュメントが存在しない、クラスタ内部でエラーが発生したなど、様々な理由でエラーが発生します。

  • HTTP ステータスコードを確認する: API レスポンスの HTTP ステータスコードは、結果を判断する上で最も重要です。
    • 2xx (例: 200 OK, 201 Created): 成功。
    • 4xx (例: 400 Bad Request, 404 Not Found): クライアント側のエラー（リクエストの誤り、リソースの不在など）。
    • 5xx (例: 500 Internal Server Error): サーバー側のエラー（クラスタの問題など）。

  • レスポンスボディを確認する: エラーが発生した場合、レスポンスボディには通常、エラーに関する詳細情報が含まれます。JSON 形式で "error" フィールドに含まれることが多いです。

    例: 存在しないインデックスを操作しようとした場合

    json
    {
    "error": {
    "root_cause": [
    {
    "type": "index_not_found_exception",
    "reason": "no such index [non_existent_index]",
    "index_uuid": "_na_",
    "index": "non_existent_index"
    }
    ],
    "type": "index_not_found_exception",
    "reason": "no such index [non_existent_index]",
    "index_uuid": "_na_",
    "index": "non_existent_index"
    },
    "status": 404 # ステータスコードは 404
    }
    "error" オブジェクトには、エラーのタイプ ("type"), 理由 ("reason"), 根本原因 ("root_cause") などが含まれます。これらの情報を元に、エラーの原因を特定して対処します。

認証と認可 (X-Pack Security の概要)

デフォルトの Elasticsearch は認証なしで誰でも API にアクセスできてしまいます。本番環境で Elasticsearch を利用する場合、セキュリティは非常に重要です。Elasticsearch には X-Pack Security というセキュリティ機能があり、API アクセスを制限できます。

  • 認証 (Authentication): API を呼び出すユーザーやシステムが誰であるかを確認するプロセスです。ベーシック認証、API キー、証明書認証など、様々な方法がサポートされています。
  • 認可 (Authorization): 認証されたユーザーが、特定のリソース（インデックスなど）に対して特定の操作（読み取り、書き込みなど）を実行する権限を持っているかを確認するプロセスです。ロールベースアクセス制御 (RBAC) によって管理されます。

これらのセキュリティ機能は、通常、有料ライセンスまたは Basic レベル以上のライセンスで利用できます。入門段階ではセキュリティなしでローカルで試すことが多いですが、実運用では必ずセキュリティを有効にすることを検討してください。API コール時には、認証情報（ヘッダーなど）を付加する必要があります。

API クライアントライブラリの利用

curl や Kibana Dev Tools は API の動作確認や手動での操作には便利ですが、アプリケーションから Elasticsearch を操作する場合、各プログラミング言語で提供されている公式または非公式のクライアントライブラリを利用するのが一般的です。

  • Python, Java, JavaScript (Node.js), Go, Ruby, PHP, .NET など、主要な言語のクライアントライブラリが提供されています。
  • これらのライブラリは、HTTP 通信の詳細を抽象化し、よりオブジェクト指向的または言語の慣習に沿った形で API を呼び出せるようにしてくれます。
  • エラー処理、接続管理、リトライ、バランシングなどもライブラリ側で面倒を見てくれるため、開発効率と信頼性が向上します。

例えば Python の elasticsearch クライアントを使う場合、ドキュメントのインデクシングは以下のように記述できます。

“`python
from elasticsearch import Elasticsearch

Elasticsearch クライアントの初期化

ローカルのデフォルト設定ならホスト指定は不要なことも

es = Elasticsearch([{‘host’: ‘localhost’, ‘port’: 9200}])

ドキュメントのインデクシング

doc = {
‘title’: ‘Elasticsearch API 入門 (Python)’,
‘publish_date’: ‘2024-01-01’,
‘views’: 300
}
response = es.index(index=’my_index_with_mapping’, id=4, document=doc)

print(response[‘result’]) # ‘created’ or ‘updated’

ドキュメントの取得

response = es.get(index=’my_index_with_mapping’, id=4)
print(response[‘_source’])

検索

search_body = {
“query”: {
“match”: {
“title”: “Python”
}
}
}
response = es.search(index=’my_index_with_mapping’, body=search_body)
print(f”Got {response[‘hits’][‘total’][‘value’]} Hits:”)
for hit in response[‘hits’][‘hits’]:
print(f”{hit[‘_score’]}: {hit[‘_source’][‘title’]}”)
“`

クライアントライブラリを使うことで、より構造化されたコードで Elasticsearch API を利用できます。

Kibana Dev Tools の活用

Kibana は Elasticsearch の公式 UI ツールであり、その中に含まれる Dev Tools は、Elasticsearch API を手軽に実行して試すための非常に強力なツールです。

  • HTTP リクエストをエディタに記述し、実行ボタンを押すだけで API を呼び出せます。
  • リクエストやレスポンスの JSON のシンタックスハイライトや整形機能があります。
  • 過去に実行したリクエストの履歴を確認できます。
  • GET /_cluster/health のような記述でよく、ホスト名やポート番号を毎回記述する必要がありません。
  • _search API のリクエストボディを書く際に補完機能が働くなど、非常に便利です。

この記事で紹介した curl コマンドの例は、ほとんど Kibana Dev Tools でそのまま実行できます（curl -X GET "..." の代わりに GET ... と書けば良いです）。API の学習段階では、Kibana Dev Tools を積極的に活用することをお勧めします。

バージョン間の互換性

Elasticsearch は活発に開発が進められており、バージョンアップによって API に変更が加えられることがあります。

  • 特にメジャーバージョンアップ（例: 6.x から 7.x, 7.x から 8.x）では、非推奨になった API が削除されたり、新しい API が追加されたり、既存 API の挙動が変わったりすることがあります。
  • 例えば、バージョン 7.x でドキュメントの Type (_type) が非推奨となり、8.x で完全に削除されました（Type は常に _doc となります）。この記事の例はバージョン 7.x 以降を想定していますが、古いバージョンのドキュメントや記事を参照する場合は注意が必要です。
  • API のドキュメントには、その API がどのバージョンで導入され、非推奨になったか、削除されたかなどの情報が含まれています。
  • 公式ドキュメントを参照する際は、必ず使用している Elasticsearch のバージョンに合ったドキュメントを参照するようにしてください。

まとめと次のステップ

この記事では、Elasticsearch API の入門者向けに、その基礎知識から基本的な操作、そして検索の核となる Query DSL について詳細に解説しました。

  • Elasticsearch API が RESTful であること、そして HTTP メソッドとエンドポイントの役割を理解しました。
  • _cluster/health, _cat/indices といったクラスタやインデックスの状態確認 API を試しました。
  • PUT, POST, GET, DELETE, HEAD メソッドを使って、インデックスの作成・削除、ドキュメントのインデクシング・取得・更新・削除といった基本的な CRUD 操作を行いました。
  • 簡単な URI 検索から、より複雑な Query DSL を使ったリクエストボディ検索の基本を学び、代表的なクエリ句（match, term, range, bool など）とその使い分け（クエリコンテキスト vs フィルタコンテキスト）を理解しました。
  • _bulk API による一括操作、_mapping API によるマッピングの確認・更新、_analyze API によるテキスト分析、_count API による件数取得、そして _update_by_query, _delete_by_query といった便利な API についても触れました。
  • 実践的な観点から、エラーハンドリング、セキュリティの重要性、クライアントライブラリの利用、Kibana Dev Tools の活用、そしてバージョン間の互換性についても言及しました。

これで、Elasticsearch API を使ってデータの操作や基本的な検索を行うための土台が築けました。しかし、Elasticsearch の機能は非常に広範です。次に学習すべきステップとしては、以下のようなテーマがあります。

  • Aggregation (集計): 検索結果を集計して様々な分析を行うための強力な機能です。売上集計、人気タグランキング、価格帯別件数など、ビジネスインテリジェンスの基盤となります。
  • More Like This (似たようなドキュメント検索): 特定のドキュメントに似たドキュメントを検索する機能です。
  • Suggest (サジェスト): 入力中のクエリに対して、候補となるクエリや語句を提示する機能です。
  • Aliases (エイリアス): 一つまたは複数のインデックスに別名を付ける機能です。インデックスの切り替えなどをダウンタイムなしで行うために重要です。
  • Index Templates (インデックステンプレート): 新しいインデックスが作成される際に自動的に適用される設定やマッピングを定義する機能です。
  • Data Streams (データストリーム): ログや時系列データなど、追記型のデータを扱うための便利な機能です。
  • Snapshot and Restore (スナップショットとリストア): クラスタのバックアップと復元に関する API です。
  • Cluster Management API (クラスタ管理 API): ノード管理、シャード再配置など、より高度なクラスタ運用に関する API です。

これらの高度な機能についても、まずは公式ドキュメントを参照しながら、API を使って実際に試してみることをお勧めします。

最も重要なのは、実際に手を動かして練習することです。Kibana Dev Tools や curl、あるいは選んだプログラミング言語のクライアントライブラリを使って、様々な API を呼び出し、レスポンスを確認してみてください。公式ドキュメントは最も正確で最新の情報源ですが、量が多いので、この記事で学んだ基礎を元に、必要な情報をピンポイントで探していくと良いでしょう。

Elasticsearch API の世界は奥深いですが、一歩ずつ学び進めることで、その強力な機能を自在に活用できるようになります。この記事が、あなたの Elasticsearch 学習の助けとなれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール