RDBがスケールしない理由+HBase

Masayoshi Hagiwara @masayh

RDBがスケールしない本質的な理由を考えてみたことがありますか？正規化、ディスクベース、I/Oコスト、join...なぜ？

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： 正規化（垂直分割の一種）、ディスクベース（有限メモリならどんんなデータモデルでもあり）、I/Oコスト（ディスクベースと同じく）、join（分割したものの複合化はデータモデルに依存しない）、トランザクション（更新系なら必要）。どれも違います。

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： ヒントはNoSQL

ビズアイユ @Bizuayeu

I/Oコストはオンメモリにすれば良いと思うので、ノード間でトランザクションを保障するためのオーバヘッドですかね。CPU的にもネットワーク的にも。 QT @masayh RDBがスケールしない本質的な理由を考えてみたことがありますか？正規化、ディスクベース、join...なぜ？

Masayoshi Hagiwara @masayh

残念ですが違います。@Bizuayeu I/Oコストはオンメモリにすれば良いと思うので、ノード間でトランザクションを保障するためのオーバヘッドですかね。

Masayoshi Hagiwara @masayh

I/Oコストはオンメモリにすれば良いと思う...簡単にオンメモリといいますが、性能を上げるにはインデックス、ハッシュテーブル、バケットなどいろんなデータ構造を適切なアルゴリズムとタイミングでオンメモリに乗せるので簡単ではありません。クラウドのデータは数百GBを想定して考えましょう

w.miya @wamiya

SQLのパースは分散処理出来ないからですかね。ノード感のデータ移動負荷はどの仕組みでも高いですし RT @masayh RDBがスケールしない理由： 正規化（垂直分割の一種）、ディスクベース（有限メモリならどんんなデータモデルでもあり）、I/Oコスト（ディスクベースと同じく）

ビズアイユ @Bizuayeu

んー、この記事の内容が答えに近いか？ http://bit.ly/anuEup QT @masayh 簡単にオンメモリといいますが、（略）いろんなデータ構造を適切なアルゴリズムとタイミングでオンメモリに乗せるので簡単ではありません。クラウドのデータは数百GBを想定して考えましょう

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： 行指向であること。ページサイズがOLTPに最適化されているので分析系でのI/Oの負荷が高いこと。行指向であることは、関係代数の徹底のために、挿入、変更対象データだけでなく、処理の中間データ形式までtupleを使い、B-treeが前提となっている点。

Masayoshi Hagiwara @masayh

行指向は人間が情報を扱う点でシステムのどこかで必ず出現し、主に入口で使われるので避けて通れません。ただ、RDBはそれをシステム全体で使っている点が制約で、その優れたアルゴリズムだけを取り出して、並列エンジンに乗せてNoSQLと組み合わせ、入口以外のところに適用していくのがいい。

Masayoshi Hagiwara @masayh

情報を行で扱うのは人間の意味の認識と深くかかわるので、避けて通れない自然の発想、概念です。それ自体は何も制約がない。

Masayoshi Hagiwara @masayh

@tatsuya6502 HBaseについて質問ですが、ブロックサイズの64KBは固定でしょうか。これはRDBでいうページサイズと同じI/Oの単位でしょうか？なぜ、64KBかの根拠はありますか？

Tatsuya Kawano @tatsuya6502

@masayh HBase のブロックサイズはRDBでいうページサイズと同じI/Oの単位で、テーブルのカラムファミリーごとに設定できます。小さくするとランダムアクセスが有利になり、大きくするとレンジスキャンが有利になります。

Tatsuya Kawano @tatsuya6502

@masayh なぜ、ディフォルトを64KBにしたかの根拠はわからないです（RDBだと4KBくらいですよね） 推測ですが、HDFSとのやりとりにコストがかかるので、少しまとめて取るのかも。最適値は平均的な行のサイズで決まりますので、チューニングすべきパラメータだと思います。

Masayoshi Hagiwara @masayh

ありがとうございます。64KBはOLTPには大きいし、データ分析には小さい中途半端な数字なので気になっていました。HDFSとの相性とか、Hadoopとの関係か @tatsuya6502 なぜ、ディフォルトを64KBにしたかの根拠はわからないです（RDBだと4KBくらいですよね）

Masayoshi Hagiwara @masayh

この大きさはディスクのスピンドル数の設計とセットで考えないといけませんね。@tatsuya6502 、チューニングすべきパラメータだと思います。

ICHIRO SATOH @ichiro_satoh

横から失礼。おそらくHbaseのもとになった、GoogleのBigtableのブロックサイズが64KBだったからでは。@tatsuya6502 @masayh なぜ、ディフォルトを64KBにしたかの根拠はわからないです（RDBだと4KBくらいですよね） 推測ですが、

Masayoshi Hagiwara @masayh

なるほど、それはありえますね。@ichiro_satoh おそらくHbaseのもとになった、GoogleのBigtableのブロックサイズが64KBだったからでは。

Tatsuya Kawano @tatsuya6502

@ichiro_satoh @masayh あ、そちらは64KBではなくて、64MBです。HFDSはランダムreadが可能なので、HBaseでは、HDFSファイルの中を論理的なブロックで区切って、seek+readしてます。

ICHIRO SATOH @ichiro_satoh

こちらはキーサイズの話だとおもっていたのですが・・・@tatsuya6502 @ichiro_satoh @masayh あ、そちらは64KBではなくて、64MBです。HFDSはランダムreadが可能なので、HBaseでは、HDFSファイルの中を論理的なブロックで区切って、…

Tatsuya Kawano @tatsuya6502

@ichiro_satoh @masayh 失礼しました。このブログ記事の真ん中あたり、HFileの中のDataと書かれたブロックについて話していました。 http://j.mp/4Hwp8U

Masayoshi Hagiwara @masayh

HBase使ってMapReduceするときは、ログのjoinではmaster dataが小さいときはrandom readでもメモリに載るのでログだけのsequential readを考えてブロックを大きくしておけばいいが、問題はmaster dataが大きい場合。今日説明しよう