Elasticsearch 2.0.0のリリース以降、310人のコミッターから2,674件のプルリクエストがあった、Elasticsearch 5.0.0 GAをベースにしたLucene 6.2.0のリリースを発表できることを嬉しく思います。これは最新の安定版で、Elasticsearch-as-a-serviceプラットフォームであるElastic Cloudですでに利用可能になっています。

今すぐダウンロードしてご利用ください。

Elasticsearch 5.0.0はどのユーザーにも必ず何らかのメリットをもたらします。5.0.0は、機能強化や新機能が満載された、これまでのElasticsearch の中で最も速く、最も安全で最も復元性が高く、最も使いやすいバージョンです。

インデキシングパフォーマンス
Ingest node
Painlessスクリプト
新しいデータ構造
サーチとAggregation
ユーザーフレンドリー
復元性
Java RESTクライアント
Migration Helper

インデキシングパフォーマンス

5.0.0では、インデキシングのスループットが劇的に向上しました。これは、数値データ構造の改善 ( 「新しいデータ構造」を参照)、同じドキュメントの同時更新を防ぐロックの競合の軽減、トランザクションログのfsync時のロック要件の緩和など、多数の変更によって実現したものです。Translogの非同期fsyncは、ディスクを使用しているユーザーには特にメリットが大きいでしょう。追記のみ（時間ベースのイベントなど）のユースケースでは、ElsticsearchでドキュメントIDを自動生成する際に大幅なスループットの向上が得られます。リアルタイムのドキュメントGETをサポートする仕組みが内部的に変更されたことで、インデキシングバッファに利用できるメモリが増え、ガベージコレクションに要する時間が大幅に短縮されます。

ユースケースによっては、インデキシングのスループットは25%～80%の向上を見込めます。

Ingest node

Elasticsearchへのデータの取り込みが大幅に容易になりました。Logstashは確かに強力なツールですが、小規模な企業では、括的なルーティングオプションは不要で、フィルタだけが必要という場合も多くあります。そこで、grokやsplit、convert、dateなど、Logstashの最も人気の高いフィルタだけを取り出して、プロセッサとしてElasticsearchに直接実装しました。複数のプロセッサをパイプラインに統合して、index APIやbulk API経由でインデックス時にドキュメントに適用することができます。

ログメッセージのインジェストも、Ingest APIでパイプラインを構成するのと同じように簡単になりました。また、Elasticsearchにログファイルを転送するようにFilebeatを設定するのも簡単です。さらに、専用のインジェストノードを実行して、抽出と変換の作業負荷を、検索やaggregation、インデキシングと切り離すことも可能になりました。詳細は、「A New Way to Ingest - Part 1」を参照してください。

Painlessスクリプト

Elasticsearchでは、スクリプトが便利ですが、セキュリティ上の理由でスクリプトをデフォルトで有効にできないのは悩みのタネでした。そこで、Painlessという名前の新しいスクリプト言語を開発しました。Painlessは速く、安全でセキュアなだけではなく、デフォルトで有効になります。その上、Painlessは現状でもGroovyの4倍速く、今後もどんどん速くなっていく予定です。とにかく Painlessは素晴らしいので、新しいデフォルトのスクリプト言語として採用することになり、GroovyやJavascript、Pythonの使用を廃止しました。

Painlessについての詳細は、ブログ記事の「Painless: A New Scripting Language」を参照してください。

新しいデータ構造

