Cassandraのはじめ方─手を動かしてNoSQLを体感しよう
第1回 NoSQL,そしてCassandraとは
はじめまして,大谷です。これから数回にわたってNoSQLミドルウェアであるCassandraの連載をさせていただくことになりました。どうぞよろしくお願いします。
NoSQLって何だろう?
最近KVS(Key Value Store)やドキュメント指向データベースなどのミドルウェアを総称した"NoSQL"という言葉がよく聞かれるようになりました。国外ではTwitterやFacebookといったWebサービス企業を発端としてNoSQLミドルウェアの模索がはじまっています。国内においてもkumofsやROMAといったミドルウェアが開発され,にわかに活気づいています。
NoSQLとは何でしょうか?
語感だけを聞くと「"No SQL"だから,RDBMSを捨ててKVSなどに置き換える」という意味に取られがちですが,そうではありません。「RDBMSが得意な分野にはRDBMSを使って,RDBMSが不得意な分野にはその分野にあった適切なミドルウェアを使いましょう」という考え方のことです。Not only SQL(SQLだけではない),NoSQLはそのように捉えるのが適切です。
個々のNoSQLミドルウェアおよびRDBMSでそれぞれ進化しているので現実はもっと複雑ですが,NoSQLミドルウェアはRDBMSと比較すると以下のような傾向があります。
| NoSQL | RDBMS | |
|---|---|---|
| 何を重要視しているか | スケールアウトすること,高い可用性 | 一貫性 |
| どのようにパフォーマンスを出すか | コモディティサーバを並べてスケールアウト | スケールアップまたはデータを水平分割 |
| 問い合わせ | シンプルなキーでの問い合わせ | SQLによる問い合わせ |
| 一貫性の維持 | 緩い | 強い |
| データモデル | 列指向モデル,純粋なキーと値などさまざま | 関係モデル |
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが,それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので,ぜひそちらを参照してみてください。
- 高速に動作する
- リレーションモデルではないデータモデル
- スケールアウト型アーキテクチャ
- コモディティサーバによって構築される
- スキーマフリー
- SPOF(単一故障点)を持たない
- 自動的に複数台へレプリケーションする
- イベンチュアルコンシステンシまたは一貫性の選択が可能
- SQLのような強力なクエリ言語を持たず,シンプルな問い合わせしかできない
Cassandraとは何か
NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが,オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが,Apache Cassandra(カサンドラ)です。
Cassandraは,もともとFacebookが作成したものです。その後Apacheファウンデーションに寄贈され,2010年2月に晴れてApacheトッププロジェクトに昇格しました。
Cassandraは,Google BigtableのデータモデルとAmazon Dynamoのレプリケーションなどの分散システムデザインを融合させてできた分散データベースです。すべてJavaで実装されており,ASL2(Apache Software Licenseバージョン2)で提供されています。
Cassandraプロジェクトでは,以下のような点からCassandraを“Dynamo 2.0”と位置づけています(※1)。
- すでに実績のあるDynamoと同様の手法で一貫性を保障する
- ワンホップでデータに到達するルーティング方式を採用している
- BigTableのデータモデルを元にデータモデルを構築できる
- 異なるデータセンター間でもレプリケーション可能
- ラックアウェア,DC(データセンター)アウェアな書き込みが可能
- Dynamoよりも高速な書き込み方式を採用している
Cassandraの具体的な特徴として,以下の9つが挙げられます。
- ① 実用途向き
- ② 耐障害性の高さ
- ③ SPOF(単一故障点)がないアーキテクチャ
- ④ 一貫性制御の自由度
- ⑤ リッチなデータモデル
- ⑥ リニアにスループットを向上可能
- ⑦ 高い可用性
- ⑧ さまざまな言語をクライアントコードとしてサポート
- ⑨ JMX(※2)によるサーバ内部の状態の把握のしやすさ/監視のしやすさ
この中で特に魅力的なのは③の「SPOFをもたないアーキテクチャ」,⑤の「リッチなデータモデル」,そして⑧の「さまざまな言語をクライアントコードとしてサポート」の3点です。
まず1点目,SPOFがないのは,Cassandraのアーキテクチャがマスターノードを持たないためです。そのため部分的な故障で全体が停止することはなく,サービスを続行することができるので耐障害性が高いといえます。
Cassandraではデータが各ノードに複製・分散されるようになっていて,データ損失にも対策が施されています。加えて,⑨で挙げたようにJMXでどれくらいデータの書き込み/読み込みがあったかなど,サーバ内部の状態を細かく把握・監視できます。さらに,マシン(ノード)を追加すれば比較的リニアな性能の向上が期待できます。
このような側面をふまえて,TwitterやDiggなどの企業はRDBMSで垂直分割+Memcachedを運用するよりもCassandraのほうが運用コストが下がることがわかり,実践投入したようです。
2点目のデータモデルですが,CassandraはBigtableのデータモデルのようなリッチなデータモデルを持っています。RDBMSのリレーショナルモデルとは違いはあるのですが,頭の中にイメージがわくようになるとわかりやすく,かつ使いやすいのが特徴です。具体的なメリットについては本連載で追って説明します。
3点目に挙げた多様な言語をサポートしているのは,Thriftというフレームワークでデータを取得しているためです。Thriftは異なる言語間でも通信ができる仕組みを持っているので,Cassandraクライアントはいろいろな言語に対応できるのです。
ThriftはIDL(インタフェース定義言語)を記述すれば,通信部分のコードを自動生成してくれます。CassandraではすでにThfiftのIDL(.thriftファイル)が定義されているので,たとえば以下のような言語でCassandraクライアントを動かすことが可能です。
- C++
- Java
- Python
- PHP
- Ruby
- Erlang
- Perl
- Haskell
- C#
- Objective-C
- Smalltalk
- OCaml
また,Thriftから自動生成されたクライアントコードをベースに,より便利になるような機能を足したクライアントが多数開発されています。ざっと見ただけでも以下の言語に対応したクライアントが提供されています(※3)。
- Java
- Python
- Ruby
- PHP
- Perl
- C++
- C#
- Scala
- Clojure
本連載の後半の回のどこかで,リッチなクライアントの代表例としてHectorを触ってみる予定です。
- ※1)
- URL:http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf を参照
- ※2)
- JME:Java Management Extension。アプリケーションやJVMの状態を監視・管理するためのJava標準API。
- ※3)
- 詳細はCassandra Wikiの「ClientOptions」に詳しく書いてあります。
URL:http://wiki.apache.org/cassandra/ClientOptions/
まとめ
今回はNoSQLにおける現在の概観をざっくりとご説明した上で,Cassandraについても説明しました。次回は具体的にCassandraのインストールと設定を行って,コマンドラインから動かしてみましょう。

