HBaseを読む（２）ビッグデータの夜明け、ＲＤＢの問題点

ＮＨＮカンファレンスでもらったHBaseの本を、ざっと斜め読みして、適当にまとめるシリーズ「HBaseを読む」の続きです。
ちゃんとした情報を知りたい人は、HBaseの本を見てください。

今回は、１．１、１．２章

---

■１章　HBaseの紹介
・なぜまた別のストレージアーキテクチャを扱う必要があるのか
　　→ＲＤＢＭＳ：いまでも有効
　　→このモデルがあまりうまくは適合しない、特定の課題もありそう

■１．１　ビッグデータの夜明け
・Ｈａｄｏｏｐ　数ペタバイトに及ぶデータを収集
　　→それ以上のデータを収集する必要性
　　　　　：機械学習などで、さらに増大
　　→これまで：すべての情報を保存するコスト効率のよい方法なし
　　　　　特定のデータソース無視してよかった
　　　　　→いまや、そういった企業は競争に敗れそう
　　　　　→期間全体にわたる数学モデルの構築：機会を失う
　　　　　　Ralph Kimball
　　　　　　　データ資産はバランスシート状の主要な構成要素
　　　　　　　２０世紀における既存の物理的な資産を置き換える
　　　　　　　データの価値が広く認識

・Ｇｏｏｇｌｅ，Ａｍａｚｏｎ：データの価値を理解
　　Ｇｏｏｇｌｅ：スケーラブルなストレージとデータ処理
　　　→Ｇｏｏｇｌｅの外部で、オープンソースのHadoop
　　　　　　HDFSとMapReduce

・Ｈａｄｏｏｐの強み
　　任意のあるいは半構造化された、あるいはまったく構造化されて
　　いないフォーマットのデータの保存
　　　　→データの解釈を分析の時点で決められる
　　既存のデータベースシステムを補完
　　　　無限データを保存
　　　　適切タイミングでデータ取り出し
　　　　巨大なファイルの保存やバッチ処理、ストリーミング型アクセス
　　　　　に最適化されている

・ユーザー：バッチでなく、ランダムアクセスも
　→構造化されたデータのランダムアクセス：ＤＢへクエリに慣れている
　　　ＲＤＢＭＳ：Ｃｏｄｄの１２のルール
　　　　　→非常に厳格な要求
　　　　　　大きな変化はない
　　　近年：列指向、あるいは大規模分散処理データベース

・列指向データベース
　　データを列でグループ化
　　　　ある列の値は非常に良く似た性質
　　　　　→行指向のレコード構造に比べて、圧縮しやすい
　　HBase:列指向データベースではなく
　　　　　列指向のフォーマットを利用しているだけ

・地球サイズのＷｅｂアプリケーション
　　例：Ｆａｃｅｂｏｏｋなど
　ある主要な産業界のそれほどＷｅｂを主体としない企業でも
　収集データの量は増加（以下に例）
　　　金融
　　　バイオセマンティックス
　　　スマートグリッド（ＯｐｅｎＰＤＣ）
　　　販売
　　　ゲノム学
　　　携帯電話、軍隊、環境問題
　数ペタバイトに及ぶデータを効率的に保存、更新
　　　→容易ではない。

---

■１．２　リレーショナルシステムの問題点

たとえば、HBaseのＵＲＬ短縮サービスHushのサービスを考える

・はじめ：ＬＡＭＰで実装
　　　データを正規化
　　　インデックス
　　　ストアドプロシジャ
　　　強い一貫性

・データ数増加：負荷増大
　　→読み出しを並列＝スレーブのＤＢサーバー追加

・そのつぎに
　　キャッシュの追加(Memcachedなど）
　　　→一貫性の保証失われつつある

・書き込みの負荷が厳しい場合
　　ＣＰＵ，メモリ、ディスクを強力に→スケールアップ
　　→コストかかる
　　→スレーブもマスタ同様強力にしないと

・アプリケーションに機能追加
　　ＳＱＬのＪＯＩＮ速度急速に低下
　　　　スキーマの非正規化
　　　　最もコストの高いクエリの事前マテリアライズ化
　　　　セカンダリインデックス：メンテナンス負荷
　　　　　　→主キーのみに
　　　　データをシャーディング
　　　　　　→運用上の悪夢

シャーディング
　　レコードを水平なパーティションに論理的に分割すること
　　シャードのやりなおし：時間かかる
　　→仮想シャード

多くの企業はＲＤＢＭＳを使ってうまくいっている
　　新しい製品の実装を始めるにあたって、
　　利用可能なあらゆる選択肢を持っておいたほうがいい

---

次回は１．３章から