Elasticsearch の ES|QL エディターエクスペリエンスと OpenSearch の PPL イベントアナライザーの比較

Elasticsearch を実際に体験してみましょう。サンプルノートブックを詳しく調べたり、Elastic の無料クラウドトライアルを開始したり、今すぐローカルマシンで Elastic を試したりできます。

8.14 から一般公開されているElasticsearch クエリ言語(ES|QL) では、検索、可観測性、セキュリティ調査用に設計された専用のクエリ言語とエンジンが導入されています。既存のパイプ言語から多くの部分を借用している OpenSearch のパイプ処理言語 (PPL) とは異なり、ES|QL は洗練性、使いやすさ、および Kibana プラットフォーム全体でのシームレスな統合に重点を置いてゼロから構築されました。

このブログでは、Elasticsearch 9.1 の ES|QL エディターの開発者エクスペリエンスを、OpenSearch 3.2 のイベント アナライザー (略して PPL) の PPL と比較しながら探っていきます。

違いはすぐに明らかになります。ES|QL エディターは、初心者ユーザーだけでなく、エキスパートレベルのユーザーにも力を与えるインテリジェントなオートコンプリート、コンテキスト ヘルプ、推奨クエリ、およびクラスター間クエリ サポートを提供します。ES|QL オーサリングの思慮深い設計は、たとえば最近のクエリを使用した Kibana ワークフローによる統合クエリ検査と総合的な統合にも反映されています。

対照的に、PPL にはオートコンプリート、コンテキスト ガイダンス、分散クエリに対する同等のサポートがないため、学習曲線が急峻になり、試行錯誤が増えます。

ES|QL の学習と使用を容易にする

新しいクエリ言語を使い始めると、圧倒されると感じることがよくあります。Kibana Discover に直接組み込まれた ES|QL エディターは 、 クエリの作成とデバッグをサポートするだけでなく、言語に慣れて使いこなせるようになるまでの時間を短縮することで、そのプロセスを容易にするように設計されています。エディターは日常のタスクの摩擦を軽減するのに役立つため、構文や試行錯誤からソリューションの作成に焦点を移すことができます。これらの原則と、それをエディターにどのように統合したかの詳細については、こちらをご覧ください。

このエディター エクスペリエンスは Discover に限定されません。これは再利用可能なコード モジュールであり、ダッシュボード、Kibana アラート、Kibana マップなど、 Kibana の他の部分に統合する作業が進められています。

インテリジェントなオートコンプリート: クエリ作成を高速化

ES|QL エディターのオートコンプリートは包括的で、互換性のある関数、引数、リテラル、さらにはネストされた関数の提案を提供します。これは PPL には明らかに欠けている機能です。実際、ここで概説されているように、根本から再構築されました。

ここで説明されているように、検証はユーザーが入力すると実行され、フィールドを提案し、ユーザーにエラーを通知します。これにより、ユーザーの精神的負担が軽減され、クエリ作成プロセスの早い段階でエラーを防ぐことができます。

例: このネストでは、フィールドと互換性のある関数が提案されています。

PPL がサポートしていないもの:

互換性のある関数、引数、ネストされた関数を案内するインテリジェントなオートコンプリート機能があっても、利用可能なオプションについてさらに深く理解したい場合があります。ここで、ES|QL エディターのコンテキスト ヘルプが非常に役立ち、エディター内で即時に支援が提供され、クエリの開発が明確化され、強化されます。

指先で状況に応じたヘルプ

オートコンプリートによって生成されたコマンドに関する追加情報は、Ctrl キーとスペース キーを押すことで表示されます。問題の関数、引数、またはフィールドの詳細を示すパネルがすぐに表示されます。この軽量なインタラクションにより、開発者はスムーズに作業を進めることができ、エディターを離れたり外部ドキュメントを検索したりすることなく、ジャストインタイムのガイダンスを得ることができます。これにより、構文の検索に費やす時間が削減され、よくある間違いを未然に防ぐことができます。

実際の動作は次のようになります。

