【初心者向け】Elasticsearchとは? データ分析・全文検索の基本を徹底解説
インターネット上には膨大な情報が溢れています。Webサイトの記事、商品カタログ、ログデータ、センサー情報など、その種類も量も日々増え続けています。これらの情報を効率的に探し出し、分析することは、現代のビジネスや研究において非常に重要です。
伝統的なデータベース(RDB)でも情報を蓄積・検索することはできますが、特に「あいまいなキーワードで検索したい(全文検索)」や「大量のデータをリアルタイムに分析したい」といったニーズに対しては、限界があります。
そこで登場するのが Elasticsearch です。
Elasticsearchは、これらの現代的な情報活用ニーズに応えるために設計された、パワフルな検索・分析エンジンです。この記事では、Elasticsearchが何であり、なぜ多くの場面で利用されているのか、そしてその基本的な仕組みや使い方について、初心者の方にも分かりやすく、網羅的に解説していきます。
約5000語というボリュームで、Elasticsearchの基本をじっくり理解していただける内容を目指します。さあ、Elasticsearchの世界に足を踏み入れてみましょう。
第1章 Elasticsearchとは何か?
まず、Elasticsearchが一体何者なのかをシンプルに定義しましょう。
Elasticsearchは、Apache Luceneという強力な全文検索ライブラリをベースにして作られた、分散型のRESTfulな検索・分析エンジンです。
…と聞いても、初心者の方は「???」となるかもしれませんね。大丈夫です。一つずつ紐解いていきましょう。
1.1 シンプルな定義:検索と分析に特化したデータベースのようなもの
Elasticsearchを最もシンプルに理解するなら、「大量のデータから素早く情報を探し出したり、集計・分析したりすることに特化したデータベースのようなもの」と捉えるのが良いでしょう。
ただし、従来のデータベース(RDB、例えばMySQLやPostgreSQLなど)とは得意なことが少し違います。RDBは、構造化されたデータを正確に保存し、厳密な条件に基づいてデータを取得したり、整合性を保ったりすることに優れています。一方、Elasticsearchは、構造化されていないデータや半構造化されたデータも含め、全文検索(キーワードであいまいな検索をする)やリアルタイムでの高速なデータ集計・分析に非常に優れています。
例えるなら、RDBが「図書館の蔵書目録(ISBNや書名、著者名などで厳密に検索)」だとすると、Elasticsearchは「インターネット上の検索エンジン(キーワードで関連性の高い情報を検索)」や「大量のアンケート結果を素早く集計・分析するツール」のようなイメージです。
1.2 キーワード解説:分散型、RESTful、検索・分析エンジン
先ほどの定義に出てきたキーワードを解説します。
-
分散型(Distributed):
Elasticsearchは、最初から複数のコンピュータ(サーバー)に分散してデータを保存・処理することを前提に設計されています。これにより、- 大量のデータを扱える: 1台のサーバーでは処理しきれないデータ量も、複数のサーバーに分散することで対応できます。
- 高い可用性(High Availability): あるサーバーが故障しても、システム全体が停止することなく稼働を続けられます。データのコピーを別のサーバーに持っておくことで、故障に備えます。
- スケールアウトしやすい: データ量や負荷が増加した場合、サーバーを追加することで簡単に処理能力を増強できます。
これは、後述する「クラスター」「ノード」「シャード」「レプリカ」といったアーキテクチャの根幹に関わる非常に重要な特徴です。
-
RESTful:
Elasticsearchとのデータのやり取りは、HTTPプロトコルを使って行われます。WebブラウザでWebサイトを見るのと同じような仕組みで、データを登録したり、検索したり、削除したりできます。具体的には、GET、POST、PUT、DELETEといったHTTPメソッドを使って、JSON形式のデータを送受信します。これにより、様々なプログラミング言語やツールから簡単にElasticsearchを操作できます。 -
検索・分析エンジン:
Elasticsearchの主な目的は、データに対して高速な検索と分析を実行することです。- 検索(Search): 特定のキーワードや条件に合致するドキュメント(データ単位)を見つけ出します。特に全文検索に強く、単語の類似性や関連性に基づいた検索が可能です。
- 分析(Analytics): データのパターンを発見したり、統計情報を計算したりします。例えば、「過去1時間のWebサイトへのアクセス数を、ブラウザの種類別に集計する」といったことが高速にできます。これは「アグリゲーション(Aggregation)」と呼ばれる機能によって実現されます。
1.3 なぜElasticsearchが生まれたのか? 伝統的な技術の限界
Elasticsearchがこれほど普及した背景には、従来の技術では難しかった課題を解決できたことがあります。
-
リレーショナルデータベース (RDB) の限界:
RDBは構造化されたデータを扱うのは得意ですが、全文検索は苦手です。キーワードであいまいな検索をしようとすると、LIKE検索などを使うことになりますが、データ量が増えると極端に遅くなりがちです。また、非構造化データや半構造化データ(例えば、フォーマットが一定しないログデータなど)を扱うのも得意ではありません。スケールアウト(サーバーの追加による性能向上)もRDBでは比較的難しい場合が多いです。 -
従来の全文検索システムの複雑さ:
Luceneのような全文検索ライブラリは強力ですが、それを単体で使いこなすには、プログラムを書く必要があり、分散処理や可用性の確保を自分自身で実装する必要がありました。これは非常に難易度が高く、多くの開発者にとって障壁となっていました。
Elasticsearchは、Luceneの強力な検索機能を基盤としつつ、データの分散、スケーラビリティ、可用性の確保、そして開発者にとって使いやすいRESTful APIを提供することで、これらの課題を一挙に解決しました。これにより、誰でも比較的簡単に強力な検索・分析システムを構築できるようになったのです。
1.4 Elasticsearchはどのようなデータが得意か?
Elasticsearchは、特定の構造を持たない、あるいは構造が変化しやすい様々な種類のデータを扱うのに適しています。
- テキストデータ: Webサイトのコンテンツ、ドキュメントファイル、メール、SNSの投稿など、全文検索の対象となるあらゆるテキストデータ。
- ログデータ: サーバーログ、アプリケーションログ、アクセスログなど。大量に発生し、リアルタイムでの監視や分析が求められるデータ。
- メトリックデータ: システムのパフォーマンス情報、センサーデータ、IoTデバイスからのデータなど。時系列での分析や異常検知に利用されます。
- 位置情報データ: GPSデータなど。特定の範囲内の情報を検索したり、距離に基づいた分析を行ったりできます。
- 商品カタログやドキュメントのメタデータ: 構造化されたデータに加えて、説明文などのテキスト情報も一緒に扱う場合。
要するに、「大量にあって、検索や分析のニーズがあり、従来のRDBでは扱いづらい」ようなデータは、Elasticsearchの得意とするところです。
第2章 なぜElasticsearchが必要なのか? 具体的な利用シーン
Elasticsearchがどのようなシステムで、どのようなデータが得意なのかが分かりました。では、具体的にどのような場面でElasticsearchは活躍しているのでしょうか? いくつかの代表的な利用シーンを見てみましょう。
2.1 全文検索(Full-Text Search)
これはElasticsearchの最も代表的な用途です。
- ECサイトの商品検索:
ユーザーが入力したキーワード(例えば「夏 ワンピース カジュアル 花柄」)に対して、商品のタイトル、説明文、タグなどから関連性の高い商品を素早く探し出します。単なるキーワード一致だけでなく、類義語や単語の組み合わせ、重要度(人気度など)を考慮した関連性スコアに基づいて、最適な順序で結果を表示することができます。これはRDBのLIKE検索では非常に難しい処理です。 - Webサイト内検索:
ブログ記事、ニュース記事、ヘルプドキュメントなど、Webサイト上の大量のテキストコンテンツから、ユーザーが求める情報を探し出す機能を提供します。 - 社内文書検索:
企業内のドキュメント管理システムにおいて、Word、PDFなどの文書ファイルの内容をインデックス化し、キーワードで横断的に検索できるようにします。 - 顧客サポートシステム:
過去の問い合わせ履歴やFAQデータベースから、類似する質問や回答を検索し、サポート担当者の業務効率を向上させます。
Elasticsearchの全文検索は、単にキーワードを含むか含まないかだけでなく、検索語の重要度、出現頻度、単語間の距離などを考慮して、関連性の高い順に結果を返すことができるのが大きな強みです。
2.2 ログおよびメトリックデータの分析 (ELK Stack / Elastic Stack)
Elasticsearchが最も大規模に利用されている領域の一つが、これです。
- サーバー・アプリケーションログの集中管理と可視化:
複数のサーバーやアプリケーションから吐き出される大量のログデータをElasticsearchに集約し、リアルタイムで検索・分析・可視化します。例えば、「過去5分間に発生したエラーログを全て表示する」「特定のユーザーに関連する一連のログを追跡する」といったことが容易になります。 - システムパフォーマンスの監視:
サーバーのCPU使用率、メモリ使用量、ネットワークトラフィック、アプリケーションのレスポンスタイムなどのメトリックデータをElasticsearchに収集し、 Kibana(後述するElasticsearchのUIツール)でグラフやダッシュボードとして表示します。これにより、システムの異常を早期に発見したり、性能ボトルネックを特定したりできます。
この用途では、Elasticsearchは単体で使われるだけでなく、通常は以下のツールと組み合わせて使われます。これらをまとめて Elastic Stack (以前はELK Stackと呼ばれていました: Elasticsearch, Logstash, Kibana) と呼びます。
- Beats: 軽量なデータシッパー。サーバーやコンテナからログ、メトリックなどのデータを収集し、LogstashやElasticsearchに送ります。
- Logstash: データ処理パイプライン。様々なソース(ファイル、ネットワーク、データベースなど)からデータを受け取り、整形、加工、フィルタリングなどの処理を行ってからElasticsearchに送ります。
- Kibana: 可視化および管理ツール。Elasticsearchに格納されたデータを検索したり、豊富なグラフやマップ、表などを使ってデータを可視化したり、ダッシュボードを作成したりできます。Elasticsearchの操作や管理もKibanaのUIから行えます。
このElastic Stackは、大量の時系列データを扱うのに非常に強力で、DevOps、SRE(Site Reliability Engineering)、セキュリティ監視などの分野で広く活用されています。
2.3 ビジネスインテリジェンス(BI)とデータ分析
Elasticsearchは、構造化・非構造化を問わず様々なデータを高速に集計・分析できるため、ビジネス上の意思決定を支援するためのデータ分析にも利用されます。
- ユーザー行動分析:
Webサイトやアプリケーションでのユーザーのクリック履歴、ページの閲覧時間、購入履歴などをElasticsearchに蓄積し、「どのページからアクセスしたユーザーがコンバージョンしやすいか」「特定のキャンペーンの効果はどれくらいか」といった分析をリアルタイムに近い形で行います。 - マーケティングキャンペーンの効果測定:
広告のクリックデータ、Webサイトへの流入元、ユーザーの属性情報などを組み合わせて分析し、マーケティング施策の最適化を図ります。 - 在庫管理と需要予測:
販売データ、在庫データ、気象情報などをElasticsearchに集約し、現在の在庫状況を把握したり、過去の傾向から将来の需要を予測したりするための分析基盤とします。
特に、アドホックな(その場での)多様な切り口でのデータ集計や、大量データの高速な探索的分析において、Elasticsearchのアグリゲーション機能は非常に強力です。
2.4 セキュリティ情報の管理と分析 (SIEM)
Elasticsearchは、システムやネットワークから発生するセキュリティ関連のログやイベント(ログイン履歴、ファイアウォールの通信記録、侵入検知システムのアラートなど)を収集・分析するプラットフォームとしても利用されます。
- サイバー攻撃の検知と調査:
膨大なセキュリティログの中から、不審なアクセスパターンや異常な振る舞いをリアルタイムで検知したり、インシデント発生時に原因究明のためにログを高速に検索・分析したりします。 - コンプライアンスレポート作成:
セキュリティポリシーに基づいたログの保管と、監査に必要なレポート作成を支援します。
Elasticsearchの高速な検索・集計能力は、日々大量に発生するセキュリティイベントの中から、脅威となりうる兆候をいち早く発見するために不可欠です。Elastic社は、SIEM(Security Information and Event Management)ソリューションも提供しており、Elasticsearchはその中核を担っています。
これらの利用シーンから分かるように、Elasticsearchは単なる全文検索エンジンではなく、大量の多様なデータを高速に検索・分析するための汎用的なプラットフォームとして、非常に幅広い分野で活用されています。
第3章 Elasticsearchの基本アーキテクチャ
Elasticsearchがどのようにデータを扱い、高速な検索・分析を実現しているのかを理解するためには、その基本的なアーキテクチャを知る必要があります。
3.1 クラスター (Cluster)
Elasticsearchの最も大きな単位はクラスターです。クラスターは、1つ以上のノードの集まりで構成されます。
- 役割: クラスター全体でデータのインデックス作成、検索、分析、そして分散管理を行います。
- 特徴: クラスター内のノードは互いに通信し合い、連携して動作します。データや処理負荷はクラスター内のノードに分散されます。単一障害点(SPOF)をなくし、高可用性とスケーラビリティを提供します。
例えば、3台のサーバーそれぞれにElasticsearchをインストールして起動すると、それらのサーバーが互いに認識し合い、一つのElasticsearchクラスターを形成します。
3.2 ノード (Node)
ノードは、Elasticsearchがインストールされ、実行されている1台のサーバーまたはプロセスです。
- 役割: クラスターの一部として、データの保存、インデックス作成、検索、アグリゲーションなどの処理を実行します。
- 種類: Elasticsearchのノードにはいくつかの役割を持たせることができますが、初心者としてはまず以下の基本的な役割を理解しておけば十分です。
- Master-eligible Node: クラスターを管理する役割を持つ可能性のあるノード。ノード間で選挙を行い、1つのノードがマスターノードとして選出されます。マスターノードは、ノードの参加/離脱、シャードの管理などのクラスター全体の状態を管理しますが、データの検索やインデックス作成などの処理は通常行いません(負荷軽減のため)。
- Data Node: データを格納し、データのインデックス作成、検索、アグリゲーションなどの処理を実行するノード。通常、クラスターの処理能力やデータ容量はデータノードの数に比例します。
- Coordinating Node: クライアントからのリクエスト(検索など)を受け付け、そのリクエストを適切なデータノードにルーティングし、各データノードからの応答を集約してクライアントに返す役割を持つノード。自身ではデータを保持しません。
本番環境では、これらの役割を分けて複数のノードタイプを組み合わせることが多いですが、学習目的や小規模環境であれば、1つのノードがすべての役割を兼ねることも可能です(シングルノードクラスター)。
3.3 インデックス (Index)
インデックスは、関連性の高いドキュメント(後述)の集まりです。RDBにおける「データベース」や「テーブル」に例えられることが多いですが、完全に同じものではありません。
- 役割: データの論理的な区分けを行います。検索や分析の単位となります。例えば、ECサイトであれば「商品」インデックス、ログ分析であれば「Webアクセスログ」インデックス、「エラーログ」インデックスのように分けます。
- 特徴: 各インデックスは独立して管理されます。インデックスごとに、データの構造(マッピング)や設定(シャード数、レプリカ数など)を定義できます。
3.4 シャード (Shard)
インデックスは非常に大きくなる可能性があるため、Elasticsearchはインデックスをさらに小さな単位に分割します。これがシャードです。
- 役割: インデックスのデータを物理的に分割・保持し、分散処理を可能にします。各シャードは独立した Lucene インデックスです。
- 種類:
- プライマリシャード (Primary Shard): 元のデータを持つシャードです。インデックス作成時にシャード数が決定され、後から変更することはできません(リインデックスなどの操作が必要になります)。
- レプリカシャード (Replica Shard): プライマリシャードのコピーです。プライマリシャードとは別のノードに配置されます。
シャードは、Elasticsearchの分散処理とスケーラビリティの要となります。インデックスが複数のシャードに分割されることで、
- 並列処理: 検索リクエストは複数のシャードに対して並列に実行されるため、高速化が図れます。
- データ分散: シャードがクラスター内の複数のノードに分散して配置されることで、1台のノードが扱えるデータ容量の制限を超えて大量のデータを扱えます。
インデックスを作成する際に、いくつのプライマリシャードに分割するか(number_of_shards
)を設定します。これは非常に重要な設定であり、一度作成したインデックスのプライマリシャード数は原則変更できないため、設計時に適切な数を検討する必要があります。
3.5 レプリカ (Replica)
レプリカは、プライマリシャードの複製(コピー)です。
- 役割:
- 高可用性 (High Availability): プライマリシャードを持つノードが故障しても、そのレプリカシャードが別のノードに存在していれば、データは失われず、システムは稼働を続けられます。レプリカシャードは自動的にプライマリシャードに昇格して、処理を引き継ぎます。
- 検索パフォーマンスの向上: 検索リクエストはプライマリシャードとレプリカシャードのどちらに対しても実行できるため、レプリカ数を増やすことで、検索処理の負荷を分散し、スループットを向上させることができます。
レプリカシャードは、インデックス作成時または作成後にいくつ作成するか(number_of_replicas
)を設定できます。レプリカ数を増やすほど、可用性と検索スループットは向上しますが、ディスク容量の使用量が増え、データのインデックス作成(書き込み)時の負荷も増加します(プライマリとすべてのレプリカにデータを書き込む必要があるため)。
通常、可用性を確保するためには最低1つのレプリカ(number_of_replicas: 1
)を設定します。これにより、プライマリシャードのデータが少なくとも1つの別のノードに複製されることが保証されます。
アーキテクチャのまとめ
簡単な例で考えてみましょう。
3台のノード(Node A, Node B, Node C)で構成されるクラスターがあり、「商品」インデックスを作成するとします。このインデックスをプライマリシャード2つ(P0, P1)、レプリカ1つ(R0, R1)で設定した場合、データの配置は例えば以下のようになります。
- Node A: P0, R1
- Node B: P1, R0
- Node C: (この時点ではシャードを持たないが、ノード数が増えたり、ノードが落ちたりするとシャードが再配置される可能性がある)
重要な点は、プライマリシャードとそのレプリカシャードは必ず別のノードに配置されるということです。これにより、Node Aが故障してもP0のデータはNode BにあるR0が引き継ぎ、Node Bが故障してもP1のデータはNode AにあるR1が引き継げるため、データの可用性が保たれます。
また、検索リクエストが来た場合、例えばP0に対する検索はNode AとNode BのR0に対して並列に実行され、結果が統合されて返されます。これにより検索性能が向上します。
このように、Elasticsearchは「クラスター」「ノード」「インデックス」「シャード」「レプリカ」といった要素を組み合わせることで、大量のデータを分散して管理し、高い可用性とスケーラビリティ、そして高速な検索・分析を実現しています。
第4章 Elasticsearchのコアコンセプト:ドキュメント、マッピング、転置インデックス
Elasticsearchのアーキテクチャの次は、データをどのように扱い、どのように検索を実現しているのか、その核となる概念を見ていきましょう。
4.1 ドキュメント (Document)
Elasticsearchにおけるデータの最小単位はドキュメントです。
- 役割: 検索や分析の対象となる個々のデータレコードです。RDBにおける「行」に例えられることが多いですが、より柔軟です。
- 形式: ドキュメントは、JSON(JavaScript Object Notation)形式で表現されます。JSONは、キーと値のペアで構成される、人間にもコンピュータにも分かりやすいデータ形式です。
- 特徴:
- 各ドキュメントは、一意の
_id
を持ちます。 - スキーマレス(Schema-less)またはダイナミックスキーマと呼ばれる特性を持ちます。これは、RDBのように事前に厳格なテーブル定義をしなくても、データを投入するだけでElasticsearchがデータの構造(フィールドとそのデータ型)を自動的に推測してくれます。ただし、後述するマッピングで明示的に定義することも可能です。
- ドキュメントは、1つ以上のフィールドを持ちます。フィールドは、テキスト、数値、日付、真偽値、位置情報など、様々なデータ型を持ち得ます。さらに、ネストされたオブジェクトや配列も扱えます。
- 各ドキュメントは、一意の
ドキュメントの例 (JSON)
json
{
"title": "Elasticsearch 初心者向け解説",
"author": "記事太郎",
"publish_date": "2023-10-27T10:00:00Z",
"tags": ["Elasticsearch", "検索", "分析", "入門"],
"content": "この記事では、Elasticsearchの基本について初心者向けに分かりやすく解説しています。",
"views": 1234
}
このJSONオブジェクト全体が1つのドキュメントとして扱われます。title
, author
, publish_date
, tags
, content
, views
がフィールド名、それぞれの右側がそのフィールドの値です。tags
のように複数の値を持つ配列や、publish_date
のように特定のフォーマットを持つ日付なども扱えます。
Elasticsearchにデータを追加することを「ドキュメントのインデックス作成 (Indexing a document)」と呼びます。
4.2 マッピング (Mapping)
マッピングは、インデックス内のドキュメントが持つフィールドのデータ型や、そのフィールドがどのようにインデックス化され、検索されるべきかを定義するスキーマです。
-
役割:
- データ型定義: 各フィールドのデータ型(テキスト、数値、日付、ブーリアン、位置情報など)を明確に定義します。これにより、Elasticsearchはデータを効率的に保存し、適切な検索方法(例: 数値範囲での検索、日付範囲での検索、全文検索など)を提供できます。
- インデックス化方法の定義: 特にテキストフィールドの場合、どのように単語に分割(トークン化)し、どのような処理(小文字化、ステミングなど)を施してインデックス化するかを定義します。これが全文検索の精度に大きく影響します。
- 検索方法の定義: フィールドが検索可能か、集計可能かなどを制御します。
-
ダイナミックマッピングと明示的マッピング:
- ダイナミックマッピング (Dynamic Mapping): ドキュメントを初めてインデックス作成した際、Elasticsearchがフィールド名と値を見て、自動的にそのフィールドのデータ型を推測し、マッピングを生成する機能です。初心者にとっては便利ですが、意図しないデータ型に推測されてしまう可能性もあります。
- 明示的マッピング (Explicit Mapping): 事前にAPIを使ってインデックスの作成時にマッピングを定義したり、既存のインデックスにマッピングを追加したりする方法です。特にテキストフィールドのインデックス化方法や、日付・数値の正確な型指定など、細かく制御したい場合に利用します。本番環境では、意図した検索・分析を正確に行うために、明示的マッピングを利用することが推奨されます。
マッピングの例 (一部)
上記のドキュメント例に対する自動生成または手動で定義されたマッピングは、例えば以下のようになります(完全な形式ではありません)。
json
{
"mappings": {
"properties": {
"title": { "type": "text" }, // 全文検索用のテキスト
"author": { "type": "keyword" }, // 完全一致検索・集計用のテキスト
"publish_date": { "type": "date" }, // 日付・時間による検索・範囲指定用
"tags": { "type": "keyword" }, // 配列内の各要素に対して完全一致検索・集計用
"content": { "type": "text" }, // 全文検索用のテキスト
"views": { "type": "long" } // 数値範囲検索、集計用
}
}
}
text
型と keyword
型は、テキストフィールドの代表的なデータ型です。
* text
型: 全文検索(単語に分割してあいまい検索)に適しています。
* keyword
型: 完全一致検索やソート、集計(アグリゲーション)に適しています。単語に分割されず、値全体が1つの単位として扱われます。
同じテキストフィールドでも、用途によってこれらの型を使い分けることが重要です。ダイナミックマッピングでは、文字列はデフォルトで text
と keyword
の両方としてマッピングされることが多いですが、明示的に定義することでより細かく制御できます。
4.3 全文検索の仕組み:転置インデックス (Inverted Index)
Elasticsearchの全文検索の速さの秘密は、転置インデックスというデータ構造にあります。
一般的なデータベースのインデックス(順方向インデックス)が、「ドキュメントID → ドキュメントの内容」という構造であるのに対し、転置インデックスは「単語 → その単語を含むドキュメントのリスト」という構造になっています。
例えるなら、本の巻末にある「索引」のようなものです。索引では、「単語」を探すと、その単語が記載されている「ページ番号」のリストが見つかりますね。転置インデックスもこれに似ています。
転置インデックスの作成プロセス(簡易版)
- ドキュメントの収集: 検索対象となるドキュメントを集めます。
- 分析 (Analysis): 各ドキュメントのテキストフィールドに対して、以下の処理を行います。
- 文字フィルタリング (Character Filtering): 特殊文字を除去したり、文字コードを統一したりします。
- トークナイズ (Tokenizing): テキストを単語(トークン)の列に分割します。日本語の場合は、形態素解析などが必要です。
- トークンフィルタリング (Token Filtering):
- 小文字化 (Lowercasing): 大文字・小文字を区別なく検索できるように、全て小文字に変換します。
- ステミング (Stemming): 単語の語幹を取り出します(例: “running”, “runs”, “ran” → “run”)。
- ストップワード除去 (Stop Word Removal): “the”, “a”, “is” のような、検索上あまり意味を持たない単語を除去します。
- 類義語展開 (Synonym Expansion): “PC” と “パソコン” を同じ単語として扱えるようにします。
- その他、様々なフィルタリングがあります。
- インデックス化: 分析によって得られた単語(トークン)と、それを含むドキュメントID、単語が出現した位置情報などを記録した転置インデックスを作成します。
例: 以下の2つの簡易ドキュメントがあるとします。
- Doc 1: “Quick brown fox jumps over the lazy dog”
- Doc 2: “Lazy fox is quick”
分析プロセス(単純なスペース区切り、小文字化、ストップワード除去 “the”, “is”)を経て、以下のような単語リストが得られます。
- Doc 1: quick, brown, fox, jumps, over, lazy, dog
- Doc 2: lazy, fox, quick
この情報から、転置インデックスは以下のように構築されます。
単語 | ドキュメントID (出現位置など)
------- | ---------------------------
quick | Doc 1 (1), Doc 2 (3)
brown | Doc 1 (2)
fox | Doc 1 (3), Doc 2 (2)
jumps | Doc 1 (4)
over | Doc 1 (5)
lazy | Doc 1 (7), Doc 2 (1)
dog | Doc 1 (8)
検索プロセス:
例えば「quick fox」というクエリで検索する場合、Elasticsearchはクエリ文字列も同様に分析し、「quick」と「fox」という単語を得ます。
- 転置インデックスで「quick」を検索 → Doc 1, Doc 2 が見つかる
- 転置インデックスで「fox」を検索 → Doc 1, Doc 2 が見つかる
- これらの結果を統合し、両方の単語を含む Doc 1 と Doc 2 を検索結果として返します。
転置インデックスを使うことで、検索クエリに含まれる単語を含むドキュメントを、データベース全体をスキャンすることなく、インデックスを引くだけで高速に特定できます。また、単語の出現頻度や近接度などを考慮して、より関連性の高いドキュメントを上位に表示する(関連性スコアリング)ことも可能です。
この転置インデックスの仕組みは、Elasticsearchの全文検索性能を支える最も重要な要素です。マッピングでフィールドのデータ型を適切に設定し、テキストフィールドに対して適切なアナライザー(分析プロセスを定義したもの)を選択することが、検索精度に直結します。
第5章 Elasticsearchの基本的な操作
Elasticsearchの基本概念が理解できたところで、実際にどのようにデータを扱ったり検索したりするのか、その基本的な操作方法を見ていきましょう。ElasticsearchはRESTful APIを提供しているため、cURLコマンドや任意のプログラミング言語のHTTPクライアントライブラリを使って操作できます。KibanaのDev ToolsにあるConsoleを使うのが、学習目的には最も簡単で便利です。
操作は主にHTTPメソッド(PUT, POST, GET, DELETE)とエンドポイント(URL)を使って行います。
5.1 ドキュメントのインデックス作成 (Indexing a Document)
新しいドキュメントを特定のインデックスに追加したり、既存のドキュメントを更新したりする操作です。
例: products
インデックスに新しい商品ドキュメントを追加
“`bash
cURL コマンドの例
インデックス名: products
ドキュメントID: 1 (明示的に指定)
PUT /products/_doc/1
{
“name”: “おしゃれな麦わら帽子”,
“description”: “夏の強い日差しから守る、通気性の良い麦わら帽子です。”,
“price”: 2500,
“stock”: 50,
“tags”: [“夏”, “帽子”, “ファッション”, “麦わら”],
“created_at”: “2023-10-27T11:00:00Z”
}
“`
PUT /<index>/_doc/<_id>
: 指定したインデックス (products
) の、指定したID (1
) でドキュメントをインデックス作成(または更新)します。IDが既に存在すれば更新、なければ新規作成です。POST /<index>/_doc
: IDをElasticsearchに自動生成させてドキュメントをインデックス作成します。
更新の場合も、PUT
を使って同じIDでドキュメント全体を再度送信します。これはドキュメント全体を置き換える操作になります。一部のフィールドだけを更新したい場合は、後述の _update
エンドポイントを使います。
5.2 ドキュメントの取得 (Getting a Document)
特定のIDを持つドキュメントを取得する操作です。
例: products
インデックスのID 1
のドキュメントを取得
“`bash
cURL コマンドの例
GET /products/_doc/1
“`
GET /<index>/_doc/<_id>
: 指定したインデックス (products
) の、指定したID (1
) のドキュメントを取得します。
成功すると、ドキュメントのソースデータ (_source
フィールド) に加えて、インデックス名 (_index
)、ドキュメントID (_id
)、バージョン (_version
) などのメタデータが返されます。
5.3 ドキュメントの検索 (Searching Documents)
これがElasticsearchの最も強力な機能です。様々な条件でドキュメントを検索できます。
検索には主に2つの方法があります。
-
URIによる検索 (URI Search):
URLのクエリパラメータとして検索条件を指定するシンプルな方法です。簡単な検索には便利ですが、複雑な検索や集計には向いていません。例:
products
インデックスで「麦わら」を含むドキュメントを検索“`bash
cURL コマンドの例
GET /products/_search?q=麦わら
“`GET /<index>/_search
: 指定したインデックス (products
) に対して検索を実行します。?q=麦わら
: クエリパラメータq
で検索文字列を指定します。デフォルトでは、マッピングで全文検索可能に設定されている全てのフィールドに対して検索が行われます。
特定のフィールドを指定して検索することも可能です。
例:
description
フィールドで「通気性」を含むドキュメントを検索bash
GET /products/_search?q=description:通気性 -
リクエストボディによる検索 (Request Body Search) – Query DSL:
HTTPリクエストのボディにJSON形式で検索条件を指定する方法です。Elasticsearchの検索機能のほぼ全てを利用でき、複雑なクエリやフィルタリング、集計(アグリゲーション)を記述できます。このJSON形式のクエリ言語を Query DSL (Domain Specific Language) と呼びます。例:
products
インデックスで、name
またはdescription
フィールドに「帽子」を含むドキュメントを検索“`bash
cURL コマンドの例
POST /products/_search
{
“query”: {
“multi_match”: {
“query”: “帽子”,
“fields”: [“name”, “description”]
}
}
}
“`POST /<index>/_search
: リクエストボディを使って検索を実行します。"query": { ... }
: 検索条件を記述する部分です。"multi_match": { ... }
: 複数のフィールドに対して同じクエリを実行するクエリタイプです。"query": "帽子"
: 検索したいキーワードです。"fields": ["name", "description"]
: 検索対象とするフィールドを指定します。
Query DSLには、様々な種類のクエリがあります。
- Match Query: テキストフィールドに対して、分析プロセスを経てあいまいな全文検索を行います。
- Term Query:
keyword
型などの非テキストフィールドに対して、完全一致検索を行います。 - Range Query: 数値や日付フィールドに対して、範囲検索を行います(例:
price
が1000円以上3000円以下)。 - Bool Query: 複数のクエリをAND (must), OR (should), NOT (must_not), Filter (filter) といった論理演算子で組み合わせます。Filter句はスコアリングに影響せず、キャッシュされるため、絞り込みによく使われます。
- Phrase Match Query: 単語が特定の順序で、かつ近くに出現するドキュメントを検索します(フレーズ検索)。
- 他にも、地理空間検索、ネストされたドキュメントの検索など、非常に多くのクエリタイプがあります。
検索結果は、条件にマッチしたドキュメントのリスト (
hits
) と、合計件数 (hits.total
) などの情報を含むJSON形式で返されます。検索結果はデフォルトで関連性スコア (_score
) の高い順にソートされます。
5.4 ドキュメントの部分更新 (Updating a Document)
既存のドキュメントの一部フィールドだけを更新したい場合に利用します。これは、GET
で取得して変更を加えて PUT
で全体を置き換えるよりも効率的です。
例: products
インデックスのID 1
のドキュメントの stock
フィールドだけを 45
に更新
“`bash
cURL コマンドの例
POST /products/_update/1
{
“doc”: {
“stock”: 45
}
}
“`
POST /<index>/_update/<_id>
: 指定したドキュメントを更新します。"doc": { ... }
: 更新したいフィールドとその値をJSON形式で指定します。Elasticsearchは既存のドキュメントを取得し、指定されたフィールドだけを変更して、新しいドキュメントとして再インデックス作成します。
スクリプトを使って更新することも可能です。例えば、現在の在庫数に特定の数を加減するなど、フィールドの値に基づいて更新する場合に使います。
5.5 ドキュメントの削除 (Deleting a Document)
特定のIDを持つドキュメントを削除する操作です。
例: products
インデックスのID 1
のドキュメントを削除
“`bash
cURL コマンドの例
DELETE /products/_doc/1
“`
DELETE /<index>/_doc/<_id>
: 指定したドキュメントを削除します。
ドキュメントはすぐに物理的に削除されるわけではなく、削除済みとしてマークされ、後からマージプロセスによって物理的に削除されます。
5.6 インデックスの管理操作 (Index Management)
ドキュメントの操作だけでなく、インデックス自体を作成、取得、削除することも重要です。
例: logs
という名前の新しいインデックスを作成
“`bash
cURL コマンドの例
PUT /logs
{
“settings”: {
“number_of_shards”: 3,
“number_of_replicas”: 1
},
“mappings”: {
“properties”: {
“timestamp”: { “type”: “date” },
“level”: { “type”: “keyword” },
“message”: { “type”: “text” }
}
}
}
“`
PUT /<index>
: 指定した名前 (logs
) で新しいインデックスを作成します。"settings": { ... }
: インデックスの設定(シャード数、レプリカ数など)を指定します。"mappings": { ... }
: フィールドのマッピングを定義します。この例ではtimestamp
,level
,message
というフィールドを明示的に定義しています。
例: 既存の products
インデックスの設定やマッピングを取得
“`bash
cURL コマンドの例
GET /products
“`
GET /<index>
: 指定したインデックスの情報を取得します。
例: logs
インデックスを削除
“`bash
cURL コマンドの例
DELETE /logs
“`
DELETE /<index>
: 指定したインデックスとその中の全てのドキュメントを削除します。この操作は非常に破壊的であり、実行する際は十分に注意が必要です。
これらの基本的な操作は、Elasticsearchとプログラムから連携したり、手動でデータを投入・確認したりする際の基礎となります。Query DSLは非常に奥が深く、様々な検索ニーズに対応できるようになっています。最初はシンプルなクエリから始め、必要に応じてより複雑なクエリを学んでいくのが良いでしょう。
第6章 データ分析機能:アグリゲーション (Aggregations)
Elasticsearchは単にドキュメントを検索するだけでなく、大量のデータに対して統計情報や集計値を算出する強力な機能を持っています。これがアグリゲーションです。SQLにおける GROUP BY
, COUNT
, SUM
, AVG
, MIN
, MAX
といった集計処理に似ていますが、より多様な集計タイプを持ち、高速に実行できるのが特徴です。
アグリゲーションは、検索クエリと一緒に実行されることが多く、検索結果に加えて、その検索条件にマッチしたデータの集計結果を得ることができます。
6.1 アグリゲーションでできること
アグリゲーションを使うと、以下のようなデータ分析が可能です。
- カテゴリ別集計:
- 「商品」インデックスで、カテゴリごとの商品数をカウントする。
- 「ログ」インデックスで、エラーレベルごとのログ件数をカウントする。
- 数値データの統計:
- 「商品」インデックスで、価格の平均値、最大値、最小値を計算する。
- 「アクセスログ」インデックスで、ページのレスポンスタイムの平均値を計算する。
- 期間別集計:
- 「販売データ」インデックスで、日別、週別、月別の売上合計を計算する。
- 「ログ」インデックスで、時間帯ごとのアクセス件数を集計する。
- バケット(buckets)とメトリック(metrics):
アグリゲーションは通常、「バケット」と「メトリック」の2つの概念を組み合わせて行われます。- バケット: ドキュメントを特定の基準でグループ化するものです(例: カテゴリ別、国別、年齢層別、価格帯別など)。SQLの
GROUP BY
句に相当します。 - メトリック: 各バケット内のドキュメントに対して計算される統計値です(例: 個数 (count)、合計 (sum)、平均 (avg)、最大値 (max)、最小値 (min) など)。SQLの
COUNT
,SUM
などの集計関数に相当します。
- バケット: ドキュメントを特定の基準でグループ化するものです(例: カテゴリ別、国別、年齢層別、価格帯別など)。SQLの
例えば、「カテゴリ別の平均価格」を知りたい場合、「カテゴリ」がバケット、「価格の平均」がメトリックになります。
6.2 アグリゲーションの基本的な構文
アグリゲーションのリクエストは、検索リクエストの _search
エンドポイントに対して、query
とは別に aggs
(または aggregations
) というセクションを追加して記述します。
例: products
インデックスで、tags
フィールドの値ごとの商品数をカウントし、上位5つを表示
“`bash
cURL コマンドの例
POST /products/_search
{
“size”: 0, // 検索結果のドキュメント自体は不要なので0に設定
“aggs”: {
“products_by_tag”: { // アグリゲーションの名前 (任意)
“terms”: { // バケットタイプ: 特定フィールドの値でグループ化
“field”: “tags.keyword”, // 対象フィールド (keyword型を使うことが多い)
“size”: 5 // 上位5つのバケットを表示
}
}
}
}
“`
"size": 0
: アグリゲーションの結果だけが欲しい場合、検索結果のドキュメントリストは不要なのでsize
を0に設定します。これによりパフォーマンスが向上します。"aggs": { ... }
: アグリゲーションの定義を開始します。"products_by_tag": { ... }
: このアグリゲーションに付ける任意の名前です。結果はこの名前で返されます。"terms": { ... }
: バケットタイプを指定します。terms
は、フィールドに含まれるユニークな値ごとにドキュメントをグループ化します。"field": "tags.keyword"
: グループ化の基準となるフィールドを指定します。テキストフィールドを値でグループ化したい場合は、通常keyword
サブフィールドを指定します(マッピングで設定されている場合)。"size": 5
: 返すバケットの最大数を指定します(この例では、出現回数の多い上位5つのタグ)。
結果例 (一部)
json
{
"took": ...,
"timed_out": false,
"_shards": ...,
"hits": { ... }, // size: 0 なので hits.hits は空
"aggregations": {
"products_by_tag": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": ...,
"buckets": [
{
"key": "夏", // タグ名 (バケットのキー)
"doc_count": 30 // このタグを持つドキュメント数 (バケット内のドキュメント数)
},
{
"key": "帽子",
"doc_count": 25
},
{
"key": "ファッション",
"doc_count": 20
},
{
"key": "麦わら",
"doc_count": 10
},
{
"key": "アウトレット",
"doc_count": 5
}
]
}
}
}
結果の aggregations
セクションに、定義した名前 (products_by_tag
) の結果が含まれます。buckets
配列の中に、各タグ名 (key
) とそのタグを持つドキュメント数 (doc_count
) が表示されています。
6.3 よく使われるアグリゲーションタイプ
アグリゲーションには様々な種類があります。代表的なものをいくつか紹介します。
-
Bucketing Aggregations (バケットアグリゲーション):
ドキュメントをグループ化します。terms
: フィールドの値でグループ化(上記の例)。range
: 数値や日付の範囲でグループ化。date_histogram
: 日付フィールドを指定した間隔(日別、週別、月別など)でグループ化。時系列データの分析に必須です。filter
: 特定のクエリにマッチするドキュメントでグループ化。filters
: 複数のクエリで複数のグループを作成。
-
Metric Aggregations (メトリックアグリゲーション):
各バケット内のドキュメントに対して値を計算します。count
: ドキュメント数(doc_count
)。termsアグリゲーションなどで自動的に計算されます。sum
: フィールドの値の合計。avg
: フィールドの値の平均。min
: フィールドの値の最小値。max
: フィールドの値の最大値。stats
: 上記のcount
,sum
,avg
,min
,max
をまとめて計算。cardinality
: フィールドに含まれるユニークな値の数(例: アクセス元IPアドレスのユニーク数)。
-
Pipeline Aggregations (パイプラインアグリゲーション):
他のアグリゲーションの結果に対して計算を行います。derivative
: 時系列データの変化率を計算。moving_average
: 移動平均を計算。
アグリゲーションはネスト(入れ子)にすることも可能です。例えば、「タグ別」にグループ化した後、各タグ内でさらに「価格帯別」にグループ化し、それぞれの価格帯での「平均在庫数」を計算する、といった複雑な分析も一度のリクエストで行えます。
アグリゲーションは、KibanaのDiscoverやVisualize機能の基盤となっています。Kibanaを使うことで、JSONで複雑なアグリゲーションクエリを書かなくても、GUI操作だけで簡単に様々なグラフやダッシュボードを作成できます。
アグリゲーション機能があることで、Elasticsearchは単なる検索エンジンにとどまらず、強力なリアルタイム分析プラットフォームとして利用できるのです。
第7章 Elasticsearchのエコシステム:Elastic Stack (ELK Stack)
Elasticsearchは単体でも非常に強力ですが、通常は同じElastic社が提供する他のプロダクトと組み合わせて利用されます。これらをまとめて Elastic Stack または以前の名称で ELK Stack (Elasticsearch, Logstash, Kibana) と呼びます。最近では Beats も含まれるようになり、ELKBC Stackと呼ばれることもありますが、一般的にはElastic StackまたはELK Stackと呼ばれます。
それぞれのプロダクトがどのような役割を担っているのかを見ていきましょう。
7.1 Logstash
Logstash は、様々なソースからデータを収集し、加工・変換を行い、指定した出力先(主にElasticsearch)にデータを送信するための、サーバーサイドのデータ処理パイプラインです。
- 役割:
- 入力 (Input): ログファイル、ネットワーク(Syslogなど)、各種データベース、メッセージキュー(Kafka, RabbitMQ)、クラウドサービスなど、多様なソースからデータを読み込みます。
- フィルター (Filter): 読み込んだデータに対して、構造の解析(例: WebサーバーログからIPアドレスやリクエストパスを抽出)、データ型の変換、不要なフィールドの削除、データの追加、匿名化などの加工を行います。特によく使われるのが
grok
フィルターで、正規表現を使って非構造化ログから構造化データを抽出できます。 - 出力 (Output): 加工済みのデータを指定した宛先に送信します。主な出力先はElasticsearchですが、ファイル、S3、Kafka、他のデータベースなど、様々な出力先に対応しています。
Logstashは、特にフォーマットが一定しないログデータなどをElasticsearchに取り込む際に非常に役立ちます。複雑なデータ加工が必要な場合に Logstash を利用します。
7.2 Beats
Beats は、軽量で単一目的のデータシッパー(データ転送ツール)のファミリーです。サーバーやコンテナにインストールして使用します。Logstashよりもリソース消費が少なく、特定の種類のデータを効率的に収集することに特化しています。
- 役割: 様々なソースからデータを収集し、LogstashまたはElasticsearchに直接送信します。
- 代表的なBeats:
- Filebeat: ログファイルを収集し、行ごとに読み込んで転送します。
- Metricbeat: システムやサービス(CPU、メモリ、ネットワーク、Docker、Kubernetes、データベースなど)のメトリックを収集します。
- Packetbeat: ネットワークトラフィックをキャプチャし、プロトコルレベルの情報を解析して転送します(HTTP、DNSなど)。
- Winlogbeat: Windowsイベントログを収集します。
- Auditbeat: Linuxの監査フレームワークから監査データを収集し、システムアクティビティを監視します。
LogstashとBeatsの使い分けとしては、
* Beats: サーバーからデータを収集する最初のステップとして軽量に動かしたい場合。
* Logstash: 収集したデータに対して複雑な加工や複数の入力ソースの結合が必要な場合。
Beatsでデータを収集し、Logstashで加工してからElasticsearchに送る、という構成が一般的ですが、シンプルなケースではBeatsから直接Elasticsearchに送ることもあります。
7.3 Kibana
Kibana は、Elasticsearchに格納されたデータを探索、可視化、管理するためのWebベースのUIツールです。
- 役割:
- データの探索 (Discover): Elasticsearchにインデックスされたデータを検索クエリを使って自由に探索できます。特定の条件にマッチするドキュメントを一覧表示したり、時系列での件数推移をグラフで確認したりできます。ログ分析で特定のログを検索する際などに非常に便利です。
- データの可視化 (Visualize): 棒グラフ、折れ線グラフ、円グラフ、ヒートマップ、マップ、表など、様々な種類のグラフを作成してデータを可視化します。Elasticsearchのアグリゲーション機能を使って、複雑な集計結果を分かりやすく表示できます。
- ダッシュボード (Dashboard): 作成した複数の可視化要素を組み合わせて、1つの画面で複数の指標を同時に監視できるダッシュボードを作成します。システムの健全性監視やビジネス指標の追跡に活用されます。
- 開発ツール (Dev Tools): ElasticsearchのREST APIを直接操作できるConsoleを提供します。JSON形式でAPIリクエストを送信し、レスポンスを確認できます。学習やデバッグ、手動での操作に非常に便利です。
- 管理機能 (Management): インデックスの管理(作成、削除、設定変更)、マッピングの確認、シャードの配置状況の確認など、Elasticsearchクラスターの管理タスクを行うためのUIを提供します。
- その他の機能: Machine Learning(異常検知など)、APM(アプリケーション性能監視)、SIEM(セキュリティ監視)など、Elastic Stackの有料機能や高度な機能を利用するためのインターフェースも提供します。
Kibanaは、Elasticsearchのデータを「見る」「触る」「管理する」ための窓口となります。特に初心者にとっては、JSONコマンドを直接打つよりも、KibanaのGUIを使った方がElasticsearchのデータや機能を直感的に理解しやすいでしょう。
Elastic Stack全体像
典型的なElastic Stackのデータフローは以下のようになります。
データソース
→ Beats
→ (Logstash
) → Elasticsearch
← Kibana
Beatsが様々な場所からデータを収集し、必要に応じてLogstashで加工・整形された後、Elasticsearchに格納されます。そして、Kibanaを使ってElasticsearchのデータを検索、可視化、分析、監視します。
この統合されたスタックによって、データの収集から保存、分析、可視化までを一気通貫で行うことができるようになり、特にログ分析やリアルタイム監視の分野で絶大な支持を得ています。
第8章 初心者がElasticsearchを始めるには
ここまでElasticsearchの基本について解説してきましたが、「よし、始めてみよう!」と思った初心者が、最初の一歩を踏み出すためには何をすれば良いでしょうか。
8.1 環境構築
最も簡単な方法は、Dockerを利用することです。Docker Composeを使えば、ElasticsearchとKibanaを数コマンドで起動できます。
- DockerとDocker Composeをインストールする: ご利用のOSに合わせてインストールしてください。
-
docker-compose.yml
ファイルを作成する: 以下のような内容でファイルを作成します。“`yaml
version: ‘3.8’services:
elasticsearch:
image: elasticsearch:8.9.0 # 利用したいバージョンを指定 (最新版または推奨版)
container_name: elasticsearch
environment:
– discovery.type=single-node # 開発・学習用シングルノード設定
– xpack.security.enabled=false # セキュリティ無効化 (学習用、本番NG)
– “ES_JAVA_OPTS=-Xms512m -Xmx512m” # JVMメモリ設定
ports:
– “9200:9200” # REST API
– “9300:9300” # Node間通信 (通常は不要)
volumes:
– elasticsearch-data:/usr/share/elasticsearch/data # データ永続化用ボリュームkibana:
image: kibana:8.9.0 # Elasticsearchと同じバージョンを指定
container_name: kibana
environment:
– ELASTICSEARCH_HOSTS=[“http://elasticsearch:9200”] # Elasticsearchのホスト名
ports:
– “5601:5601” # Kibana UI
depends_on:
– elasticsearch # Elasticsearch起動後にKibanaを起動volumes:
elasticsearch-data: # Elasticsearchのデータを保存するDockerボリューム
“`- 注意: この設定は学習・開発用であり、セキュリティが無効化されています (
xpack.security.enabled=false
)。本番環境では絶対にこの設定を使わないでください。 本番環境では、セキュリティ(認証・認可)を有効化し、メモリ設定やシャード数なども適切に調整する必要があります。 - 利用したいElasticsearchとKibanaのバージョンを揃えて指定してください。
- コンテナを起動する:
docker-compose.yml
ファイルがあるディレクトリで以下のコマンドを実行します。
bash
docker-compose up -d
これで、ElasticsearchとKibanaのコンテナがバックグラウンドで起動します。
4. Kibanaにアクセスする: Webブラウザでhttp://localhost:5601
にアクセスします。Kibanaの画面が表示されれば成功です。左側のメニューから「Analytics」→「Discover」や、「Management」→「Dev Tools」を選択してみましょう。 - 注意: この設定は学習・開発用であり、セキュリティが無効化されています (
Dockerを使わない場合は、公式サイトから各種OS向けのバイナリやパッケージをダウンロードしてインストールすることも可能です。インストール手順は公式サイトのドキュメントを参照してください。
8.2 Dev Tools (Console)でElasticsearchを触ってみる
Kibanaが起動したら、左側のメニューから「Management」→「Dev Tools」を選んでみましょう。ここでElasticsearchのREST APIコマンドを直接実行できます。
画面左側のエディタにコマンドを入力し、実行ボタン(緑色の三角)を押すと、右側に結果が表示されます。
-
クラスターの情報を取得:
GET /
Elasticsearchのバージョン情報などが表示されます。 -
クラスターヘルスを確認:
GET /_cluster/health
クラスターの状態 (status
: green, yellow, red) やノード数などが表示されます。シングルノードの場合は status は通常yellow
またはgreen
になります。 -
全てのインデックスを表示:
GET /_cat/indices?v
現在クラスターに存在するインデックスの一覧が表示されます。Kibanaのインデックスなどが既にあるかもしれません。 -
最初のドキュメントをインデックス作成:
PUT /my_first_index/_doc/1
{
"greeting": "Hello, Elasticsearch!",
"timestamp": "2023-10-27T12:00:00Z"
}
my_first_index
という新しいインデックスが自動的に作成され、ID1
のドキュメントが追加されます。 -
インデックス作成したドキュメントを取得:
GET /my_first_index/_doc/1
-
インデックス作成したドキュメントを検索:
GET /my_first_index/_search?q=elasticsearch
POST /my_first_index/_search
{
"query": {
"match": {
"greeting": "Hello"
}
}
}
まずはこのように、小さなインデックスを作成し、数件のドキュメントをインデックス作成、取得、検索してみることから始めましょう。
8.3 公式ドキュメントを活用する
Elasticsearchは機能が豊富で、設定やQuery DSLも多岐にわたります。公式ドキュメントが非常に充実しており、最新かつ正確な情報源です。何か分からないことがあれば、まず公式ドキュメントを参照するようにしましょう。
日本語のドキュメントも一部存在しますが、最新の情報は英語版が最も早く、網羅的です。
8.4 最初の目標設定
初心者向けの最初の目標としては、以下のようなステップをお勧めします。
- 環境構築: Docker等を使ってElasticsearchとKibanaを起動する。
- Dev Toolsでの基本操作: インデックス作成、ドキュメントのCRUD (Create, Read, Update, Delete)、URI Search、シンプルな Query DSL での検索を試す。
- Kibana Discoverでのデータ探索: サンプルデータを入れるか、自分でインデックス作成したデータをKibanaのDiscover画面で見てみる。検索バーでキーワード検索などを試す。
- Kibana Visualizeでの基本可視化: 簡単な棒グラフや円グラフ(例: フィールドごとの件数、日付フィールドの時系列グラフ)を作成してみる。アグリゲーションの概念とKibanaでの操作を結びつける。
- サンプルデータの取り込み: Elastic Stackには様々なデモ用のサンプルデータセット(フライトデータ、ウェブサイトログなど)を取り込む機能があります。これを利用して、実際の大量データに対する検索や可視化を体験してみるのも良いでしょう。
焦らず、まずは基本的な操作と概念をしっかりと掴むことが大切です。
第9章 知っておくと便利な概念(初級〜中級向け)
基本的な使い方を試す中で、いくつか追加で知っておくと理解が深まる概念があります。これらは直接的な操作というよりは、Elasticsearchが内部でどう動いているかに関わる部分です。
9.1 アナライザー (Analyzer)
第4章で触れたように、テキストフィールドがインデックス化され、全文検索が可能になるプロセスを分析 (Analysis) と呼びます。この分析処理のまとまりをアナライザーと呼びます。
アナライザーは、以下の3つの要素で構成されます。
- Character Filters: 元の文字列の前処理(HTMLタグの除去、文字変換など)。
- Tokenizer: 文字列を単語(トークン)に分割します(例: 標準トークナイザー、空白区切りトークナイザー、n-gramトークナイザーなど)。日本語の場合は、形態素解析を行うkuromojiなどのトークナイザーが使われます。
- Token Filters: トークナイザーで分割された単語列に対する後処理(小文字化、ステミング、ストップワード除去、類義語展開など)。
マッピングでテキストフィールドを定義する際、使用するアナライザーを指定できます。デフォルトのアナライザーもありますが、検索精度や言語特性に合わせて適切なアナライザーを選択したり、独自のアナライザーを定義したりすることが、高品質な全文検索には不可欠です。
例えば、日本語のテキストを正確に検索するためには、英単語のように空白で区切るのではなく、形態素解析によって単語を抽出する必要があります。Elasticsearchには kuromoji という日本語対応のアナライザープラグインがあります。
9.2 スコアリングと関連性 (Scoring and Relevance)
全文検索では、検索クエリにマッチしたドキュメントが複数見つかった場合、どのドキュメントが最も関連性が高いかを判断し、その順序で結果を返すことが重要です。この「関連性の高さ」を示す数値がスコア (_score
) であり、その計算方法がスコアリングです。
Elasticsearchのデフォルトのスコアリングアルゴリズムは BM25 というものです。BM25は、以下の要素などを考慮してスコアを計算します。
- Term Frequency (TF): 検索語がドキュメント内にどれだけ頻繁に出現するか。多く出現するほど関連性が高いとみなされます。
- Inverse Document Frequency (IDF): 検索語がインデックス全体の中でどれだけ珍しい単語か。珍しい単語ほど、それを含むドキュメントの関連性が高いとみなされます。
- Field Length Norm: フィールドの長さ。短いフィールドに検索語が出現した場合、長いフィールドに出現した場合よりも重要度が高いとみなされる傾向があります(短いタイトルにキーワードが含まれる方が、長い本文に含まれるよりも関連性が高い、という考え方)。
これらの要素を組み合わせることで、単にキーワードが含まれているだけでなく、「より重要で、より少ないドキュメントにしか含まれないキーワードが、短いフィールドに多く出現している」ドキュメントのスコアが高くなるように設計されています。
必要に応じて、スコアリングの仕組みをカスタマイズしたり、特定のドキュメントやフィールドの重要度を上げたり(Boosting)することも可能です。
9.3 インデックスの管理と運用
Elasticsearchを本番運用する際には、インデックスの適切な管理が重要になります。
- インデックスライフサイクル管理 (ILM – Index Lifecycle Management):
ログデータなどの時系列データは、古くなるにつれてアクセス頻度が下がり、やがて削除されるのが一般的です。ILMは、インデックスを「Hot」(書き込み・検索)、HWarm(検索のみ)、Cold(アクセス頻度低い、読み取り専用)、Delete(削除)といった段階に自動的に移行させ、ストレージの種類やシャード/レプリカ数の調整などを行うことで、運用コストを最適化する機能です。 - シャード数の検討:
インデックス作成時に設定するシャード数 (number_of_shards
) は、後から変更できないため、慎重に検討が必要です。多すぎると管理オーバーヘッドが増え、少なすぎるとデータ量増加時にスケールアウトの限界になります。データ量、ノード数、検索負荷などを考慮して適切な数を決定します。 - レプリカ数の検討:
レプリカ数 (number_of_replicas
) は、可用性と検索スループットに影響します。最低1つは設定するのが一般的ですが、検索負荷が高い場合はレプリカを増やして読み取りリクエストを分散させます。書き込み性能とのトレードオフになります。 - リインデックス (Reindex):
既存のインデックスの設定やマッピングを変更したい場合、あるいはシャード数を変更したい場合、直接変更することはできません。新しい設定で別のインデックスを作成し、元のインデックスから新しいインデックスに全てのドキュメントをコピーする「リインデックス」操作を行います。 - スナップショットとリストア (Snapshot and Restore):
データのバックアップと復旧のための機能です。クラスターの状態やインデックスのデータをスナップショットとしてストレージに保存し、必要に応じてリストアできます。
これらの概念は、Elasticsearchを安定して大規模に運用する上で非常に重要になります。
第10章 まとめと次のステップ
この記事では、初心者向けにElasticsearchの基本について、その概要からアーキテクチャ、コアコンセプト、基本的な操作、主要な利用シーン、そしてエコシステムであるElastic Stackまで、幅広く詳細に解説しました。
Elasticsearchは、単なるデータベースではなく、大量の非構造化・半構造化データを含む様々なデータに対して、高速な全文検索とリアルタイムな分析を可能にする強力な分散システムです。ELK Stackという形で、データの収集から可視化までを包括的にサポートするプラットフォームとして、多くの企業で活用されています。
その中核をなすのは、転置インデックスによる高速な全文検索、シャードとレプリカによる分散・高可用性、そしてアグリゲーションによる強力なデータ分析機能です。
もちろん、Elasticsearchの世界はここで解説した以外にも、非常に多くの機能や詳細な設定が存在します。パフォーマンスチューニング、高度なQuery DSL、セキュリティ設定、Machine Learning機能など、学び続けるべきことはたくさんあります。
次のステップとしては、
- ハンズオンで触ってみる: 記事で紹介したDockerを使った方法などで、実際にElasticsearchとKibanaを起動し、Dev Toolsを使って基本的な操作や簡単なアグリゲーションを試してみてください。手を動かすことが最も理解を深めます。
- Kibanaを使いこなす: KibanaのDiscoverやVisualize、Dashboard機能を積極的に使ってみましょう。GUI操作でデータの探索や可視化を行うことで、Elasticsearchの能力を視覚的に理解できます。
- 興味のある分野のドキュメントを読む: 全文検索、ログ分析、メトリック監視など、ご自身の興味のある分野のElastic Stack公式ドキュメントやチュートリアルを読んでみましょう。より実践的な知識が得られます。
- Elasticsearchのコミュニティに参加する: オンラインフォーラムやミートアップなどで他のユーザーと交流し、質問したり知見を共有したりするのも良い学びの機会です。
Elasticsearchは、現代のデータ活用において非常に価値の高いスキルの一つです。最初は難しく感じるかもしれませんが、一歩ずつ学びを進めていけば、きっとその強力さと便利さに気づくはずです。
この記事が、あなたのElasticsearch学習の良き出発点となれば幸いです。頑張ってください!