HBaseのコンパクションまわりを調べてみた件。

10
Takuya UESHIN @ueshin

@shiumachi あれ、なぜか cdh3u0 見てました。。。 まだ手元にあったのか。w

2011-08-31 01:08:55
Sho Shimauchi @shiumachi

@ueshin あれ、でもコード変更ないみたいですね。"majorcompaction = true;" これですか?

2011-08-31 01:12:20
Takuya UESHIN @ueshin

@shiumachi あ、そうですね。そのフラグがのちにメジャーコンパクションへとつながります。よくわからない条件は689〜694あたりですね。。。

2011-08-31 01:16:16
Sho Shimauchi @shiumachi

@ueshin while 文の中ですね。その上の長いコメントに説明が書いてますけど、確かにややこしいですね

2011-08-31 01:23:44
Takuya UESHIN @ueshin

@shiumachi そうなんすよね。寝ぼけた頭にはきついのでまた明日にします。w ではおやすみなさい〜。

2011-08-31 01:26:36
hamburgerkid @hamburger_kid

hbase.hregion.majorcompactionを0(major compactionを自動実行しない)にしていても Store.javaの709行目の条件を満たすとmajor compactionは自動実行されるのだー cdh3u1の話です #hbase

2011-08-31 18:49:57
hamburgerkid @hamburger_kid

で それはYCSBをグリグリやるような ひとつのテーブルだけ更新され続ける そんな特殊な状況でしか発生しない どうでしょう? #hbase

2011-08-31 18:54:11
Takuya UESHIN @ueshin

さて、遅くなりましたがこないだの続き。 メジャーコンパクションとなる最後の条件は、コンパクションをかけようとしているStore(=リージョン内のカラムファミリー毎に分かれた部分)にあるファイルに特別大きなファイルがなくて、ファイル数が指定値以下であること、かな。

2011-09-04 23:37:51
Takuya UESHIN @ueshin

特別大きなファイル、というのは、 "hbase.hstore.compaction.min.size"という設定で指定したサイズ(デフォルトは "hbase.hregion.memstore.flush.size" の設定値で、これのデフォルトは64MB)と、(続

2011-09-04 23:38:07
Takuya UESHIN @ueshin

同時にコンパクションされるファイルのサイズ合計 * "hbase.hstore.compaction.ratio"の設定値(デフォルトは1.2)のうち、どちらか大きい方、よりも大きいファイル。

2011-09-04 23:38:21
Takuya UESHIN @ueshin

ファイル数の指定値は "hbase.hstore.compaction.max" (デフォルト: 10)。

2011-09-04 23:38:30
Takuya UESHIN @ueshin

例えばリージョン分割が発生しない状況だとすると、はじめは小さなファイルができるのでコンパクションのたびにメジャーコンパクション扱いとなるけど、しばらくするとファイルサイズが大きくなってくるので、そのStoreは明示的にメジャーコンパクションの指示がない限りはメジャーじゃなくなる。

2011-09-04 23:40:22
Takuya UESHIN @ueshin

リージョンが分割されれば、しばらくするとファイルが小さくなるのでまたメジャーコンパクション扱いになる。

2011-09-04 23:40:34
Takuya UESHIN @ueshin

ところでメジャーコンパクション扱いになるといっても、実装的には対象のファイルを全部読み込んで新しいファイルにコピーするようになっているだけで、メジャーとの違いは削除されたものを読み込むかどうかの違いでしかなく、ファイルが少ない場合にはむしろメジャーにしたほうが効率が良さそう。

2011-09-04 23:42:36
Takuya UESHIN @ueshin

Store内のファイルが多くなった時のメジャーコンパクションや、定期メジャーコンパクションで一気にやると大変な負荷がかかることになる。

2011-09-04 23:43:00
Takuya UESHIN @ueshin

あとリージョン分割は、分割時点では親リージョンの前半分、後半分へのリファレンスを子供リージョンがそれぞれ保持するだけなのでそれ自体ではそんなに負荷にならなそうだけど、その次のコンパクションでは全ファイルが処理対象になるので、そちらが問題になりそう。

2011-09-04 23:45:59
Takuya UESHIN @ueshin

ちなみにMapReduceでデータ投入中にリージョン分割が起こると結構な確率で落ちるので気をつけましょう。最近は自動リージョン分割はオフにするのを推奨されているそうな。

2011-09-04 23:51:14
Takuya UESHIN @ueshin

というわけで自動メジャーコンパクションをオフっててもメジャーコンパクション相当の処理が走ることがあるし、ログにも出る。

2011-09-05 00:02:25
Takuya UESHIN @ueshin

1時間くらいの定期でメジャーコンパクションが発生していたのは1時間くらいでコンパクションになっていたからでは。しかもYCSBが全リージョンに均等に書き込みを行なっていればほぼ同時にコンパクションされる。リージョン分割が発生しなければしばらくするとメジャーではなくなるのかな。

2011-09-05 00:10:13
Takuya UESHIN @ueshin

ソース読んだ感じだと、そんな動きになっているような気がします。なにか間違いがあれば指摘していただければと〜。

2011-09-05 00:17:45