arcanum_jp’s blog

おっさんの日記

Cassandra

データ構造についてのメモ

 

Keyspace

 1つのアプリケーションで1つのKeyspaceを使う(と言うことを推奨しているみたい)RDBMSとよく対比した説明があったけど、DBにたとえられる。XXシステムDBみたいな。内部にはキーで識別できるその値(ColumnFamily)のリストが入っている

ColumnFamily

 RDBで言うところのテーブルにあたる。中にはキーで識別できるその値(Row)が入っている。

Row

 RDBで言うところの行。RDBでは行にはそのフィールドが入っているのだが、Cassandraの場合、SuperColumnかColumnが入っている。それらは、ColumnFamilyやRowと同じようにキーで識別できる値としてはいっている。SuperColumn、ColumnのいずれをRowに入れるのかは、設定ファイル(0.6系まではstorage-conf.xml、0.7系以上はcassandra.yaml)で設定するらしい。

SuperColumnとColumn

 Cassandraでのデータの最小単位がColumn。キーで識別できる値(バイトの配列で)が入っている。また、その値の登録日付や更新日付を表す?longのタイムスタンプも持つ。CassandraのDBとしてはこのタイムスタンプの時間を最新更新日付として、古いタイムスタンプでは更新ができない仕組みは持つ。でも更新時にそのタイムスタンプをしているするのはアプリケーション側の責務のため、「先勝ちの仕組みは用意してあげるけど、後はアプリケーションでよしなにやってね!」と言うことだろうか。

 ColumnをグルーピングするディレクトリみたいなのがSuperColumn。キーで識別できる値(Column)のリストが入っている。

図に表す

 よく、Cassandraは4次元か、5次元のデータ構造と言われるが、上の[Keyspace] ⇒ [ColumnFamily] ⇒ [Row] ⇒ [Column]と、キーでデータが4階層に追っていける場合のデータ構造の場合は4次元。[Keyspace] ⇒ [ColumnFamily] ⇒ [Row] ⇒ [SuperColumn] ⇒ [Column]と、キーでデータが5階層に追っていける場合のデータ構造は5次元と言う感じか。よくWebで見る図はこんな感じかな。



SuperColumnが無い場合。検索はキーでだが、よく見るRDBの構造によく似ている。



SuperColumnがある場合。RDBの1行を複数まとめるものがあるので、正直「どう使うんだろう」と感じる。


 でも僕はこんな感じに感じた。各階層の入れ物はキーにより識別できるけど、その値は、ポインタで、次の階層で定義される値へのポインターを持つって感じか?最下層のColumnまで行くと、実際のデータに会えるとかね。


一番上のレベルのKeyspaceから一番下のColumnまで、キーでたどっていける。



 実際Cassandraを使って設計する場合はどうなんだろう。ありきたりな考えとしてブログシステムを作るとして、一瞬、こんなのを想像してみた。

 Blogspace(DB)にはブログ本体のデータを格納するWeblog(テーブル)と、そのユーザーのプロファイルを格納するProfile(テーブル)があり、両者は中身のデータはUserのIDで検索できる。WeblogのUser毎のデータは日付で検索できるRow(行)に格納されており、日付で検索するとブログの内容本体が取得できる。それらは、各画面のフィールドの値や、オプショナルで指定される画像データなど、可変なデータを持つ。こんな感じだろうか。


 Webでの記事とかを元にしているけど、自分の理解力も足りないし、こんな事を話せる人が回りにいないので、これで正しいんだろうか・・・このデータ構造で実際にブログシステム(もどき)を作ってみればいいのかな?