前回までの説明でCassandraのインストールと動かすところまでいきました。今回はCassandraのデータモデルを理解して、実際にデータにアクセスしてみましょう。

データはすべて4次元または5次元の連想配列

Cassandraのデータは非常にシンプルなデータモデルを持っています。データはすべて4次元または5次元の連想配列のようになっています。

4次元の場合は以下の形で値にアクセスします。

［キースペース］［カラムファミリ］［キー］［カラム］

そして5次元の場合は以下の形でデータを特定します。

［キースペース］［カラムファミリ］［キー］［スーパーカラム］［カラム］

Cassandraのデータモデルは以下の4つの概念で成り立っています。

カラム：

データの最小単位。実際のキーと値、そしてタイムスタンプを持つ。

スーパーカラム：

カラムの集合を扱う単位。

カラムファミリ：

カラムまたはスーパーカラムの集合を扱う単位。RDBMSでいうところのテーブル。

キースペース：

RDBMSでいうところのデータベース。一般に1アプリケーションで1つ使用する。

1つ1つ見ていきましょう。

カラム ─データ構造の最小単位

カラムとは、Cassandraで扱うデータ構造の最小単位です。どのデータも、カラムによって以下の項目を保持しています。

• name：カラムにアクセスするためのキー
• value：カラムの値
• timestamp：カラムの更新日時

これらの値はすべてアプリケーションから与えられるもので、Cassandra側では何も足したりはしません。これを図示すると、以下のようになります（カッコ内はデータ型⁠）⁠。

これがもっとも基本的なデータ構造になります。たとえばカラム「twitter」があるとして、その値が「shot6」の場合、以下のようになります。

スーパーカラム ─カラムの集合を扱う

スーパーカラムはカラムの集合を扱うデータ構造です。複数のカラムを束ねて、1つのキーでアクセスできるようになります。スーパーカラムのキーに対して、値が〈カラム名、カラム〉の、ソート済みのマップのようなデータ構造と思ってください。

スーパーカラムは以下の項目を保持しています。

key:

このスーパーカラムにアクセスするためのキーです。

value:

このスーパーカラムで保持するカラムの配列です。

スーパーカラムはタイムスタンプを持たないのが特徴です。使い方としては、以下のようになります。

• スーパーカラムのキーでカラムの集合を特定する
• 第2のキーとして、カラム名でカラムを特定する

データ構造を図示すると以下のようになります。

具体例で見てみましょう。

複数Webサービスのプロフィールを表現するスーパーカラム「profile」があるとします。各サービス名をSuperColumnのキーとする場合、たとえば以下のようになります。

この場合、「hatena」というキーを持つデータに注目してみましょう。「hatena」というスーパーカラムは、「id」「firstname」「lastname」「lastupdate」という4つのカラムが返ってきます。このようにスーパーカラムは複数のカラムを持つことができるのです。

では次に、「twitter」というキーを持つデータに注目してみてください。こちらは「userid」「name」「location」「web」というカラムを持ちます。 あれ？　おかしいですね。先ほどの「hatena」というキーが持つカラムの内容が明らかに違っています。

実はCassandraではカラムファミリごとに異なるカラムを持つことができます。カラムは実行時に追加できるので、設定ファイルで決め打ちにしておく必要がありません。カラムの変更でCassandraのサーバを再起動しなくても済むのです。

カラムファミリ ─カラムを保持する

カラムファミリはカラムを保持する器です。カラムの集合をロウと呼びますが、ロウにキーをつけて管理します。ロウには以下の2つの状態があります。

• カラムが入る場合
• スーパーカラムが入る場合

カラムとスーパーカラムを同一のカラムファミリに入れることはできません。必ずどちらかのケースになります。

各カラムファミリはロウごとにソートされており、アクセスの単位も基本的にはこのカラムファミリのロウが基準になりアトミックになります。そのためアトミックに処理する関連カラムはすべてカラムファミリに落とし込む必要があります。

カラムファミリはstorage-conf.xmlにて、たとえば「どういう名前でどういったカラム順序で保存しておくか」などを設定する必要があります[1]。

カラムファミリの変更を行った場合、現状のCassandraは再起動が必要になります[2]。

カラムファミリのデータ構造は、カラムを入れる場合と、スーパーカラムを入れる場合で若干異なってきます。カラムファミリにカラムを入れる場合、以下のようなデータ構造になります。

この場合、SuperColumnと同一のデータ構造になります。

一方、カラムファミリにスーパーカラムを格納する場合、データ構造は以下のようになります。

カラムの場合と違ってくるのは、内部に格納されるデータの位置です。

下記のように、ユーザIDごとに複数のWebサービスのプロファイルを管理するカラムファミリ「profile-group」があるとしましょう。

このような場合、共通のカラムファミリーのキーに対して、複数のスーパーカラムからなるロウが存在します。たとえば、「shot」というカラムファミリーのキーに対して、「twitter」と「hatena」というスーパーカラムのキーがあります。また、「twitter」というスーパーカラムのキーの中に複数のカラムが存在するという構造です。

このように、カラムファミリ内にスーパーカラムが入っているときは、通常のカラムファミリより一段構造が深くなります。そのため、カラムファミリ内で扱えるデータも構造ごとに集合で扱えるのが非常に便利です。

キースペース ─最上位のデータ構造

最も上位のデータ構造が、キースペースです。RDBMSで言うところのデータベースにあたるもので、カラムファミリーの集合を持ちます。

カラムに対しての操作を行う場合、第1次元は必ずキースペースになります。たとえば「Sample1」というキースペースで、今までのデータ構造とまとめるために全体を絵にしてみると、以下のようになります。

なんとなくイメージをつかんでいただけたでしょうか？

あらためて4つのデータモデルの特徴をまとめると、次の表のようになります。

感覚がつかめてきたでしょうか？　そうであれば幸いです。

CassandraのWikiページにも、データモデルについてくわしい説明が載っていますので、そちらもご覧になってください。

データモデルの和訳

URL：http://wiki.apache.org/cassandra/DataModel_JP

データモデルの本文

URL：URL：http://wiki.apache.org/cassandra/DataModel

長くなってしまいましたが、次回は設定とJavaコードからのアクセスの基本について見ていきます。