HBase本(馬本）刊行記念 著者Lars George氏 来日特別セミナーまとめ
-
- いいね！8
Sho Shimauchi
@shiumachi
クラスタのサイジング。過去1,2年多くのお客様と話をした上で自分で学んできた注意点に関する話 #hbaselars
2012-10-12 19:43:29
Sho Shimauchi
@shiumachi
HBase は HDFS 上で稼働するが、読み込みと書き出しはコードパスとしては別々で実装として重なる部分はないが、実際にはリソースを奪い合う。RPCのスレッドプールなどがいい例 #hbaselars
2012-10-12 19:44:47
Sho Shimauchi
@shiumachi
Java プロセス内におけるメモリの使用について。リードとライトについて別に割り当てる。40%が書き込み、20%が読み込み、残り40%がJava 自体が使う(全部デフォルト値) #hbaselars
2012-10-12 19:46:00
Sho Shimauchi
@shiumachi
まず読み込みについて。リージョンサーバの配置とリクエストの配分に気をつける必要がある。一つはプリフェッチのオプションを指定すること。クライアント側で指定しておけば、2回目のアクセスからはさらに高速にルックアップ・アクセスできるようになる #hbaselars
2012-10-12 19:48:25
Sho Shimauchi
@shiumachi
クライアントが一旦どのリージョンにアクセスするかということがわかれば、ブルームフィルタを使い、またブロックキャッシュにアクセスしてもしヒットすれば高速に読み込むことができる #hbaselars
2012-10-12 19:49:38
Sho Shimauchi
@shiumachi
ブロックキャッシュ。ヒット率や排除率を確認することができるメトリクスがある。ブロックキャッシュのサイズはデフォルトで全ヒープの20%。調整は可能だが、完全に無効化するのはよくない #hbaselars
2012-10-12 19:50:48
Sho Shimauchi
@shiumachi
書き込みについて。書き込みによってクラスタサイズを決定する。Log structured merge tree を採用していることが原因。これはBigtable よりも古い技術。 #hbaselars
2012-10-12 19:52:15
Sho Shimauchi
@shiumachi
変更(put, delete)はインメモリのストアと先行書き込みログ(WAL) の両方に格納される #hbaselars
2012-10-12 19:52:53
Sho Shimauchi
@shiumachi
メモリがいっぱいになる(デフォルトの40%を上回る)と、フラッシュアウトしファイルに書き込まれる。 #hbaselars
2012-10-12 19:53:45
Sho Shimauchi
@shiumachi
先行書き込みは必要なときにリプレイする。バックグラウンドではコンパクションが行われ、小さいファイルを大きいファイルにまとめる #hbaselars
2012-10-12 19:55:06
Sho Shimauchi
@shiumachi
書き込み性能ボトルネックの注意点。キーの分散。全クラスタにバランスよく分散させる必要がある #hbaselars
2012-10-12 19:56:08
Sho Shimauchi
@shiumachi
RPCのハンドラが十分あるかどうか。スレッドプールの設定がきちんとできているか。先行書き込みログは次のスライドで説明 #hbaselars
2012-10-12 19:57:06
Sho Shimauchi
@shiumachi
コンパクション。バックグラウンドで小さいファイルを大きいファイルにまとめるので、チューニングが間違っていると性能ボトルネックの原因になる #hbaselars
2012-10-12 19:57:55
Sho Shimauchi
@shiumachi
先行書き込みログ(WAL) は現場でのNo.1 ボトルネック。1リージョンサーバに1つ。この問題解決のために開発中の機能。WAL圧縮(0.94) #hbaselars
2012-10-12 19:59:54
Sho Shimauchi
@shiumachi
WAL続き。デフォルトHDFSブロックの95%にサイズ設定する。なるべく小さく、しかし小さすぎず。ログサイズを大きくするとメモリに負荷がかかるがtoo many hlogs を避けるためにある程度のサイズも必要 #hbaselars
2012-10-12 20:02:32
Sho Shimauchi
@shiumachi
WALさらに続き。リージョン間で同期されるので大きいセルがあるだけで全体のパフォーマンスが低下する #hbaselars
2012-10-12 20:04:04
Sho Shimauchi
@shiumachi
WAL続き。WALをオフにすることもできるが、耐障害性を失うのであまりオススメしない。この対策としてコプロセッサでpreWALRestoreを使うというアイデアもあるが、いずれにせよおすすめできない #hbaselars
2012-10-12 20:05:34
Sho Shimauchi
@shiumachi
フラッシュ。メムストアがいっぱいになるとデータをディスクに書き出す。コンパクションも行われる。さらにファイルサイズを見てリージョンの適切サイズを超えていればさらにリージョン分割が行われる #hbaselars
2012-10-12 20:07:18
Sho Shimauchi
@shiumachi
コンパクションストーム。フラッシュなど、今まで説明した全てをきちんと管理しないとこれが発生する。小さいファイルを大きいファイルにまとめるという操作が繰り返され、IO性能が落ちる #hbaselars
2012-10-12 20:08:39
Sho Shimauchi
@shiumachi
フラッシュサイズ。ストアごとや列ファミリで決まるわけではない。3つの列ファミリがあるときその総和でディスクにフラッシュされる。 #hbaselars
2012-10-12 20:10:58
Sho Shimauchi
@shiumachi
HBase の書き込みパフォーマンスサイジング表。一般的なHDFS書き込みパフォーマンスは35-50MB/s。しかし現実には15MB/sかそれ以下になる。 #hbaselars
2012-10-12 20:12:40
Sho Shimauchi
@shiumachi
サーバ上のリージョン数に基づいてメムストアのサイズを計算。保存するログの数もフラッシュの比率などから計算。Heap サイズ、リージョン数とサイズ、キーの分散の程度などから容量を計算 #hbaselars
2012-10-12 20:14:30
Sho Shimauchi
@shiumachi
まとめとチートシート。以下のことを確認。WALの性能は十分以上を確保。メムストアの許容範囲を超えてクライアントが利用しないこと。フラッシュ頻度が上がる。 #hbaselars
2012-10-12 20:16:02