PPL にはこのレベルの組み込みガイダンスがないため、ユーザーは外部のドキュメントや試行錯誤に頼ることになります。その欠如は単に機能が欠けているというだけではなく、設計哲学におけるより広範な相違を浮き彫りにしています。ES|QL は、ユーザーのデータとワークフローに適応する、思慮深くコンテキストを意識したエクスペリエンスを優先します。この違いはクエリの複雑さが増すにつれて顕著になり、ES|QL エディターは学習と本番使用の両方においてより効率的で信頼性の高い環境になります。

データのコンテキストを考慮した推奨クエリ

ES|QL エディターは、ログなどの作業中のデータに合わせて自動的に調整される推奨クエリを提供します。空白のエディターを表示する代わりに、一般的なユースケースに最も関連性の高い開始点を表示します。推奨クエリを選択すると、すぐに使用できる標準クエリが生成され、必要に応じてさらに絞り込むことができます。このアプローチにより、特に完全な構文をまだ知らない新しいユーザーにとって、クエリの開発が加速されます。

以下は、ユーザーが「変化点の検出」クエリを選択する例です。

これを PPL の経験と比較してみましょう。

対照的に、ここでの PPL は基本的なオートコンプリートのみを提供するため、コンテキストや構造なしでクエリを組み立てることになります。このガイダンスの欠如は、フラストレーションと試行錯誤につながる可能性があります。ES|QL エディターのデータ対応の推奨クエリを使用すると、日常的なタスクの構文を最初から作成したり、暗記したりする必要がなくなります。エディターは認知負荷を軽減し、エラーの防止に役立ち、クエリの構築に悩むのではなく、問題解決やクラスター間検索の実行などのより広範な目標に集中できるようにします。

直感的なクラスター間クエリ

ES|QL エディターのオートコンプリートは、 CCS を使用して複数のリモート クラスターを操作する場合でも、優れた性能を維持します。理由は次のとおりです。

ES|QL エディターは、クラスター間でもシームレスなオートコンプリートを提供します。

ES|QL エディターのオートコンプリートは、クラスター名だけでなく、ローカル インデックスとリモート インデックスの両方をサポートします。ここで説明されているように、これはコーディネーター ノード アーキテクチャのおかげで機能します。このアーキテクチャは、ローカル ノードに送信するクエリ プランを検証および生成し、クエリを実行して結果を集計してからユーザーに送り返すのに役立ちます。完全なリモート クラスター名を入力せずに「:」と入力すると、リモート インデックスの自動補完プロセスが開始されます。また、接頭辞に限定されるわけではありません。

これにより、命名規則を記憶したりコンテキストを切り替えたりすることなく、分散データセット全体の検出とクエリを簡単に実行できるようになります。

以下は、ユーザーが「clu:g」と入力してリモート インデックスを検索する例です。

対照的に、PPL はローカル インデックスに対して基本的な補完のみを提供し、提案はプレフィックスの一致に制限されています。リモート クラスターは手動で入力する必要があるため、エラーが発生する可能性が高まり、クエリの作成が遅くなります。

PPL はローカル インデックスに対してのみ補完を提供し、提案はプレフィックスに制限されます。

ES|QL ではさらに、負の符号を使用して直接除外できるため、探索に参加するクラスターをきめ細かく制御できます。この機能は、クラスター間の調査中に特定のデータセットを含めたり省略したりする必要があるハイブリッド環境で作業する場合に特に役立ちます。

これらの機能強化は、Elasticsearch がクラスター間検索における摩擦の軽減に重点を置いていることを反映しています。ES|QL エディターでは、分散クエリの構築と管理が容易になるため、アナリストや開発者は構文ではなく洞察に集中できます。一方、PPL ではその負担がユーザーに多く残ります。ES|QL エディターは、クラスター間クエリの作成を簡素化するだけでなく、それらのクエリの実行方法を検査するツールも提供し、複数のクラスターにわたる透明性とパフォーマンス監視を保証します。

検査ツールを使用してクロスクラスター検索の詳細を分析する

