こんにちは、下田です。先日オーストラリアのケアンズ、ブリスベン、シドニー、メルボルンに２週間ほど弾丸で行ってきました。旅行から帰ってきた後に教えてもらったこの記事（http://rocketnews24.com/2015/11/06/660596/）がまさにその通りだったので笑ってしまいました。しかし海外はいつも新しい発見があって面白いですね、もし機会があればぜひ海外旅行に行ってみてください。

はい、では、完全に出遅れ感がありますが、今回から Cassandra について、記事を書いていきたいと思います。 Cassandra とは、なにか、一言で言うとチョーでかい HashTable です。チョー頭のいい人ならこれで大体理解出来ると思います。しかし、我々パンピーはそんなうまい話があるわけないので、粛々と学びながら説明してきたいと思いますので、お手柔らかにお願い致します。

では、まず、昨今のデータベースの要件として、 Scalability, Reliability が重要視されています。まず、 Scalability ですが、もしサービスがヒットした場合、サーバーを足すだけで処理能力が向上する仕組みになっているかどうか、サービスの利用者が増えて大量データとなったときサーバーを足すだけで、ストレージが大きくなる仕組みになっているかどうかといったことを指します。次に、 Reliability ですが、サーバーが一台故障した場合、サービス停止が必要かどうかといったことを指します。従来、使用されてきた Relational Database では、こういった問題を苦手としています。もちろん、 Relational Database にもかなり強い分野はありますが、その分野（データの完全性）を追求するには、先の Scalability, Reliability を犠牲にしなければならないアーキテクチャとなっています。そこで、データの完全性をある程度犠牲にして Scalability, Reliability に特化したデータベースが Cassandra となっています。CAP Theorem で言うと、通常の Relational Database が、 Consistency と Availability を有しており、 Cassandra は、 Availability と Partition Tolerance を有しています。以下の図は、 Cassandra をシンプルにしたモデルとなっています。

Node と記載しているのが実際のサーバーです。この図の場合だと６台を一つの Cassandra クラスタとして表しています。 Node の隣に記載されている Token は、自分が管理する番号レンジです。 基本的には、 HashTable の構造がただ複数サーバーになっただけですね。 Cassandra では、Primary Key の一つ目のカラムを Partition Key と呼びますが、そのPartition Key を特定の Hash アルゴリズムで、数値化し、どの Node にデータを記録するか決めます。上記の図の例だと、 Hash アルゴリズムを利用して 1- 60 までの数字に変換し、記録するサーバー(Node) を特定し、そこに書き込みを依頼をするといった仕組みが基本的な流れです。こういった構成にすることで、例えば、 Node3 のサーバーがダウンしたとしても、サービスの影響があるのは、 Hash アルゴリズムで計算された値が、 21-30 までに制限されることに大きな意味があります。例えば、オーダーシステムだった場合、１台のサーバーがダウンした時に、オーダーが全く受けられないようなシステムと、オーダー番号の Hash が 21-30 になってしまうデータだけ受けられない場合だと明らかに後者のほうが損害が少なくなります。また、 Cassandra の Hash アルゴリズムでは、６台に極力均等になるようなアルゴリズムが採用されているため、 1/6 の確率でオーダーが受けられなくなるとも言えます。（１００％ではないですが）しかし、この副作用として、検索条件として、 Partition Key (Primary Key の一つ目のカラム) 指定しない検索が出来なくなります。何故かというと、 Cassandra が、どの Node を検索すればいいか分からないため、1000 Node ある場合は、 1000 Node 全てに聞きまわらなければならなくなるためです。よって、 RDB 同様にデータモデリングも重要になってきます。

上記の図は、もう一つの機能である Replication です。基本的に、 Reliability を上げるためには、他のノードが自分のデータを保持する必要があります。上記の例では、 Replication factor = 3 となっており、一つのデータを書き込む毎に、1 つの Node と、バックアップとして、 2 つの Node に書き込みをします。これにより、 3 つのうち 1 台が故障したとしても、サービス影響なしにデータの検索や更新が出来ます。さらに、別のデータセンターが存在する場合は、そのデータセンターにも 3 つの Node に対して書き込みを行うためある程度のレイテンシーはあっても、全世界でデータの同期が自動でなされます。

上記の図は、 Node を追加した例です。 Node を追加した場合は、 Ring(Token のレンジ) を自動で再計算してどんどんとレンジの幅を狭めていきます。今回の例だと Token のレンジは 60 となっているため、 Node の数は必然的に 60 が限界となりますが、実際のレンジは、2^127-1 までスケールします。自分の管理するレンジが狭くなればなるほど自分の責任範囲が狭くなるため、サーバーを追加するだけで、 Reliability が向上する仕組みとなっています。（6 台の場合は、 1/6 の確率で検索、更新が失敗しますが、 100 台の場合は、 1/100 の確率で失敗することになるため）
以上が基本的な Cassandra の仕組みです。次回は、 Consistency レベルについて話を進めていきたいと思います。

【関連記事】
Splunkに株価を取り込んでみた ft. Fujikawa
Introduction to Antlr!
Introduction to Antlr! Pt.2
JavaPoetで簡単コード生成！
Introduction to Antlr! Pt.3
モニタリングルーター Sensu
マイクロフレームワーク Spark
Introduction to Antlr! Pt.4
Introduction to Antlr! Pt.5