HBaseの性能について
noracorn
HBaseの質問をさせて下さい。
HBaseの性能指標を出そうとしているのですが、なかなか良い資料がなく困っています。
HBaseへの書き込み性能と、検索性能についての情報がまとまっている
サイトやPDFがありましたら、教えてください。
Kauzki Aranami
少し情報としては、古いのですが下記の論文とスライドにベンチマークの
結果がまとまっているので、参考にされてみてはいかがでしょうか？
論文
http://research.yahoo.com/node/3202
スライド
http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
ベンチマークツール自体は、下記にあるので自分で計測することもできそうです。
https://github.com/brianfrankcooper/YCSB/wiki/
-----------------------------------------------------------
コンプレクッスネットワークテクノロジー
荒浪 一城（Kazuki Aranami）
Twitter: http://twitter.com/kimtea
http://complex-network-technology.jp/
-----------------------------------------------------------
2010年11月22日17:38 noracorn <nora...@mail.goo.ne.jp>:
Tatsuya Kawano
noraconさん、こんにちは。
>> HBaseの性能指標を出そうとしているのですが、なかなか良い資料がなく困っています。
性能指標ですが、ほとんど見つからないのが現状です。kimteaさんご紹介の YCSB の他に、断片的に紹介できるものはありますが、どれもハードウェア構成が異なります。ですから、それらをそのまま noraconさんのケースに当てはめるのも難しいと思います。
また、HBase にとって、性能面（特に randam read 性能）は、日々改善が著しい部分です。例えば、YCSBの v4 レポート（今年の４月）も、あるバージョンの HBaseと、あるハードウェア構成の組み合わせで測定した１つのスナップショットに過ぎません。最新版の YCSB 0.1.3 と HBase 0.20.6 では、random read のレイテンシが、以前と比較して半分以下の40%になったとの報告もあります。まもなく、HBase 0.90 がリリースされますが、こちらは、bloom filter が再実装されていますので、random readの性能もさらに向上していると思われます。
さらに、どのデータベースでもそうですが、データへのアクセスパターンによって、性能が大きく変わります。HBase の場合は、単独の Get（random read）が性能面で最悪のシナリオです。しかし、行キーをうまく設計して、これをScan（sequencial read）に変えられると、スループットが大幅に向上します。ですから、アプリケーション側の設計も重要です。
つまり、アプリケーションのデータへのアクセスパターン、HBase のバージョン、ハードウェアの選定によって、HBase が使えるものになったり、使えないものになったりします。プロジェクトの早期に性能を検証するフェーズを入れて、YCSBなどをベースに、ワークロード（作成しようとしているアプリのアクセスパターン）を実装して、測定することをおすすめします。また、同時に MySQL クラスターのような選択肢も残しておいてください（NoSQLは発展途上です）
>> HBaseへの書き込み性能と、検索性能についての情報がまとまっている
HBase は、random write が最も高速です。一方、random read が最も低速、性能上のボトルネックになります。
random write > sequential read > sequential write > random read の順だと思えば間違いないです。
ですから、検索性能（random read？）が目標に届くように、アプリからのアクセスパターンを設計して、ハードウェアの構成を決めることになります。この性能は、それが Getなのか、Scanなのかと、サーバーに搭載した RAM の量、ハードディスクドライブの性能によって大きく変わると思います。また、当然、ワーカー用のサーバーの台数によっても変わります。
多分、いま世界で最速の HBase クラスターは、Adobeのテスト用クラスターです。
http://hstack.org/hbase-performance-testing/
サーバー１台あたりの構成は、8コアCPU、32GB RAM、10,000 RPS の SAS ディスクを 24台（本番機は16台に減らした） この構成のサーバーをワーカー用として７台使っています。HBase は、今年の２月時点の trunk からビルドしたものを使用しており、現在リリースされている 0.20 系よりも、まもなくリリースされる 0.90 系に近いはずです。
上記のテスト結果（１レコードは 128～256バイトで、件数は30億件）ですと、600スレッドからの Get/Put 混合（70% Get / 30% Put）で、平均レイテンシが 26.48 ms、スループットが22,659 qps（クエリ/秒）となっています。300スレッドなら、14.62 ms、20,520 qps。
HBaseは、他の高速性をうたう NoSQL と比べると、平凡な read 性能しか発揮しません。性能面での他との違いは、データがメモリーに収まらなくなっても性能が落ちないことと、クラスターの台数を数百台まで増やしても、リニアにスケールすること、つまり、大規模データ向けです。
通常の予算では、１台のサーバーに、ディスクを24台とか16台とか搭載することはまずないでしょう。StumbleUponでは、４台しか搭載していません。一般的には４～12台だそうです。台数が多いほうが、random readが速くなります。
RAMは、Map Reduceも動かすなら最低 8GB、Map Reduceを動かさないなら最低 4GB 必要です。Map Reduceも動かす場合の Cloudera の推奨は、24～32GBとなっています。RAMが多いほうが安定して動作します。また、readキャッシュを大きくとれますので、RAMが多いと実運用の random read も速くなります（一方、ベンチマークだとキャッシュの効果はほとんどでません）
以下の２つの記事が参考になります。
http://www.cloudera.com/blog/2010/03/clouderas-support-team-shares-some-basic-hardware-recommendations/
http://www.cloudera.com/blog/2010/08/hadoophbase-capacity-planning/
ノード数は、HA構成なら、マスター系が２台。ワーカー系が最低４台か５台用意するのが無難です。残念ながら、いまの HBase はスモールスタートには向きません。もし台数を減らすなら、マスターを１台にして、フェイルオーバー先をワーカーノードにしてください。ワーカーを減らしては絶対にダメです。
RAMは、8GBから始めて、データ量が増えたら 32GBくらいまで段階的に増やしていってもいいかもしれません。randam read性能を稼ぐなら、ディスク性能とディスク台数が最重要で、次に RAM 容量です。ディスクはSASで、高回転のものを最低４台。SSDは高価ですが大きな効果がありそうですので、データ容量があまり大きくない場合は検討の余地もあるかもしれません。
最低台数が決まってしまっていますので、高価なクラスターとなりますが、HBase 0.92で搭載される予定のセキュリティ機能を使えば、１つのクラスターを複数のサービスで共有することが可能になると思います。
たつや
--
Tatsuya Kawano
Tokyo, Japan
http://twitter.com/#!/tatsuya6502
どうも@kimteaこと荒浪です。
少し情報としては、古いのですが下記の論文とスライドにベンチマークの
結果がまとまっているので、参考にされてみてはいかがでしょうか？
ベンチマークツール自体は、下記にあるので自分で計測することもできそうです。
https://github.com/brianfrankcooper/YCSB/wiki/
noracorn
さっそくの返信ありがとうございます。
資料のほう活用させていただきます。
必要な環境の構成を出すために、資料から計算しようとしています。
HDFSの資料は多く存在するのですが、HBaseは資料が少ないですね。
ありがとうございます。
On Nov 22, 6:50 pm, Kauzki Aranami <kazuki.aran...@gmail.com> wrote:
> どうも@kimteaこと荒浪です。
>
> 少し情報としては、古いのですが下記の論文とスライドにベンチマークの
> 結果がまとまっているので、参考にされてみてはいかがでしょうか？
>
> 論文http://research.yahoo.com/node/3202
> ベンチマークツール自体は、下記にあるので自分で計測することもできそうです。https://github.com/brianfrankcooper/YCSB/wiki/
>
> -----------------------------------------------------------
> コンプレクッスネットワークテクノロジー
> 荒浪 一城（Kazuki Aranami）
>
> Twitter:http://twitter.com/kimtea
> http://complex-network-technology.jp/
> -----------------------------------------------------------
>
noracorn
Hbase構成を机上でいろいろ決めて、予算を出すのは難しそうですね。
実際に動かしてみて、性能が出るか出ないかとなると思います。
その場合は、HBaseが選択されるかわかりませんが。。
というわけで、少しごまかして資料を作成してみます。
上記で述べられている構成や資料など、非常に参考になりました。
ありがとうございました。
On 11月23日, 午前11:41, Tatsuya Kawano <tatsuya6...@gmail.com> wrote:
> noraconさん、こんにちは。
>
> >> HBaseの性能指標を出そうとしているのですが、なかなか良い資料がなく困っています。
>
> 性能指標ですが、ほとんど見つからないのが現状です。kimteaさんご紹介の YCSB の他に、断片的に紹介できるものはありますが、どれもハードウェア構成が異なります。ですから、それらをそのまま noraconさんのケースに当てはめるのも難しいと思います。
>
> また、HBase にとって、性能面（特に randam read 性能）は、日々改善が著しい部分です。例えば、YCSBの v4 レポート（今年の４月）も、あるバージョンの HBaseと、あるハードウェア構成の組み合わせで測定した１つのスナップショットに過ぎません。最新版の YCSB 0.1.3 と HBase 0.20.6 では、random read のレイテンシが、以前と比較して半分以下の40%になったとの報告もあります。まもなく、HBase 0.90 がリリースされますが、こちらは、bloom filter が再実装されていますので、random readの性能もさらに向上していると思われます。
>
> さらに、どのデータベースでもそうですが、データへのアクセスパターンによって、性能が大きく変わります。HBase の場合は、単独の Get（random read）が性能面で最悪のシナリオです。しかし、行キーをうまく設計して、これをScan（sequencial read）に変えられると、スループットが大幅に向上します。ですから、アプリケーション側の設計も重要です。
>
> つまり、アプリケーションのデータへのアクセスパターン、HBase のバージョン、ハードウェアの選定によって、HBase が使えるものになったり、使えないものになったりします。プロジェクトの早期に性能を検証するフェーズを入れて、YCSBなどをベースに、ワークロード（作成し ようとしているアプリのアクセスパターン）を実装して、測定することをおすすめします。また、同時に MySQL クラスターのような選択肢も残しておいてください（NoSQLは発展途上です）
>
> >> HBaseへの書き込み性能と、検索性能についての情報がまとまっている
>
> HBase は、random write が最も高速です。一方、random read が最も低速、性能上のボトルネックになります。
> random write > sequential read > sequential write > random read の順だと思えば間違いないです。
>
> ですから、検索性能（random read？）が目標に届くように、アプリからのアクセスパターンを設計して、ハードウェアの構成を決めることになります。この性能は、それが Getなのか、Scanなのかと、サーバーに搭載した RAM の量、ハードディスクドライブの性能によって大きく変わると思います。また、当然、ワーカー用のサーバーの台数によっても変わります。
>
> 多分、いま世界で最速の HBase クラスターは、Adobeのテスト用クラスターです。http://hstack.org/hbase-performance-testing/
>
> サーバー１台あたりの構成は、8コアCPU、32GB RAM、10,000 RPS の SAS ディスクを 24台（本番機は16台に減らした） この構成のサーバーをワーカー用として７台使っています。HBase は、今年の２月時点の trunk からビルドしたものを使用しており、現在リリースされている 0.20 系よりも、まもなくリリースされる 0.90 系に近いはずです。
>
> 上記のテスト結果（１レコードは 128～256バイトで、件数は30億件）ですと、600スレッドからの Get/Put 混合（70% Get / 30% Put）で、平均レイテンシが 26.48 ms、スループットが22,659 qps（クエリ/秒）となっています。300スレッドなら、14.62 ms、20,520 qps。
>
> HBaseは、他の高速性をうたう NoSQL と比べると、平凡な read 性能しか発揮しません。性能面での他との違いは、データがメモリーに収まらなくなっても性能が落ちないことと、クラスターの台数を数百台まで増やしても、リニア にスケールすること、つまり、大規模データ向けです。
>
> 通常の予算では、１台のサーバーに、ディスクを24台とか16台とか搭載することはまずないでしょう。StumbleUponでは、４台しか搭載していません。 一般的には４～12台だそうです。台数が多いほうが、random readが速くなります。
>
> RAMは、Map Reduceも動かすなら最低 8GB、Map Reduceを動かさないなら最低 4GB 必要です。Map Reduceも動かす場合の Cloudera の推奨は、24～32GBとなっています。RAMが多いほうが安定して動作します。また、readキャッシュを大きくとれますので、RAMが多いと実運用の random read も速くなります（一方、ベンチマークだとキャッシュの効果はほとんどでません）
>
> 以下の２つの記事が参考になります。http://www.cloudera.com/blog/2010/03/clouderas-support-team-shares-so...http://www.cloudera.com/blog/2010/08/hadoophbase-capacity-planning/
>
> ノード数は、HA構成なら、マスター系が２台。ワーカー系が最低４台か５台用意するのが無難です。残念ながら、いまの HBase はスモールスタートには向きません。もし台数を減らすなら、マスターを１台にして、フェイルオーバー先をワーカーノードにしてください。ワーカーを減らしては絶 対にダメです。
>
> RAMは、8GBから始めて、データ量が増えたら 32GBくらいまで段階的に増やしていってもいいかもしれません。randam read性能を稼ぐなら、ディスク性能とディスク台数が最重要で、次に RAM 容量です。ディスクはSASで、高回転のものを最低４台。SSDは高価ですが大きな効果がありそうですので、データ容量があまり大きくない場合は検討の余地もあ るかもしれません。
>
> 最低台数が決まってしまっていますので、高価なクラスターとなりますが、HBase 0.92で搭載される予定のセキュリティ機能を使えば、１つのクラスターを複数のサービスで共有することが可能になると思います。
>
> たつや
>
> --
> Tatsuya Kawano
> Tokyo, Japan
>
> http://twitter.com/#!/tatsuya6502
>
> On 11/22/2010, at 6:50 PM, Kauzki Aranami wrote:
>
> どうも@kimteaこと荒浪です。
>
> 少し情報としては、古いのですが下記の論文とスライドにベンチマークの
> 結果がまとまっているので、参考にされてみてはいかがでしょうか？
>
> 論文http://research.yahoo.com/node/3202
> スライドhttp://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
>
> ベンチマークツール自体は、下記にあるので自分で計測することもできそうです。https://github.com/brianfrankcooper/YCSB/wiki/
>
> -----------------------------------------------------------
> コンプレクッスネットワークテクノロジー
> 荒浪 一城（Kazuki Aranami）
>
> Twitter:http://twitter.com/kimtea
> http://complex-network-technology.jp/
> -----------------------------------------------------------
>
> 2010年11月22日17:38 noracorn <norac...@mail.goo.ne.jp>:
> noracornです。
> HBaseの質問をさせて下さい。
>
> HBaseの性能指標を出そうとしているのですが、なかなか良い資料がなく困っています。
> HBaseへの書き込み性能と、検索性能についての情報がまとまっている
> サイトやPDFがありましたら、教えてください。
>
> On 11/22/2010, at 6:50 PM, Kauzki Aranami wrote:
>
>
>
>
>
>
>
> > どうも@kimteaこと荒浪です。
>
> > 少し情報としては、古いのですが下記の論文とスライドにベンチマークの
> > 結果がまとまっているので、参考にされてみてはいかがでしょうか？
>
> > 論文
> >http://research.yahoo.com/node/3202
> > スライド
> >http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
>
> > ベンチマークツール自体は、下記にあるので自分で計測することもできそうです。
> >https://github.com/brianfrankcooper/YCSB/wiki/
>
> > -----------------------------------------------------------
> > コンプレクッスネットワークテクノロジー
> > 荒浪 一城（Kazuki Aranami）
>
> > Twitter:http://twitter.com/kimtea
> > http://complex-network-technology.jp/
> > -----------------------------------------------------------
>
> > 2010年11月22日17:38 noracorn <norac...@mail.goo.ne.jp>: