elasticsearch 1.4.0.Beta1のリリース

1.4.0のテーマは*resiliency(復元性、弾力性)*です。 resiliencyとはElasticsearchをより安定し信頼性のあるものにすることを意味します。すべての機能が正常に機能している場合は信頼することは簡単です。予想外のことが発生した時に難しくなります：ノードでout of memoryの発生、スローGCや重いI/O、ネットワーク障害、不安定なデータの送信によるノードのパフォーマンス低下など。

本ベータリリースは、resiliencyの主な3つの改善を含んでいます。

メモリ使用量の低下によるノードの安定性向上
discoveryアルゴリズムの改善によるクラスタの安定性向上
チェックサムの導入による破損したデータの検知

分散システムは複雑です。決して想像できないような状況をシミュレーションするために、ランダムなシナリオを作成する広範囲なテストスイートを持っています。しかし、無数のエッジケース(特殊なケース)があることも認識しています。 1.4.0.Beta1はこれまで私たちが行ってきた改善のすべてを含んでいます。これらの変更を実際にテストしていただき、何か問題があった場合は私たちに教えてください。

メモリ管理

ヒープ空間は限られたリソースです。上限を32GBとし、利用可能なRAMの50%をヒープの上限にすることを推奨します。この上限を超えた場合、JVMは圧縮したポインタを使用することができず、GCが非常に遅くなります。ノードの不安定性の主な原因は遅いGCです。それは、次のようなことから発生します。

メモリプレッシャー
スワップ(参照：memory settings)
非常に大きなヒープ

本リリースは、メモリ管理の改善し、（結果として）ノードの安定性を改善するいくつかの変更を含んでいます。

doc values

メモリの利用の最も大きなものの1つはfielddataです aggregation、ソート、スクリプトがフィールドの値に素早くアクセスするために、フィールドの値をメモリにロードして保持します。ヒープは貴重なため、1ビットも無駄にしないためにメモリ内のデータは高度な圧縮と最適化を行っています。これは、ヒープスペース以上のデータをもつまでは、非常によく動作します。これは、多くのノードを追加することによって常に解決できる問題です。しかし、CPUやI/Oが限界に達してしまうずっと前に、ヒープ空間の容量に到達します。

最近のリリースは、doc valuesによるサポートがあります。基本的に、doc valuesはin-memory fielddataと同じ機能を提供します。 doc valuesの提供する利点は、それらが、非常に少量のヒープ空間しか使用しない点です。 doc valuesはメモリからではなく、ディスクから読み込まれます。ディスクアクセスは遅いですが、doc valuesはカーネルのファイルシステムキャッシュの利点を得られます。ファイルシステムキャッシュはJVMヒープとはことなり、32GBの制限による束縛がありません。ヒープからファイルシステムキャッシュにfielddataを移行することによって、より小さなヒープを使うことができます。これは、GCがより早くなり、ノードが更に安定することを意味します。

本リリースより前は、doc valuesはin-memory fielddataよりもかなり遅かったです。本リリースに含まれる変更は、パフォーマンスをかなり向上させ、in-memory fielddataとほぼ同じくらいの速度になっています。

in-memory fielddataの代わりにdoc valuesを利用するために必要なことは、次のように新しいフィールドをマッピングすることです。

PUT /my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "timestamp": {
          "type":       "date",
          "doc_values": true
        }
      }
    }
  }
}

このマッピングで、このフィールドに対するfielddataの利用は、メモリにフィールドをロードする代わりに、自動的にディスクからdoc valuesを利用します。 *注意：*現時点で、doc valuesはanalyzedなstringフィールドはサポートしていません。

request circuit breaker

fielddata circuit breakerはfielddataによって利用されるメモリの上限を制限するために追加され、OOMEの最も大きな原因の1つを防ぎました。そして、リクエストレベルのcircuit-breakerを提供するために、コンセプトを拡張しました。これは、単一のリクエストによって使用されるメモリの上限を制限します。

bloom filters

Bloom filters はインデキシング(前のバージョンのドキュメントが存在するかどうかのチェックのため)や、 IDによるドキュメントの検索(ドキュメントを含むセグメントがどれかを決定するため)に関する重要な性能最適化を提供しました。しかし、もちろんそれらはコスト（メモリ）を必要とします。現在の改善は、bloom filterの必要性を取り除きました。現在では、Elasticsearchはまだ、インデックス時にそれらを構築します(実世界の経験がテストシナリオにそぐわない場合に備えて)。しかし、デフォルトではメモリにはロードされません。すべてが予定通りに運べば、将来のバージョンで完全にこれらは除去します。

クラスタの安定性

クラスタの安定性向上のために私たちができる最も大きなことは、ノードの安定性の向上です。もし、ノードが安定しておりタイミングよく反応すれば、クラスタが不安定になる可能性が大いに減少します。私たちは不完全な世界に住んでいます。- 物事は予想外にうまく行きません。クラスタはデータを失うことなくこのような状況から回復できる必要があります。

私たちは、improve_zenブランチ上で、Elasticsearchの障害からの復旧するための能力の向上に数ヶ月費やしてきました。まず、複雑なネットワークレベルの障害を繰り返すためのテストを追加しました。次に、各テストのための修正を追加しました。そこには、より多くの行うことが存在します。しかし、私たちは、issue #2488(“分割が交差している場合、minimum_master_nodesはsplit-brainを防げない”)に含まれる、ユーザが経験してきた大部分の問題を私たちは解決しました。

