Elasticsearch 1.4.1および1.3.6リリース(日本語訳)

Posted by johtani on Thursday, November 27, 2014

目次

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

原文:elasticsearch 1.4.1 and 1.3.6 released

本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.1と、バグフィックスリリースである、Elasticsearch 1.3.6をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。

過去のリリースに関するブログ(公式)はこちら。

すべての変更については1.4.1のリリースノートおよび1.3.6のリリースノートをごらんください。 以下では、重要な変更について紹介します。

shard allocation

Elasticsearch 1.3.0で、disk based shard allocationが デフォルトで有効になっています。 もし、ノードのディスクの使用量がlawで指定された値(85%)を超えた場合、ノードにはシャードが配置されません。 また、highで指定された値(90%)を超えた場合、シャードを他のノードへ移動します。

Elasticsearch 1.4.1では、disk based shard allocationに3つの改良が追加されました。

  • ディスク使用量のチェックはシャードがクラスタに配置されるタイミングでのみ実施していた。現在は60秒ごとに使用量をチェック。(#8270)
  • ディスクフルメッセージはDEBUGレベルでログに出力されていました。なぜ、新しいシャードが配置されないのかを説明するのが困難でした。現在はWARNレベルで30秒ごとにログに出力されます。(#8382)
  • 以前は、シャードをもう一つのノードへ動かすべきかどうか決めるとき、allocation deciderはノードにあるシャードのサイズを考慮するだけでした。現在は、動かされるシャードのサイズも考慮します。これにより、必要最小限のシャードの移動量となります。(#8569)

parent/child and nested documents

Elasticsearch 1.4.0で、parent/childとnestedドキュメントに対して(新しいセグメントを開くときに)固定長ビットセットフィルタを構築しキャッシュしました。クエリ、フィルタおよびAggregationを常に速くするためにです。 多くのnestedフィールドを持つユーザにとっては、以前のバージョンよりもヒープの使用量が大きくなってしまいました。

nested aggregationによって処理されるドキュメントの順序を変更すること(#8454)によって、固定長ビットセットフィルタが子のドキュメントに対して必要でなくなりました。 現在は、親のドキュメント(つまり、nestedではないドキュメント)を表すフィルタのみをキャッシュしています。これにより必要なキャッシュ空間のサイズを減少しました。(#8414#8440)

date ranges

2つの日付範囲に関する問題がこのリリースで修正されました。 1つ目は、日付を丸めるかというものです。例えば、timestampフィールドに1秒の解像度の値があるとします。 {"lt": "2014/11/26||/d"}というrangeフィルタは2014/11/26 00:00:00未満のタイムスタンプのデータを結果として返しました。 しかし、ltlteに変更した場合、2014/11/27 00:00:00以外の値も含めたいです。

以前は、lte2014/11/27 00:00:00のタイムスタンプも含めてしまっていました。現在は、想定通りの動作をします。(#8556)

2つ目のバグは日付の範囲条件にnow()を利用したaliasとpercolatorフィルタです。 now()の値を、フィルタが作成したタイミングで決定していました。フィルタが実行されるたびに更新せずにです。 #8534で、now()はaliasとpercolatorで想定通りの動作をします。

試してみてください。

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


comments powered by Disqus

See Also by Hugo


Related by prelims-cli