はじめに

2010年のはじめ，TwitterがApache CassandraというJavaで実装された分散型のデータストアシステムを採用しつつあるというニュースが話題を呼びました。このことでCassandraは，NoSQLと呼ばれるシステムの中で最も注目を集めるものの一つになったと言えるでしょう。

2010年7月の時点で，Twitterは，位置情報のデータストレージ，トップツイート（トップページに表示される人気ツイート一覧）などのリアルタイム分析，データマイニング処理など，多くの用途でCassandraを活用しています。また，Cassandraを生み出し，のちにApache Foundationに寄贈したFacebookでは，5億人規模・150Tバイト以上のデータ量を持つユーザメッセージの検索機能（Inbox Search）を，150ノードのCassandraクラスタで処理しています。

本稿では，まずNoSQLとCassandraについて，その全体像や位置づけを概観します。次にRuby on Rails（以下Rails）からCassandraを利用する方法について解説します。最後にCassandraクラスタ環境の構築と運用方法について説明します。

NoSQL小史

まず，NoSQLの簡単な歴史を紹介しましょう。

RDBMSの限界

RDBMSは長年にわたって広く使われ，特に大規模なシステム開発においては必ずと言ってよいほど採用されています。しかしWebが社会のITインフラとして機能する時代に入ると，SNS（Social Networking Service）やEC（電子商取引）など世界規模で運営されるWebサイトでは，データ量や同時アクセス数の増大からRDBMSではパフォーマンスの問題が生じるようになってきました。

サーバを増やすことでリニアに性能をスケールできるフロントエンドのWebサーバと違い，バックエンドを引き受けるRDBMSは負荷分散の手法に制約があり，ボトルネックになることが多くなってきたのです。

GoogleのBigtableとAmazonのDynamo

そのような状況の中，2006年にGoogleのBigtable，2007年にAmazonのDynamoと，2つの巨大Webサービス企業が，自社の開発した分散ストレージシステムについての技術論文を相次いで発表しました。両者は分散コンピューティング技術を基礎とし，データ量や処理の負荷を多数のサーバに分散できるスケールアウト可能なシステムという共通点を持っていました。

NoSQLという言葉の誕生

これらの論文は多くの人々に影響を与え，BigtableやDynamoの直接的なクローンや，アイデアを積極的に取り入れたシステムの開発プロジェクトが，数多く立ち上げられました。

そして2009年6月11日，サンフランシスコにおいて，それらを取り上げた「NOSQL meetup」というイベントが開催されました。これが「NOSQL」というキーワードを世界に広めたきっかけだと言われています。

NOSQLは「SQL/RDBMSの否定」というネガティブなイメージを持つため，のちに「Not only SQL = NoSQL」と再定義され，現在ではRDBMSと相補的な役割を持つシステムというニュアンスが強調されています。

NoSQLを理解する2つの軸

現在NoSQLとみなされる多くのシステムが存在します。それぞれ多様な特徴を持っており，どのように評価・分類すればよいのか難しいところです。そこで，NoSQLシステムの全体像の理解に役立つ2つの概念を紹介します。

CAP定理

エリック・ブリュワーが2000年に提唱した「CAP定理」（⁠The CAP Theorem）と呼ばれる概念があります（注1⁠）⁠。CAP定理は，ネットワーク上の分散システムは，次のC，A，Pの3つの要件のうち，同時に2つしか保証できない，というシステムデザイン上のトレードオフを論じたものです。

• Consistency（整合性）
• Availability（可用性）
• Partition Tolerance（ネットワーク分割耐性）

Cの整合性は，各クライアントが同時に同じデータを読み出すと必ず同じ値が返されることを意味します。Aの可用性は，サービスが恒常的に提供される（停止しない）ことを意味します。Pのネットワーク分割耐性は，分散システム内のネットワークが分断された場合もサービスを継続できることを意味します。

C，A，Pの3要件のうち同時に2つしか保証できないとは，整合性，可用性，ネットワーク分割耐性の3つを兼ね備えたシステムは構築できないことを意味します。たとえば整合性と可用性を重視したシステムは，ネットワーク分割耐性に弱点を持ってしまうというのがCAP定理の主張です。

では，C，A，Pの組み合わせCA/AP/CPは，それぞれどのような処理に向いているのでしょうか。参考までに筆者の考えを表1にまとめました。

注1）

「定理」という言葉は本来，理論体系の基礎として公に認められた証明済みの命題のことです。しかしCAP定理が「定理」と言えるかどうかは，まだ評価が定まっていません。

データモデル

NoSQLシステムがデータをどのようなモデルで取り扱うかは，大きく分類して表2の3つの方向性にまとめられます。表2には，筆者が考えるそれぞれのデータモデルに適した用途も掲載しました。

2つの軸と各NoSQLシステムの位置づけ

米国の起業家ネイザン・ハーストは，NoSQLの各種システムをCAP定理とデータモデルの2つの観点から調査し，2010年3月に自身のブログエントリでわかりやすく図解しました。その図を和訳したものを図1に掲載します。

Cassandraは，AP型（可用性とネットワーク分割耐性は備えるが，整合性は備えない）かつカラム指向なデータモデルのシステムと位置づけられています（注2⁠）⁠。表1と表2に挙げた適した処理・用途から，Cassandraは停止が許されない高いサービスレベルを要求される場面で，複雑なデータを管理するのに向いたシステムだと言えます。

注2）

後述しますが，実際は整合性について，この分類の枠に収まらない特徴的な機能を備えています。

結果整合性

AP型のNoSQLシステムでは，1つのクライアントから書き込まれた変更をすべてのクライアントから参照できるようになるまで，ある程度時間がかかる可能性があります。その間，データの整合性が守られていないことを，システムの要件として許容しているのです。このような弱い整合性のことを「結果整合性」（⁠Eventual Consistency）と呼び，NoSQLシステムにおいて中心的な概念の一つとされています。