私たちはクラスタのresiliencyを非常に真剣に取り組んでいます。私たちは、Elasticsearchが何ができるか、その上で何が弱点であるかを理解してほしいと思っています。これを考慮して、私たちはResiliency Status Documentを作成しました。このドキュメントは、私たち(または私たちユーザ)が遭遇したresiliencyの問題の、何が修正済みで、何が修正されないまま残っているかを記録します。このドキュメントを慎重に読み、あなたのデータを保護するために適切な方法を選択してください。

データ破損の検知

ネットワークをまたいだシャードリカバリのチェックサムは、圧縮ライブラリのバグを発見する助けとなりました。それは、バージョン1.3.2で修正済みです。それ以来、私たちはElasticsearchのいたるところにチェックサムとチェックサムの確認を追加しました。

マージ中に、あるセグメント内すべてのチェックサムの確認(#7360)
インデックス再オープン時に、あるセグメント内の最も小さなファイルの完全な確認と、より大きなファイルの軽量な打ち切りチェック(LUCENE-5842)
トランザクションログからイベントを再生するとき、各イベントはチェックサムを確認される(#6554)
シャードのリカバリ中もしくは、スナップショットからのリストア中にElasticsearchはローカルファイルとリモートのコピーが同一であるか確認する必要がある。ファイルの長さとチェックサムのみを使うのは不十分であることが確認された。このため、現在はセグメントのすべてのファイルの同一性を確認(#7159)

その他のハイライト

Elasticsearch 1.4.0.Beta1のchangelogに本リリースの多くの機能、改善、バグフィックスについて読むことができます。ここでは、特筆すべきいくつかの変更について述べます。

groovyによるmvelの置き換え

Groovyは現在、デフォルトのscripting languageです。以前のデフォルトはMVELで、古くなってきており、サンドボックス内で実行できないという事実は、セキュリティ問題でした。 Groovyはサンドボックスであり(それは、ボックスの外へは許可が必要)、メンテナンスされており、速いです！詳しくはscriptingについてのブログ記事をご覧ください。

デフォルトでcorsはオフ

Elasticsearchのデフォルト設定はクロスサイトスクリプティングに対して脆弱でした。私たちはデフォルトでCORSをオフにすることで修正しました。 Elasticsearchにインストールされたサイトプラグインはこれまで同様に機能します。しかし、CORSを再度オンにすることがない限り、外部のウェブサイトがリモートのクラスタにアクセスすることはできません。ウェブサイトがあなたのクラスタにアクセス可能に制御できるように、さらにCORS settingsを追加しました。詳しくはsecurity pageをご覧ください。

クエリキャッシュ

新しい試験的なshardレベルのクエリキャッシュは、静的なインデックスのアグリゲーションをほとんど即座に反応できます。ウエブサイトのアクセスの日毎のページビュー数を見るダッシュボードを持っていると想像してみてください。これらの数値は古いインデックスでは変更がありません。しかし、アグリゲーションはダッシュボードのリフレッシュのたびに再計算されます。新しいクエリキャッシュを利用すると、シャードのデータが変更されない限り、アグリゲーションの結果はキャッシュから直接返却されます。キャッシュから古い結果を決して取得することはありません。それは、常に、キャッシュされていないリクエストと同じ結果を返します。

新しいaggregations

3つの新しいaggregationsがあります。

filters
- これはfilter aggregationの拡張です。複数のバケットを定義し、バケット毎に異なるフィルタを利用できます。
children
- nestedアグリゲーションの親子版。children aggは親のドキュメントに属する子のドキュメントを集計できる
scripted_metric
- このaggregationは、データによって計算されたメトリックを完全にコントロールできます。これは、初期化フェーズ、ドキュメント収集フェーズ、shardレベル結合フェーズ、global reduceフェーズを提供します。

get /index api

以前、ある1つのインデックスのaliases、mappings、settings、warmersを取得出来ました。しかし、それらを個別にです。 get-index API はこれらのすべてもしくは一部を、複数もしくはひとつのインデックスに対して一緒に取得できます。これは、既存のインデックスと同一もしくはほぼ同一であるインデックスを作成したいときに非常に役に立ちます。

登録と更新

ドキュメントの登録と更新にいくつかの改善があります。

現在、ドキュメントIDの自動生成のためにFlake IDを使用しています。これは、プライマリキー探索時に素晴らしい性能向上を提供します。
detect_noopにtrueを設定すると、ドキュメントに変更を与えない更新が軽量になります。この設定を有効にすると、_sourceフィールドのコンテンツを変更する更新リクエストだけ、ドキュメントの新しいバージョンを書き込みます。
更新はスクリプトから完全に操作できます。以前は、スクリプトはドキュメントがすでに存在しているときだけ実行可能で、それ以外は、upsertドキュメントで登録しました。script_upsertパラメータでスクリプトから直接ドキュメントの作成が操作できます。

function score

すでに非常に便利なfunction_scoreクエリが、新しくweightパラメータをサポートします。これは、それぞれの指定された関数の影響をチューニングするのに使われます。これは、人気度よりも更新日時により重みをかけたり、地理情報よりも価格により重みをかけるといったことを可能にします。また、random_score機能はセグメントマージによる影響を受けません。これにより、より一貫した順序が提供されます。

試してみてください。

ぜひ、Elasticsearch 1.4.0.Beta1をダウンロードして、試してみてください。そして、感想をTwitter(@elasticsearch)などで教えて下さい。また、問題がありましたら、GitHub issues pageで報告をお願いします。