Elasticsearch 2.0.0.beta1リリース間近（日本語訳）

差分や移動平均、他の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をリリースしました。

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

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

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

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

http://localhost:9200/_plugin/migration

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

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

Elasticsearch 2.0.0.beta1リリース間近（日本語訳）

目次

Pipeline Aggregations

Query/Filter merging

Configurable store compression

Performance and resilience

アップグレード前に

Elasticsearch Migration Plugin

See Also by Hugo

Related by prelims-cli

FEATURED TAGS