メモリにロードする必要がある。このフィールドデータは数十GBのメモリを使うことはよく知られている。メモリは安くなってきたので、メモリを追加すること自体には普通やるし問題ない。レベルのメモリ管理の話で、数十GB単位のヒープに対するメジャーGCは、容易に数秒はかかるため、その間あなたのアプリは完全にストップすることになる。ヒープには保存しないほうがよりピッタリだと思う。http://www.elasticsearch.org/blog/disk-based-field-data-a-k-a-doc-values/また、データをヒープで管理しないことで、OSレベルのディスクキャッシュ用のメモリ上で管理されるようになりますので、安定性が増す形になります。このメモリをより効率的に使えるようになった、ということでしょう。導入された機能キーワード検索では、転置インデックスを用いることで高速に検索することができるが、facetやソート、ハイライトについてはかなり遅かった。ファセッティング・エンジンは、検索結果に表示される各ドキュメントの中に含まれるタームを全て参照する必要があり、ファセットのリストをつくるためにドキュメントのIDを取り出さなければいけない。Solrでは、これらのメモリ上でこれらの処理をおこなっており、ロードする処理が遅くなることがある。この課題を解消するために、インデックスの作り方を変えた。マッピングを作成する、カラム指向なフィールドである。この方法は、フィールドキャッシュに必要なメモリの量を和らげ、ファセット、ソート、グルーピングを高速化する。いずれも設定が可能です。設定後は、再インデックスが必要になります。積極的に設定してみてもいいかもと思いました。使用する項目に設定しても、高速化が期待できるかもしれませんね。第8回elasticsearch勉強会どうも!今日も勉強会に参加いたしました。第7回elasticsearch勉強会どうも!久しぶりのエントリーです。調べてみたけど、ちょっと違ったという話。こんな投稿をしていたのですが。第6回elasticsearch勉強会どうも!久しぶりの勉強会参加です。はてなブログPro検索プラットフォームの開発・運用をしているプログラマーです。好き勝手なことを綴りますが、どうぞ宜しくお願いします。所属組織とは関係のない個人の見解です。(41)月別アーカイブはてなブログをはじめよう!yoshi0309さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。