2014の25日目のエントリです。あっという間に最終日です。来年につなげるという意味で、Elasticsearchの2系のIssueをいくつかピックアップして紹介してみます。現在、ElasticsearchのGitHubリポジトリは、大きく3つのブランチで作業しています。master、1.x、1.4です。masterと1.xの大きな違いとしては、masterはLuceneの5.x系を採用している点です。これから紹介するIssueは現在、確定していない項目も含んでいます。採用されない場合もあります。(closed)https://github.com/elasticsearch/elasticsearch/pull/8347先ほど書きましたが、Luceneの5に対応するためのPRです。5に関してはLuceneのコミッターのMikeさんのブログ記事も参考になります。5に変更することで、BitSetに関する改善が多く含まれることになります。メモリの利用量、圧縮などの改善が多く含まれています。3系のインデックスを読み込むことができなくなる点です。Luceneの下位互換の範囲は1つ前のメジャーバージョン(5.x系の場合は4.xまでが対象)となっています。cacheは、trueもしくはfalseの設定が利用できますが、filterの種類にも依存します。その辺りの条件を加味しつつ、よしなにCacheをコントロールしてくれます。discuss)https://github.com/elasticsearch/elasticsearch/issues/8960似ているが少し異なるand、or、notフィルタとboolフィルタが存在しています。これらをわかりやすくするために、boolフィルタに統一しましょうという話し合いをしています。discuss)https://github.com/elasticsearch/elasticsearch/issues/9059色々な入力に関するチェックを追加しようというIssueです。ディレクトリ名やファイル名、URLのパスやクエリストリング、フィールドのパスやスクリプトなどです。Validationがあると、変な設定をして頭をかかえることもなくなるかなぁと。#8961(open)https://github.com/elasticsearch/elasticsearch/issues/8961新しくAnalyzerを作った場合に、色々な場所に登録必要があったりします。インデックスレベルとノードレベルです。(Kuromojiプラグインなどが参考になります。インデックスごとにカスタムのAnalyzerを設定するので、1つのノードに同じAnalyzerを何度も設定しないといけません。シンプルにするために、Analyzerをノード単位で設定しようという提案です。#8870(open)https://github.com/elasticsearch/elasticsearch/issues/8870同じインデックスに、異なるtypeで、同じフィールド名があった場合、いろいろと良くないことがあったりします。フィールドのタイプがintegerとstringと異なる場合に、インデックスレベルで検索を行うとうまく検索できなかったりと。この問題を解消するために、より明確にしようというIssueです。フィールド名を指定するためには、フルパスで記述をするだとか、フィールドマッピングに関してはインデックスレベルで内部で保持をするなど。#7205(closed)https://github.com/elasticsearch/elasticsearch/issues/72051.xでも取り込まれますが、嬉しい機能なので紹介します。これまでは、mappingsでスペルミスをした場合(たとえば、field設定で"indexx"といったミス)には、その項目は単に無視されるだけでした。これが、v1.xでは、エラーにまとめということで、簡単ですが、v2.0.0に向けたIssueをピックアップして紹介してみました。上記以外にも多くの改善、提案が2.0に向けて行われています。興味のある方は、v2.0.0ラベルでIssueを検索してみてはいかがでしょうか?今年もあとわずかとなりました。今年の2月にElasticsearchの1.0がリリースされ、あっという間に1.4なりました。来年もElasticsearchに興味をもっていただければ嬉しいです。Elasticsearch初のユーザカンファレンスのサイトもオープンしました。Elasticsearchに関するいろいろな話が聞ける機会だと思います。登録をお待ちしています。