@ueshin あれ、でもコード変更ないみたいですね。"majorcompaction = true;" これですか?
2011-08-31 01:12:20@shiumachi あ、そうですね。そのフラグがのちにメジャーコンパクションへとつながります。よくわからない条件は689〜694あたりですね。。。
2011-08-31 01:16:16hbase.hregion.majorcompactionを0(major compactionを自動実行しない)にしていても Store.javaの709行目の条件を満たすとmajor compactionは自動実行されるのだー cdh3u1の話です #hbase
2011-08-31 18:49:57で それはYCSBをグリグリやるような ひとつのテーブルだけ更新され続ける そんな特殊な状況でしか発生しない どうでしょう? #hbase
2011-08-31 18:54:11さて、遅くなりましたがこないだの続き。 メジャーコンパクションとなる最後の条件は、コンパクションをかけようとしているStore(=リージョン内のカラムファミリー毎に分かれた部分)にあるファイルに特別大きなファイルがなくて、ファイル数が指定値以下であること、かな。
2011-09-04 23:37:51特別大きなファイル、というのは、 "hbase.hstore.compaction.min.size"という設定で指定したサイズ(デフォルトは "hbase.hregion.memstore.flush.size" の設定値で、これのデフォルトは64MB)と、(続
2011-09-04 23:38:07同時にコンパクションされるファイルのサイズ合計 * "hbase.hstore.compaction.ratio"の設定値(デフォルトは1.2)のうち、どちらか大きい方、よりも大きいファイル。
2011-09-04 23:38:21例えばリージョン分割が発生しない状況だとすると、はじめは小さなファイルができるのでコンパクションのたびにメジャーコンパクション扱いとなるけど、しばらくするとファイルサイズが大きくなってくるので、そのStoreは明示的にメジャーコンパクションの指示がない限りはメジャーじゃなくなる。
2011-09-04 23:40:22ところでメジャーコンパクション扱いになるといっても、実装的には対象のファイルを全部読み込んで新しいファイルにコピーするようになっているだけで、メジャーとの違いは削除されたものを読み込むかどうかの違いでしかなく、ファイルが少ない場合にはむしろメジャーにしたほうが効率が良さそう。
2011-09-04 23:42:36Store内のファイルが多くなった時のメジャーコンパクションや、定期メジャーコンパクションで一気にやると大変な負荷がかかることになる。
2011-09-04 23:43:00あとリージョン分割は、分割時点では親リージョンの前半分、後半分へのリファレンスを子供リージョンがそれぞれ保持するだけなのでそれ自体ではそんなに負荷にならなそうだけど、その次のコンパクションでは全ファイルが処理対象になるので、そちらが問題になりそう。
2011-09-04 23:45:59ちなみにMapReduceでデータ投入中にリージョン分割が起こると結構な確率で落ちるので気をつけましょう。最近は自動リージョン分割はオフにするのを推奨されているそうな。
2011-09-04 23:51:14というわけで自動メジャーコンパクションをオフっててもメジャーコンパクション相当の処理が走ることがあるし、ログにも出る。
2011-09-05 00:02:251時間くらいの定期でメジャーコンパクションが発生していたのは1時間くらいでコンパクションになっていたからでは。しかもYCSBが全リージョンに均等に書き込みを行なっていればほぼ同時にコンパクションされる。リージョン分割が発生しなければしばらくするとメジャーではなくなるのかな。
2011-09-05 00:10:13