Cassandra v0.6-siryou

2010/04/27 Copyright © Infoscience Corporation. All rights reserved. - 1 -

Cassandra

2010/04/27 インフォサイエンス永江

http://oss.infoscience.co.jp/

http://www.infoscience.co.jp/



・オープンソースの分散データベース・もともとは Facebookにおいて大規模データの格納のために開発された・構造化された Key-Value型データストア

Cassandraについて





key-valueストア

key-valueストア





・キーと値の組を書き込み、キーを指定することで値を読み出せるデータベース管理ソフトウェア

書き込み (put) 要求読み出し (get) 要求

削除 (remove) 要求

返答 (成否など )値

キー値

サーバ

クライアント

HDDや SSD, メモリ上(単純な )API

key-valueストアとは





Websphere eXtreme Scale

Voldemort (LinkedIn社発のOSS)

Velocity

Memcached (OSS)

Kai (OSS)

Dynamo

Oracle Coherence

Tokyo Cabinet/Tokyo Tyrant

ROMA

Kumofs (2010年 1月に OSSとして公開 )

Flare

プロダクト名

各種 key-valueストアプロダクト





・高い性能　　 1秒あたりにさばける読み書き要求の数 (qps)は RDBとくらべて文字通りケタ違いの　　性能。低遅延。ただしスループット (時間あたりのデータ量）は出ない。

・高いスケーラビリティ・高い可用性 (耐故障性も含む )

・シンプルな問い合わせ方法　問い合わせ方法をキー 1つの指定に限定することで、高速な検索のための表

　（例：ハッシュ表や B+木 )は 1つで済み、データ書き込み時に書き換えなければならない　箇所を少なく抑えています。問い合わせの解釈、実行も素早く済み性能を稼げます。

・細かい単位に限られた atomicな読み書き　キーと値の組、また、読み出しや書き込みといった細かい単位でだけ、 atomicな処理

　が可能です。 ⇔ RDBのトランザクションではデータ 1つと言わず、表の複数箇所や　複数の表にまとまった atomicな処理が可能ですが、コストが高いです。

・複製間の緩い整合性　複製間の整合性については緩い保証にとどめることで、性能と可用性を得ています。

key-valueストアの特徴





・ RDBとはケタ違いの高性能 (qps, 低遅延 )、または・数十台以上で達成できる大容量

　　が活きて、

・キーを指定するシンプルな問い合わせ方法・キー 1つを単位とする atomicな読み書き・複製間の緩めの整合性

　　を許容できるようなアプリケーションです。

キー値サーバ

クライアント

HDDや SSD, メモリ上

key-valueストアの使いどころ





・ Dynamo・ 1日あたり数千万の要求と 300 万以上のチェックアウト (2007年時点 )・複数キーにまたがった厳しい整合性は必要ありません。

key-value – ストアの使いどころ例 . amazonのショッピングカート





・数万 qps。 KVS ”としては Flare(フレア )”を使っています。・ユーザ IDをキーとした問い合わせさえできれば OK。複数キーにまたがった厳しい整合性も必要ありません。

key-value – ストアの使いどころ例 . GREEのアクセス履歴





・データ量が少ない場合・トラフィックの上限が見えているような場合・高価な HWを調達することでスケーラビリティや冗長性についての懸念をもつ必要がない場合

・上記のようなところでは RDBMSを利用すれば足りますし、管理その他の側面で楽です。

・複雑なクエリが必要なところでは、 KVSでは難しいです。

key-valueストアでなくてもいい、向いていないところ





Cassandra

Cassandra





・もともとは facebookにおいて大規模データの格納のために開発されました。

・ Amazon Dynamoの分散システムデザインと Bigtableのカラムファミリーに基づいたデータモデルをもちます。

・ Facebookにより 2008年にオープンソース化され、現在は Apacheのトップレベルプロジェクトとなっています。

Hadoopのロゴよりは数段かっこいいです。

Cassandraについて




2010/04/27 Copyright © Infoscience Corporation. All rights reserved. - 13 -「 facebook は、友達や同僚、同級生、仲間たちと交流を深めることができるソーシャルユーティリティサイトです。」 (facebookのトップページから抜粋 )

facebook (サンプルページ )





・ 2004年にハーバード大学の学生だったマーク・ザッカーバーグが創業。当初はハーバード大学の学生が交流を図るために作られた。その数日後、スタンフォード大学やコロンビア大学、イェール大学などの学生からの「同じようなサイトが欲しい」との要望に応え、いわゆるアイビー・リーグの学生にも開放した。その後、徐々に全米の学生に開放され学生生活に欠かせないツールとなった。大学のメールアドレス（ .eduドメイン）を所有する大学生のみに参加が限られていたが、 2006年初頭には全米の高校生に開放し、 2006年 9月までには一般に開放され、誰でも利用できるようになった。

