HBaseのデータモデル
一般的に、データモデルは論理データモデルと物理データモデルを分けて考えることができます。HBaseの場合、論理データモデルと物理データモデルは非常に密接に関わっていますが、ここでは分けて考えていきたいと思います。
論理データモデル
HBaseの論理データモデルは多次元ソートマップです。
まず、RDBと同様にTableという概念が存在します。Tableには複数のRowが存在し、RowKeyで一意に特定されます。RowKeyはRDBで言うところの主キーのようなものです。すべてのRowは、RowKeyを使って常に辞書の順にソートされており、Rowには1つ以上のColumnが存在します。
HBaseでは、RDBと違いColumnはテーブル作成時に定義する必要がなく、後から自由に追加することができます。また、Tableには1つ以上のColumnFamilyが存在し、ColumnはいずれかのColumnFamilyに所属することになります。このColumnFamilyはテーブル作成時に定義する必要があります。
それぞれのColumnには、複数のバージョン（基本的にはTimestampで管理）を持たせることができ、バージョンごとに値（Value）を持つことができます。
図にすると以下のようになります。
また、プログラミング的に書くと以下のようになります。
Table = SortedMap<RowKey, Map<ColumnFamily, SortedMap<Column, SortedMap<Timestamp, Value>>>>
物理データモデル
では、実際にどのような形でデータが保存されていくのかを見ていきましょう。
HBaseは列指向のストレージフォーマットを採用しています。具体的には、論理データモデルで説明したColumnFamilyごとにファイルを分けてディスクに保存されます。
さらに、データはRowKeyの範囲でファイルが分割されます。このRowKeyの範囲で分割された単位をRegionと呼びます。Regionが各HRegionServerに割り当てられ負荷が分散されます。HBaseのRegionはデータベースのシャーディングで使われるレンジパーティションと同じです。
以下、実際にディスクに保存されるデータのイメージを図にしたものになります。
図のように、RowKey,ColumnFamily,Column,Timestamp,Valueがセットで格納されています。
同じRowでも複数のColumnの値が存在する場合は、同じRowKeyのエントリーが複数存在しています。このとき、ColumnもRowKeyと同様に辞書順でソートされて格納されています。HBaseは値がNULLであるColumnを保存しません。
また、バージョンに関しては、RowKeyやColumnが同じでTimestampのみが違うエントリーとして管理されています。
ざっとデータモデルの概要について説明しましたが、このようにHBaseはRDBとは異なるデータモデルを持っています。このようなデータモデルの中で、アプリケーションによってどのようにスキーマ設計していくかは、次回以降で解説していきたいと思います。