Lucene 6 の登場により、数値とgeo-pointフィールドにBlock K-D treesという新しいPointsデータ構造がもたらされ、数値データのインデキシングと検索の方法に革命が起きました。こちらのベンチマークでは、 Pointsはクエリ時間で36%、インデックス時間で71%速く、ディスク使用量が66%、メモリ使用量が85%もそれぞれ少ないことが分かっています ( 「Searching numb3rs in 5.0」を参照）。Pointsが追加されたことは、ip フィールドで ip field can now IPv6だけでなく、IPv4のアドレスもサポートできることを意味します。さらに、geo_pointフィールドも変更され、Luceneの新しいLatLonPointを使用できるようになりました。これにより、geo-pointのクエリパフォーマンスが倍増します。

さらに、半精度 (16ビット) 浮動小数点数に対応するhalf_floatフィールドタイプと、内部的にscaled_floatフィールドも追加されました。これで、long型に使用される圧縮技法のメリットも活かすことができます。

Analyzedとnot-analysedの文字列フィールドが、全文検索専用のtextフィールドと、文字列ID検索や並び替え、aggregation用のkeyword フィールドに代わりました。次の記事を参照してください:Strings are dead, long live strings!

最後に、dots-in-fieldnamesが戻ってきました。ただし、今回は正式なサポート付きです。つまり、foo.barのようなドット付きフィールドは、オブジェクトフィールドfooの中にあるbarフィールドと同じです。 2.xでdots-in-fieldnamesがサポートされていなためにまだ1.7から抜け出せない方は、Elasticsearch 2.4.0を参照してください。移行パスについて説明しています。

検索とAggregation

前日、前月、または前年にかけてのメトリックをグラフ化する、あの美しいKibanaチャートが、 Instant Aggregationsで大幅にスピードアップされます。チャートのデータのほとんどは、もう更新されていないインデックスから取得されますが、ElasticsearchはすべてのリクエストについてAggregationを最初から再計算する必要がありました。これは、{ "gte": "now-30d", "lte": "now" }のようなレンジをキャッシュするのは不可能だったからです。ほぼ1年分に相当するようなリファクタリングを検索APIで行った結果、Elasticsearchはレンジクエリをはるかに効率的に処理できるようになり、今では変更されたインデックスのみを再計算するようになりました。

これ以外にも、aggregrationは改善されています。たとえば、ヒストグラムaggregationでは、小数バケットがサポートされるようになり、負バケットの丸めが正しく処理され、Terms Aggregationsもより効率的に計算されて、組合せ爆発が起きるリスクが軽減されています。また、AggregationはプロファイルAPIでもサポートされるようになりました。

削除されたドキュメントも考慮するようにCompletion Suggesterが一新され、ペイロードだけではなく、ドキュメントも返されるようになりました。コンテキストがより柔軟になり、1つのコンテキスト、多数のコンテキスト、またはすべてのコンテキストについてサジェスチョンをリクエストすることができます。サジェスチョンにはインデキシング時に重み付けできるだけでなく、プレフィックスの長さやコンテキスト、ジオロケーションに基づいてスコアを調整することもできます。

Percolatorも書き直されて速度と効率がアップしました。Percolatorクエリの語句はインデックス付けされるようになり、以前のように総当たり的にチェックするのではなく、マッチする可能性のあるクエリだけをチェックすれば済みます。Percolator APIはpercolateクエリに置き換わりした。これにより、ハイライトやスコアリング、ページネーションなど、検索APIのすべての機能をパーコレーションでも活用できるようになります。

ユーザーフレンドリー

5.0.0リリースの主なテーマは、Elasticsearchをもっと安全に、もっと使いやすくすることでした。我々は 「Shout loud, shout early（大声で注意する、しかも早いうちに）」というアプローチを取りました。つまり、何か問題があるなら、疑問を頂かせたまま放っておいたり、後々データを失うようなリスクを負わせたままにするのではなく、ただちに報告すべき、ということです。この姿勢の一例がインデックスとクラスタ設定の改善です。

設定が厳しく検証されるようになりました。設定の価値を理解できないと、Elasticsearchは文句を言います。設定を認識できない場合も、文句を言った後で「つまり、こういうことですか?」という提案をします。さらに、クラスタ設定とインデックス設定は(nullを使用して)設定解除できます。また、include_defaults パラメータを指定してデフォルト設定を表示することもできます。同様に、bodyとquery文字列パラメータも厳密に解析され、パラメータが無効または認識不可と判断されると例外になります。

rolloverとshrinkAPIにより、時系列ベースのインデックスの効率的な管理が可能になります: 複数の標準を使用して、インデキシング中にハードウェアリソースを最大限に活用し、1つ (または数個) のシャードまでインデックスを縮小して保存と検索を効率化させることができます。

インデックス管理にも多数の改善が加えられています。インデックスの作成がかつてないほど簡単になり、インデックスが使用できる状態になったときのみ create index リクエストが返されるようになりました。もうwait_for_status=greenを待つ必要はありません。また、新しく作成されたインデックスによってクラスタがredになることもありません。これで、システム管理者はゆっくり眠れます。

シャード割り当てで問題が発生しても、これまでのようにElasticsearchが（ログをいっぱいにしながら）無限にシャードの割り当てを続けることはありません。5 回試行すると諦めて、問題が解決されるのを待ちます。シャードが割り当てできない原因を突き止めるためには、新しいcluster-allocation-explain APIは不可欠なツールです。

最後に、deprecation loggingがデフォルトで有効になるようになりました。これで、いま使用している機能の中でどれが廃止される予定かを前もって知ることができます。新しいメジャーバージョンへの移行に伴う苦労がかなり軽減されるはずです。

復元性

Elasticsearchの安全性を徹底的に高めるために、このリリースでは多数の変更が行われています。分散モデルのパーツを1つ1つ分解し、リファクタリングと簡略化を行って、信頼性を高めてあります。クラスタ状態の更新は、クラスタ内のすべてのノードからの確認を待ってから実行されるようになりました。プライマリがレプリカシャードを failed とマークすると、プライマリはマスタからの応答を待ちます。インデックスのデータパスには、インデックス名ではなく、UUIDが使用されるようになり、名前の重複を回避できます。

利用可能なfile descriptorsを十分に確保しておくなど、システムをきちんと構成しておく必要があります。そうしないと、後でデータを失う危険があります。Elasticsearchには、後でひどい目に遭わないように構成をチェックしてくれるブートストラップチェック機能が含まれています。ただし、ラップトップで試してみたいだけ、というような場合にシステムを構成するのは面倒ですよね。Elasticsearchは、ローカルホスト専用の開発者に優しいモードで起動します。このモードでは、構成が十分ではないよ、という警告が出るだけです。ネットワークを設定してクラスタを構成しようとすると、本番稼動モードに切り替わり、すべてのシステムチェックの実行が強制されます。以下の記事を参照してください:「Bootstrap checks: Annoying you now instead of devastating you later!」

実行中のリクエストで使用できるメモリ量を制限するサーキットブレーカーを追加し、Aggregationバケットによって使用されるメモリを追跡し、膨大な数のバケットを要求する有害なリクエストを中断するように、リクエストサーキットブレーカーを拡張しました。メモリ不足による例外は滅多に起きなくなったとはいえ、万が一発生してしまった場合、ノードはこれまでのように不明な状態でよろよろするのではなく、die-with-dignity（尊厳死）を選びます。

システム管理者のために、おびただしい数のソフトリミットを追加してあります。悪意のあるユーザーからクライアントを守り、何も知らないユーザーが危険な区域に迷い込んだときには警告してくれます。たとえば、デフォルトの検索タイムアウト、textフィールドでのfielddata読み込みの無効化、1回の検索リクエストでターゲットできるシャード数の制限、マッピングのフィールド数の制限、などがあります。

Java RESTクライアント

何年もお待たせいたしましたが、やっと低レベルのJava HTTP/RESTクライアントをリリースできることになりました。依存性を最小限に抑えたシンプルなHTTPクライアントがスニッフィングやリクエストのラウンドロビン、ノード障害時の再試行を処理します。このクライアントは、Java APIよりもはるかに安定性が高いことが分かっているRESTレイヤーを使用します。つまり、アップグレードをまたいでも問題は起きず、メジャーアップグレードを経ても安定して使用できると思われます。Java 7での動作確認は済んでおり、依存性は非常に低く、トランスポートクライアントよりも依存性の競合は起きにくいことが分かっています。他のHTTPクライアントと同様に、ファイヤウォールやプロキシで保護することができます。こちらのベンチマークでは、Java RESTクライアントはトランスポートクライアントとパフォーマンスに大差はありません。

ただし、これはあくまで低レベルクライアントであることを忘れないでください。現時点では、IDEの自動完了を手助けする、クエリビルダーやヘルパーの提供はありません。JSON-in、JSON-outですから、JSONをどのようにビルドするかはあなた次第です。ただし、開発はここで終わるわけではなく、クエリの作成や応答の解析を手助けする API を追加する予定です。変更についての最新情報は、問題#19055をフォローしてください。

Migration Helper

Elasticsearch Migration Helperは、Elasticsearch 2.3.x/2.4.xからElasticsearch 5.0への移行準備を手助けするように設計された、サイトプラグインです。このヘルパーには3つのツールが含まれています:

Cluster Checkup: クラスタ、ノード、インデックスで一連のチェックを実行し、アップグレード前に修正する必要がある既知の問題が見つかると、アラートしてくれます。
Reindex Helper: バージョン2.0.0以前で作成されたインデックスを Elasticsearch 5.xで使用するには、再インデックスする必要があります。Reindex Helperは、ボタンをクリックするだけで、古いインデックスをアップグレードしてくれます。
Deprecation Logging: Elasticsearchには、廃止された機能が使用されるたびにログにメッセージを出力するDeprecation Loggerが装備されています。このツールは、クラスタでのDeprecation loggingを有効/無効にするものです。

手順については、Elasticsearch Migration Helperのインストールを参照してください。

Elasticsearch 1.xから直接移行する場合の手順については、アップグレードに関するドキュメントを参照してください。

まとめ

Elasticsearch 5.0.0をダウンロードして、使ってみた感想をTwitter (@elastic) またはフォーラムにぜひ投稿してください。問題を見つけたら、GitHub issuesページで報告してください。

検索AI企業

生成AI

検索

セキュリティ

オブザーバビリティ

ソリューション別

業界

<

2016

<

6月

>

Elastic Stack 5.0.0 alpha4 リリース

Just Enough Kafka For The Elastic Stack, Part 2

Shieldを使用してユーザーの権限に応じた検索結果を取得する

Elastic Cloud Tutorial: Getting Started with a sample dataset

SNSリンク

会社概要

参加する

パートナー

信頼とセキュリティ

投資家向け情報

Excellence Awards