・ 2007年 10月 31日、 Googleが OpenSocialAPIを公開。 Orkut、 Salesforce、 LinkedIn、 Ning、 Hi5、 Plaxo、 Friendster、 Viadeo、 Oracleらが参加。

・ 2008年 1月 25日、 FacebookAPI"JavaScript Client Library"を公開したことにより、 SNS業界にとどまらず、 IT業界全体に SNSのオープン化に拍車をかける。

・アプリケーションの総数は約 1万 7000。毎日、約 140のアプリケーションが追加されている。

(wikipediaの facebookについての説明から抜粋 )

facebookの歴史





・ピーク時には 1憶以上のユーザが世界中のデータセンタにある数万のサーバにアクセスする。・パフォーマンス、信頼性、効率の面から厳格な運用要件がある。・継続的な成長に追従できる高スケーラビリティなプラットフォームが必要だった。

facebookで Cassandraが開発された理由





Cassandraの特徴

Cassandraの特徴

Cassandraの特徴





” ”・カラムは名前 (name)、値 (value)、タイムスタンプ (timestamp)から構成されます。

timestamp: 123456789

value: “[email protected]”

name: “E ”メールアドレス

カラム (Column)





” ”・スーパーカラムは名前と、値としてのカラムから構成されます。

Timestamp: “123456789”

Value: “108-0023”

Name: “zip”

zip:


Value: “ ”東京都港区

Name: “city”


Value: “芝浦 2-4-1”

Name: “street”

city:

Street:

　value:

name: “homeaddress1”

それぞれカラムのキーとなります。

スーパーカラム (SuperColumn) (1)





・さきほどのスーパーカラムのタイムスタンプなどを省略して書いて以下のように表現することにします。

zip: 108-0023

city: 東京都港区

street: 芝浦 2-4-1

HomeAddress1:

スーパーカラム (SuperColumn) (2)





” ”・カラムファミリーはカラム、スーパーカラムから構成されます。 RDBの「行」に相当します。

Address1:

Ken:

zip: “93301

city: “BF”

street: “A ave”

zip: “94404”

city: “FC”

street: “Howard street”

zip: “90210

city: “BH”

street: “8th street”

Address2:

Address1:

　Dean:

HomeAddressBook カラムファミリー

・カラムは常にソートされています。⇒ 読み込み性能の向上・設定ファイルで前もってソートするカラム、ソートに使う型（ Byte, UTF8, ascii, long)を指定しておきます。・ Cassandraはこのように単純なキー /バリュー型のストレージよりも多少は構造化してデータを保持できます。

カラムファミリー (ColumnFamily)





・キーの値をハッシュ化した値をもとに接続するノードを決定します。 (ハッシュ値の範囲は 0～ 2127-1です。 )

この場合、キーをハッシュ化した値はノード Bの担当する範囲に含まれますので、 Bにアクセスします。

A

B

Cハッシュ (キー )

02127-1

データへのアクセス (1)





・ノード間のアクセス負荷に偏りがでてきたら、ノードを追加しバランスをとることができます。以下の例ではノード Cの負荷がノード A, Bよりも高くなってきたために、ノード Cの担当範囲にノード Dを追加してノード Cの負荷を減らしています。

A

B

C

B～ Dの区間はノード Dの担当範囲となります。

D

02127-1

データへのアクセス (2)





・ CAP定理：　共有データに関する以下の三つの特性のうち、　どんな時も ,このうちの二つだけしか同時には達成することができない。

　　 - データの整合性 (consistency)　　 - システムの可用性 (availability)　　 - ネットワークの分断 (network partition)

・結果整合性：　誰かがデータを更新し、そのデータが複製されるのに十分な時間が過ぎ、　その後更新が加えられていなかったら、必ず新しいデータにアクセスできる。

⇒ Cassandraでは整合性を妥協することでシステムは分断のある状況でも高可用性を実現できる。

参考：“ Eventually Consistent” 　 http://www.allthingsdistributed.com/2007/12/eventually_consistent.html

　　日本語訳 http://www.hyuki.com/yukiwiki/wiki.cgi?EventuallyConsistent)

結果整合性 (Eventual consistancy)

http://www.allthingsdistributed.com/2007/12/eventually_consistent.html

http://www.hyuki.com/yukiwiki/wiki.cgi?EventuallyConsistent





Cassandraの採用例







digg: 英語圏におけるソーシャルブックマークサイトの一つ。アカウントのないユーザーでもニュース記事をクリップできることに加え、アカウントを取得する

ことによって、その記事へのコメントや投票ができるようになる。 http://digg.com/

Case study: digg

http://digg.com/

http://digg.com/

http://digg.com/





・テラバイト級のデータ ; 高いトランザクション（読み込みがメイン）

・重度に shardingされた複数の DBクラスタ (sharding: MySQLサーバーを複数用意し、アプリケーション側でデータを格納するべきサーバーを選択させること )

・運用の難しさ (作業量大、かつ障害に弱い )

・不十分な可用性 (地理的な孤立 )

diggでの問題





