@johtaniの日記 2nd

@johtani ‘s blog 2nd edition

Elasticsearch 2.0.0.beta1リリース間近(日本語訳)

※この記事は次のブログを翻訳したものになります。

原文:Elasticsearch 2.0.0.beta1 coming soon!

Elasticsearch 2.0.0.beta1のリリースの準備をしています。 これは、Lucene 5.2.1に含まれる多くの改善が利用できるようになります。 このリリースに関するいくつかの機能は次のようなものです。

Pipeline Aggregations

差分や移動平均、他のAggregationsの結果に対する series arithmeticのようなaggregationが利用可能になります。 この機能は、これまでは、クライアントサイドで実行する必要がありました。 しかし、この計算をより強力な解析クエリを構築してElasticsearchで 実行することができるようになります。 クライアントのコードをより簡潔にすることができます。 これにより、予測解析や異常検知のようなことができるようになります。

Query/Filter merging

Filterはなくなります。全てのフィルタは、クエリになります。 クエリコンテキストで利用されると、効率的に関連度スコアを計算し、 フィルタコンテキストで利用されると、単に、 マッチしていないドキュメントを除外する(今のフィルタのようなもの)だけです この変更は、クエリ実行が自動的に、より効率的な順番で実行されるように 最適化されることを意味します。 例えば、フレーズやgeoクエリのような遅いクエリは まず、近似フェーズを実行し、それから、より遅い実際のフェーズが 結果に対して行われます。 フィルタコンテキストにおいて、頻繁に利用される条件は自動的にキャッシュされます。

Configurable store compression

index.codec設定により、高速化のためのLZ4圧縮(default)か インデックスサイズを小さくするためのDEFLATE(best_compression)を 選択できます。これは、ロギングでとくに役に立ちます。 これにより、古いインデックスオプティマイズする前にbest_compressionに 変更できます。

これらに関するブログ記事がすぐに公開されるでしょう。

Performance and resilience

以降では、新しいメジャーリリースに関して簡単に紹介します。 2.0の変更の多くは内部の機能に関するものであり、 直接ユーザに関連するわけではないからです。

新しいメジャーバージョンのテーマは、パフォーマンス、安定性、 堅牢性、予測可能性、そして使い勝手の良さです。

  • 物事が予測した通りに動作する
  • 何か問題があった場合に、Elasticsearchから役立つフィードバックがある
  • ローレベルの設定を扱う必要はなく、Elasticsearchが良い設定を決定する
  • これらに加え、データがより安全に

これらの目標は完全ではありません。 まだ、多くの改善があります。しかし、2.xブランチで、 すでに500コミットを超える大きな改善が実施されています。

  • on-diskの doc valuesをデフォルトで利用(これまではfielddata)。 ヒープ使用量を減らして、スケーラビリティを向上
  • セグメントマージ処理中のメモリ使用量の削減
  • normsの圧縮率の改善。ヒープスペースを利用している大きな処理のひとつだったため。
  • 全てのリクエストの後に、transaction logをfsyncすることで、デフォルトで耐久性を向上
  • 全てのファイル変更をアトミックに(部分的なファイルの書き出しはなし)
  • マージを自動で制限
  • フレーズクエリやスパンクエリを高速化
  • フィルタキャッシュをより効率化するための圧縮されたビットセット
  • クラスタ状態の差分更新
  • 構造化されたJSON形式の例外
  • よりきめ細かいLuceneのメモリレポート
  • デフォルトではlocalhostにのみバインド。開発のノードが他のクラスタにジョインするのを防ぐ
  • parent/childのクエリ実行最適化のためにリライト
  • Java Security Managerで必要最小限なパーミッションで実行
  • 全てのコアなプラグインをelasticsearchリポジトリに移行し、Elasticsearchのバージョンに同期してリリースされる予定

アップグレード前に

メジャーバージョンのアップグレードは問題のあるものを一掃する機会を与えてくれます。 できる限り、これらの変更をアップグレードするために、簡単な方法を提供しようとしています。 しかし、Elasticsearch 2.0にアップグレードする前に、必要な処理が2つあります。

1つ目は、フィールドとタイプマッピングに関することです。 mapping APIは、現在、それほど厳密ではありません。 内蔵された保護機構を提供する代わりに、ユーザがベストプラクティスを知っていると信頼していました。 2.0では、mappingはより厳密で安全ですが、いくつかの変更では、後方互換性を保っていません。 詳細についてはThe Great Mapping Recatoringをごらんください。

2つ目はElasticsearch 0.20以前のユーザに関する変更です。 これは、Lucene 3.xを使っています。 Elasticsearch 2.xはLucene 5をベースにしています。 Lucene 5はLucene 4.xによって作成されたインデックスの読み込みはサポートしていますが、 Lucene 3.xに関してはサポートしていません。

Elasticsearch 0.20以前のバージョンによって生成されたインデックスを持っている場合、 Elasticsearch 2.xのクラスタをスタートすることはできません。 これらの古いインデックスを削除するか、Elaticsearch 1.6.0以上に含まれている upgrade APIを使用してアップグレードする必要があります。

upgrade APIの実行は2つのジョブを実行します。

  • 古いLuceneフォーマットのセグメントを最新のフォーマットで書き換えます
  • Elasticsearch 2.xによって読み込めるようという印をインデックスに追加します

全てのセグメントを最新バージョンにアップグレードするのも良い案ですが、 アップグレード前に必要な処理を最小限に抑えることも可能です。 (Lucene 3.xのセグメントだけをアップグレード) その場合は、only_ancient_segmentsパラメータを指定します。

Elasticsearch Migration Plugin

Elasticsearch 2.0 に移行する前に、インデックスがアップグレードが必要なのか、 ほかになにかするべきことがあるのかをチェックする助けになる Elasticsearch Migration Pluginをリリースしました。

まず、プラグインをインストールします

1
./bin/plugin -i elastic/elasticsearch-migration

プラグインのインストール後はノードのリスタートは必要ありません。

以下のリンクをブラウザで開きます。

http://localhost:9200/_plugin/migration

localhost:9200はインストールしたホスト名に変更してください。)

Migration pluginに関してバグやご意見がある場合は、GitHubのIssueにお願いします。

Comments