HBase勉強会行ってきました

ということで当日のメモ．
ポイントを絞ったので，かなりはしょった．削りすぎたかも...

HBaseの用途

柔軟なテーブル構造
  • Q.他のKVSと比べて柔軟なの?
    • A.Cassandraは動的に追加できる．HBaseはdisable，alterしないとダメ．
大規模データ向け(数十億件以上)
  • Q.1件あたりのデータサイズは?
    • 10KBくらいじゃね?
    • A.負荷のバランスを考えると実質パフォーマンスを維持できるのは2MBくらいまで
  • Q.下限は?
    • A.そこは確かめてください
    • 想定している範囲が見えづらいなあ
事例: Facebookメッセージング
  • 1クラスタあたり100台くらい (IDごとに割り振るらしい)
  • Q.100台以上で動かすのは危ないから!?
    • A.実践では100台くらいが上限ではないか
どんな用途に使いたいか?
  • MapReduceと組み合わせて使う
  • 大量データの高速処理
    • Twitter Streamingの解析に使いたい
    • インクリメンタル処理
    • 認証用DBとして
  • データのダムという表現はいいなあ
    • 会場の参加者もきっとそう思ったのでは

設計上の注意点

データモデル
  • ベストプラクティスはあんまりない．割と模索している感じ
  • 結局ローカリティはユーザが意識する必要がある
    • が，それでは負けだろう．作る方は楽しい．しかし，メンテは死ねる
write時に考慮すること
  • 例えば，ツイートIDをキーにするのは最悪．prefixにユーザID付けるのがよい
    • 先頭にランダムな文字を付けてもよい
  • RDBのように連番にすると，特定のリージョンに偏るのでNG
行キーの例
  • Webコンテンツの場合
    • 逆順のURLを使うと便利
  • ユーザの行動ログ
    • ユーザID - (Long.MAX_VALUE - タイムスタンプ)
    • ログデータはタイムスタンプがよく使われる
  • 業務系では色々考えないといけない
    • データに対して，どういう処理するか考えないと設計できない

HBaseの性能特性

  • Q.最適なクラスタの数
    • A.今使うなら数十台くらいじゃないか
  • Q.1台あたりの最適なリージョン数
    • A.難しい...MLでよくある質問だが，結局はデータサイズとアクセスパターンによる
自動シャーディング
  • 分割時の性能劣化はない
    • ファイルを2つにするわけではない．メタ情報を使って参照位置を変える．物理的には分割しない．
  • ある程度データがないと分散しない
    • Ver 0.90からは事前にスプリットできるようになったので，新しくテーブル作るときは必ずやりましょう

他

おまけ

  • 会場に質問した結果
    • プロダクションで使ってる人: 0
    • 試してる人: チラホラ
    • HBaseだからできるアプリ書いてる人: 0
  • 今日のよかった一言
    • 「我々が情報交換するのを見ていただく会」
    • 「自宅クラスタのために引っ越しました」