Diggでは HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort, Dynomite 等を検討しました。

“それぞれのシステムが長所と短所を持っていますが、 Cassandraはこれらすべての良い点を取り込んでいます。列指向データストレージを提供してい

るので、単純なキー /バリュー型のストレージよりも多少は構造化してデータを保持できます。

また、可用性の高いピアツーピアで連携する分散環境でも動作します。未実装の重要な機能もありますが、私たちを目的地に近づけてくれるのは、他のソリューションではなく Cassandra なのです。 “

“Looking to the future with Cassandra” http://about.digg.com/blog/looking-future-cassandra

Diggが cassandraに移行した理由

http://about.digg.com/blog/looking-future-cassandra





Twitter:Twitter （ツイッター）は、 2006年 7月に Obvious社（現 Twitter社）が開始したサービス。個々のユーザーが「ツイート (「つぶやき」 )と呼称される短文を投稿し、ゆるいつながりが発生するコミュニケーション・サービスであり、広い意味での SNSの1つ。「ミニブログ」「マイクロブログ」といったカテゴリーに括られることもある。

Case study: twitter





MySQLを使用

・テラバイト級のデータ

・高トランザクション 100 万 ops/sec

・重度の sharding

・スキーマの変更がとても難しい

・人手による shardingはとても大変

・自動化された shardingとレプリケーションは難しい

twitterでの問題





“Kings氏によると、 TwitterはシェアドMySQLとMemchacheを組み合わせたシステムを利用してきたが、データの増加ペースが急増しており、対応が

急務となっていた。

人件費をはじめとした運用費用がかさんでおり、共有MySQL設定を自動化するか、他のデータベースへの乗り換えを考慮したという。

Cassandra以外のデータベースも検討したが、マシンの追加、 SPOF（単一障害点）、書き込みの拡張性、管理作業、コミュニティの健全さ（オープンソースの場合）などを考慮した結果、すべての条件を満たしたのがCassandra だったという。 “

“Twitter、「拡張性と可用性」を求めてMySQLから Cassandra へ乗り換える” sourceforge.jp http://sourceforge.jp/magazine/10/03/02/0350225

twitterが cassandraに移行した理由

http://sourceforge.jp/magazine/10/03/02/0350225





・テラバイト級のデータ

・高いトランザクション

・複数のデータセンター

・重度の sharding

・ DB のスキーマは簡単 (DBの機能はフルに使っていない。複雑なクエリはない )

・運用に必要なコストに悩んでいた

・サービスが止まるのは困る

・ピーク時に応答が遅くなるのも困る

facebook, digg, twitterに共通していること





twissandra

・ cassandra上に twitterに近い機能を実装

http://twissandra.com/

デモ








Cassandraは高いスケーラビリティを持つ、結果整合性を用いた分散KVS(Key Value Store)です。

Cassandraは Amazon Dynamoの特性と Google BigTableのデータモデルをあわせもった分散システムです。 Cassandraは、 Dynamoのように結果整合性で、 BigTableのように既存の KVSよりもリッチな ColumnFamilyベースのデータモデルを提供します。

Cassandraは 2008年に Facebookがオープンソース化しました。そのデザインは Avinash Lakshman (Amazon‘s Dynamoの作者の一人 )と Prashant Malik ( Facebookエンジニア )によって行われました。 Cassandraは DynamoとBigTable の融合によって生まれたものであり、 Dynamo 2.0と位置づけることもできます。 Cassandraは Facebookによって実サービスによって使われており、依然進化の途中です。

Cassandra wiki http://wiki.apache.org/cassandra/FrontPage_JP より

まとめ

http://wiki.apache.org/cassandra/FrontPage_JP





・大量のアクセスがあったときに従来の DBMSではすぐに応答が遅くなってしまうというのは日常の運用でも日々実感しています。（しかもそう感じる頻度が多くなってきています。）

・テーブルの分割というのも一つの手ではありますが、障害時の対応、バックアップ、リストアなどの運用が大変になってしまいます。

・上記のような問題を乗り越える手段として、 Cassandraはよく考えられていると感じました。

・過去は高嶺の花であった RDBが現在は一般的に使われているように、将来的には cassandraのような技術も一般的になって、普通のシステムで分散 DBが使われるようになるかもしれません。

・複数のお客様が並列に使える共用の分散 DBというのも面白いかもしれません。(認証、暗号化のシステムはよく検討される必要がありますが。 )

感想





● Query

get(): カラムもしくはスーパーカラムを取得する。

get_slice(): カラムのグループを取得する。

multiget_slice():

get_count(): カラムの数

等々

http://wiki.apache.org/cassandra/API

Cassandraの API (1)





● Updating

insert(): カラムを追加 /更新する。

batch_insert(): 複数のカラムを追加 /更新する。

remove(): カラムを削除する。

batch_mutate():

http://wiki.apache.org/cassandra/API

Cassandraの API (2)




Technology

Cassandra v0.6-siryou