ES|QL エディターからアクセスできる検査ツールは、すべてのクラスターにわたるクエリ実行に関する明示的な情報をメタデータに提供するように設計されています。この機能は Kibana Discover で有効になっており、クエリ インスペクターから直接アクセスできるため、検索の進行状況と詳細を分析できます。これは、Cross-Cluster Search ( CCS ) にとって特に重要です。この機能を使用すると、検索の進行状況を監視し、分散データセット全体でのクエリの実行方法を把握できます。

特に複雑な分散検索の場合、クエリ実行の詳細な可視性により、最適なパフォーマンスとトラブルシューティングが可能になります。

ES|QL エディターは、個々のクエリの仕組みを理解するだけでなく、Kibana プラットフォーム全体に重要な機能を深く組み込むことでユーザー ジャーニーをさらに強化し、シームレスで中断のないワークフローを促進します。

ES|QLとKibanaによる統合クエリエクスペリエンス

クエリ駆動型分析における最も一般的な摩擦の原因の 1 つは、コンテキストの切り替えです。すでに記述したクエリを思い出す必要がある場合がよくあります。中断されるたびに集中力が途切れ、調査が遅くなります。ES|QL エディターは、Kibana 全体のクエリ履歴を統合することでこの問題に対処します。

最近のクエリ

ES|QL エディターの最近のクエリ機能を使用すると、過去の作業にすぐにアクセスできるようになり、作業の流れを維持できます。Discover の ES|QL エディターでは、過去 20 件のクエリを表示、再実行、スター付けすることができ、頻繁に使用するクエリや複雑なクエリを 1 回のクリックで実行できるようになります。保存されたクエリは Kibana 全体に引き継がれ、ダッシュボード、視覚化、アラート、マップと統合されるため、現在の画面を離れたり、コマンドを最初から再入力したりする必要はありません。これにより、反復的な作業が削減され、調査が高速化され、エラーのリスクが最小限に抑えられます。

たとえば、ユーザーは Discover の ES|QL エディターで最近のクエリを利用できます (そしてスターを付けることもできます)。

最近のクエリはダッシュボードに統合されています。

PPL には同等の機能は用意されていないため、ユーザーはクエリを再利用するために手動でのコピー アンド ペーストや外部メモに頼ることになります。この違いは利便性だけではありません。これは、ES|QL を Kibana エコシステム内に真に統合された言語として構築するという Elastic の戦略を反映しています。ES|QL エディターは、最近のクエリなどの機能により、日常のワークフローを効率化するだけでなく、現在テクニカル プレビューで提供されているより高度な機能の基盤も構築し、エクスペリエンスの継続的な進化を保証します。

まとめ

ES|QL は単なる構文ではありません。ユーザーがデータを検索、探索、分析する方法を改善するという Elastic の戦略を反映しています。インテリジェントなオートコンプリート、コンテキスト認識型の推奨クエリ、エディター内ガイダンス、Inspect などのツールを備えた ES|QL エディターは、学習を加速し、エラーを削減し、クラスター間分析などの複雑なワークフローを簡素化します。Kibana 全体に統合されており、クエリをダッシュボード、アラート、視覚化にシームレスに接続して、中断のないワークフローを実現します。

要約すると、ES|QL は単なる別のパイプ言語ではありません。データとの対話方法を根本的に再定義する直感的な UI と組み合わせた、思慮深く設計されたクエリ エンジンであり、OpenSearch PPL の多くの場合シーケンシャルでガイドが少ない性質とは対照的に、統合されたインテリジェントで継続的に進化するエクスペリエンスを提供します。

次は何？

このブログは ES|QL の表面的な部分のみを取り上げています。今後の投稿では、OpenSearch PPL との比較をさらに深め、地理空間、視覚化、コントロール(ダッシュボードで既に利用可能)、マルチデータ探索タブ、バックグラウンド検索、より豊富なクエリ履歴、FUSE などの今後のエディター機能について説明します。

今すぐES|QLをお試しください

無料トライアル で、完全に管理された Elasticsearch Serverless プロジェクトで ES|QL を試すことができます。8.11 以降のバージョンでも利用可能ですが、 8.19 および 9.1で最も快適にご利用いただけます。

1 つのコマンドでローカル環境で数分以内に開始できます。