Elasticsearch 1.4.0 Beta1 のリリースノートに出てきた DocValues とは何か？
先日、elasticsearch 1.4.0 Beta1 がリリースされましたね。前々回の勉強会で聞いていたとおりで、安定性の向上が中心のエンハンスメントでした。詳細は、johtani さんの記事をどうぞ。
elasticsearch 1.4.0.Beta1のリリース - @johtaniの日記 2nd
DocValues とは？
ところで、リリースノートに登場してくる DocValues が知らない単語たっだので、早速調べてみました。各ドキュメントから調べてみたのがいかです。元々は、Lucene の機能で、これを Elasticsearch でも使えるように v1.0 で実装していたようです。今回のリリースでは、この DocValues の高速化が図られています。
elasticsearch の blog 記事が以下です。惰訳ですが。。
ファセッティングやソーティングは field data をメモリにロードする必要がある。このフィールドデータは数十ＧＢのメモリを使うことはよく知られている。メモリは安くなってきたので、メモリを追加すること自体には普通やるし問題ない。問題は、JVM レベルのメモリ管理の話で、数十ＧＢ単位のヒープに対するメジャーGCは、容易に数秒はかかるため、その間あなたのアプリは完全にストップすることになる。注意深いヒープのチューニングが問題を回避するのに役に立つが、field-data をヒープには保存しないほうがよりピッタリだと思う。
http://www.elasticsearch.org/blog/disk-based-field-data-a-k-a-doc-values/
また、データをヒープで管理しないことで、OSレベルのディスクキャッシュ用のメモリ上で管理されるようになりますので、安定性が増す形になります。v1.4.0 では、このメモリをより効率的に使えるようになった、ということでしょう。
ちなみに、Solr でのドキュメントは以下。
Solrでは 4.2 から導入された機能キーワード検索では、転置インデックスを用いることで高速に検索することができるが、facetやソート、ハイライトについてはかなり遅かった。例えば、ファセッティング・エンジンは、検索結果に表示される各ドキュメントの中に含まれるタームを全て参照する必要があり、ファセットのリストをつくるためにドキュメントのIDを取り出さなければいけない。Solrでは、これらのメモリ上でこれらの処理をおこなっており、ロードする処理が遅くなることがある。
Lucene 4.0 の DocValues はこの課題を解消するために、インデックスの作り方を変えた。インデックス時に、Doc-to-Value マッピングを作成する、カラム指向なフィールドである。この方法は、フィールドキャッシュに必要なメモリの量を和らげ、ファセット、ソート、グルーピングを高速化する。
https://cwiki.apache.org/confluence/display/solr/DocValues
設定方法は、Elasticserch は mapping、Solr は schema.xml でいずれも設定が可能です。設定後は、再インデックスが必要になります。
まとめ
ファセット用の項目は、形態素やタームに分解されないように別途定義を用意しているケースが多いと思いますが、DocValues も積極的に設定してみてもいいかもと思いました。また、Kibana 4 も同時リリースされましたが、Aggregation で使用する項目に設定しても、高速化が期待できるかもしれませんね。
