Cassandraは、MongoDBなどと同じNoSQLデータベースの一種です。

 一口にNoSQLデータベースといっても様々な種類がありますが、ドキュメント指向データベースといわれるMongoDBとは違い、Cassandraはキー・バリュー型のNoSQLデータベースです。

 そのため、MongoDBに比べて検索などは弱いのですが、その分、速度などで勝っています。

 Cassandraは世界最大のSNSであるFacebookが自社で使っていたデータベースを2008年にオープンソースとして公開したものです。Apacheインキュベータプロジェクトの一つになりました。

 公開後ソーシャルブックマークのDiggやマイクロブログのTwitterなど、非常にアクセス数、データ量が多いサービスで採用されています。2010年2月には、Apacheのトップレベルプロジェクトに昇格し、現在注目度が非常に伸びています。

表1●Cassandraの7つの特徴
表1●Cassandraの7つの特徴
[画像のクリックで拡大表示]

 Cassandraのサイトでは、表1の7つが特徴として挙げられています。これらは多くのNoSQLデータベースでうたわれているものとよく似ています。この中でCassandraが特に優れているのは、Proven(証明)です。FacebookやTwitterといった世界最大規模のトラフィックをさばいている実績は、NoSQLを検討する上で大きな判断材料になります。これらの企業は、Cassandraを導入した理由の一つとして、Elastic(伸縮自在)を挙げています。サーバーの負荷が増えたときにサーバーの台数を増やすことで、処理能力や容量が線形に伸ばすことができるということです。この点は、MySQLなどの既存のデータベース・サーバーが苦手とするところでもあります。

 100テラバイト以上という非常に大きなデータも過不足なく扱えることから、数テラのログをCassandraに格納して分析するという使い方をしている企業もあります。

4~5次元の連想配列が可能

 Cassandraも本誌でこれまでに何度も見てきたkey-valueストアの一つです。memcachedなど従来の多くのkeyvalueストアは、一つのkeyに対して一つの値を保持します。これに対してCassandraは、key部分を4次元、もしくは5次元にすることができます。

 例えば通常の(key,value)が、

(110、Masui)
のような形になるのに対して、Cassandraの(key,value)では、
((blog,user,id,name),Masui)
のようにできます。これにより、SQLデータベースで、「blog」というデータベースの「user」というテーブルに格納されている「masuidrive」というIDのユーザー名(name)を取り出す際に、
use blog;
SELECT name FROM user WHERE id='masuidrive’
のように記述しなければならなかったものが、
cassandra['blog']['user']['masuidrive']['name']
という記述だけで済むようになります。

図1●CassandraとRDBの用語の違い
図1●CassandraとRDBの用語の違い
[画像のクリックで拡大表示]

 このkeyの次元には、名前が付いています(図1)。5次元の場合には、3と4の間にスーパーカラムという次元が追加されます。

 従来のkey-valueストアでも、keyの部分に配列を格納することは可能です。例えば、[masuidrive][name]という配列構造のkeyに「Masui」という文字列を格納し、[masuidrive][email]というkeyに「masui@xxxx.co.jp」のように格納できます。

 しかし、[masuidrive]だけを指定して、「Masui」と「masui@xxxx.co.jp」の両方を取り出すことはできません。そういったAPIが無いからです。CassandraではAPIとして配列をサポートしているので、[masuidrive]だけを指定して「Masui」と「masui@xxxx.co.jp」の両方を取り出すことが可能になっています。データベースのようにデータを扱えるわけです。

 この辺は、Google App EngineのDataStoreにおけるListPropertyと同じです。これ以外にも全体的な操作感として、CassandraはDataStoreに似ているところが多くあります。