HBaseのデータモデルではこのような制約はなく、キーを動的に定義できるため、いわゆるスパースな（テーブルとして表現した時に値がまばらにしか存在しない）データの格納も可能です。ところがリレーションの存在を前提とするデータ集合に対する演算操作やデータの矛盾を排除する仕組みは基本的に用意されていません。これがアプリケーションの用途の選択に与える影響は、後半で説明していきます。
次にHBaseの実装について簡単に説明しましょう。HBaseクラスタの構成要素にはデータを格納、処理する「Region Server」、メタデータを管理し、各サーバを調整する「Master」、構成情報を管理する「ZooKeeper」サーバがあります。それぞれの要素は障害に備え、複数台のサーバで構成されています。
上記で説明したHBaseテーブルのデータは行キーでソートされた状態で格納されていますが、行キーの範囲を基準として“リージョン”という単位に分割され、各リージョンはクラスタ内のRegion Serverに分散して格納、処理されます。さらに、カラムは“カラムファミリー”という単位でグループ化され、各カラムファミリーは独立したメモリ領域やファイルのセットを管理する形になっています。このようにデータを物理的に分散した上で、並列にそれぞれのデータに対して独立してアクセス、処理することで、非常に高いスケーラビリティを実現しています。
図2：HBaseクラスタ構成とテーブルの物理配置（筆者作成）
データの読み書きは、Region Serverに搭載する大容量のメモリと、データファイルの格納に利用するHadoop分散ファイルシステム（Hadoop Distributed File System：HDFS）の特性を最大限利用しています。HDFSは、もともと主にバッチ処理を対象に設計されたこともあり、シーケンシャルな読み書きに特化されています。
このため、HBaseでは書き込みデータを直接ファイルシステム上のデータ構造に反映させることはせずにメモリ上に保持し、後ほどバックグラウンドでまとまった単位でファイルへの書き出しやファイルの再構成（コンパクション）を行っていきます 。全体的に見ると、メモリを介することで細かいランダムアクセスがシーケンシャルなディスクI/Oに変換されていることが分かりますが、これはディスクI/Oがボトルネックとなりがちな大規模データ処理環境でよい解決策になっています。
これまでに述べた概念をもとに設計されたHBaseがどのような特徴を持つシステムなのかを見ていきましょう。
高いスケーラビリティ
HBaseを使う上で最大のメリットは、非常な大きな規模まで拡張が可能なスケーラビリティの高いアーキテクチャにあるでしょう。運用を続けるうちにさらに容量が必要になった場合には、単純にサーバの台数を増やすことで拡張が可能です。
モバイルアプリ解析の米Flurryは1200ノードを超えるHBaseクラスタを運用しており、データ分析業務の中核として利用しています。米Yahoo!では7つのHBaseクラスタで6Pバイト以上のデータを格納していると言われ、実際にこのような規模で運用されているNoSQLデータベースはHBaseをおいて他にはありません。
シャーディングによる負荷の分散
HBaseに格納されるデータは、上述の通り行キーによりリージョンに分割されます。テーブルを物理的に分割するという意味でRDBMSにおけるレンジパーティションに似ていますが、HBaseの各リージョンは複数のサーバに分散して配置され、各サーバはそれぞれが管理するリージョンに格納されたデータに対する処理を並列に実行することにより、全体の性能向上が図られます。これは「シャーディング」と呼ばれます。さらにリージョンの分割やリバランスを自動で行う機能も備えています。
