Post on 15-Jan-2015
description
Cassandra分散データベース
Eric Evanseevans@rackspace.com
@jericevans
FOSDEM2010年 2月 7日
（Japanese translation by あしたのオープンソース研究所 http://oss.infoscience.co.jp/）
Cassandraはトロイ戦争中のトロイの予言者。彼女の予言は必ず的中したが、人々はその予言を信じなかった。
非常にスケーラブルで、非集中化された（decentralized）、
構造化データストア（すなわち、データベース）。
アウトライン
..1 プロジェクトのこれまでの歩み
..2 解説
..3 ケーススタディ
..4 ロードマップ
• 7人の新しいコミッタが参加
• 多くのコントリビュータ• IRCには 100人以上が参加
• すでに多数の課題（バグ、機能など）を解決• 3つのメジャーリリース、2つのポイントリリース
• トップレベルプロジェクトに昇格？
アウトライン
..1 プロジェクトのこれまでの歩み
..2 解説
..3 ケーススタディ
..4 ロードマップ
Cassandraとは...
• O(1) DHT (分散ハッシュテーブル)
• 結果整合性 (Eventual consistency)
• 「整合性」と「遅延」のトレードオフを調整可能
その一方で...
• 値は構造化され、索引付けされている• カラム / カラムファミリ
• 述語によるスライス化 (クエリ)
カラムファミリ
スーパーカラム・ファミリ
クエリ
• get(): カラム名で取得
• multiget(): 一連のキーを対象にカラム名で取得• get slice(): カラム名または名前の範囲で取得
• カラムを返す• スーパーカラムを返す
• multiget slice(): 一連のキーを対象にカラムのサブセットを取得
• get count: カラムまたはサブカラムの数を取得
• get range slice(): 一定範囲のキーを対象にカラムのサブセットを取得
カラムコンパレータ
• TimeUUID
• LexicalUUID
• UTF8
• Long
• Bytes
• ...
更新
• insert(): カラムを追加/更新 (キーを指定)
• batch insert(): 複数のカラムを追加/更新 (キーを指定)
• remove(): カラムを削除
• batch mutate(): batch insert() に似ているが、削除も可能 (0.6での新機能で、batch insert()は廃止予定)
• キー範囲の削除（まもなく追加）
整合性 (Consistency)
CAP定理：整合性 (Consistency)、可用性 (Availability)、または分断への耐性 (Partition tolerance)のうち、いずれか 2つを選択する
• Zero
• One
• Quorum ((N / 2) + 1)
• All
クライアントAPI
• Thrift (12の異なる言語！)
• Ruby• http://github.com/fauna/cassandra/tree/master• http://github.com/NZKoz/cassandra object/tree/master
• Python• http://github.com/digg/lazyboy/tree/master• http://github.com/driftx/Telephus/tree/master (Twisted)
• Scala• http://github.com/viktorklang/Cassidy/tree/master• http://github.com/nodeta/scalandra/tree/master
MySQLとのパフォーマンス比較 (50GB)
• MySQL• 300ms 書き込み• 350ms 読み取り
• Cassandra• 0.12ms 書き込み• 15ms 読み取り
書き込み
書き込みについて...
• 読み取りなし• シークなし• シーケンシャルディスクアクセス• 1つのカラムファミリ内ではアトミック
• 高速• 任意のノード• 常に書き込み可能 (ヒントハンドオフ)
読み取り
読み取りについて...
• 任意のノード• リードリペア• 通常のキャッシュ方法を利用
アウトライン
..1 プロジェクトのこれまでの歩み
..2 解説
..3 ケーススタディ
..4 ロードマップ
ケース 1: Digg
Diggは、ユーザーが記事やリンクを投稿することで、インターネット上の任意の場所にあるコンテンツを紹介、共有できるソーシャルニュースサイト。投稿された記事やリンクに対して投票したり、コメントしたりできる。
Alexa.comランキング 98位。
Digg
問題点
• テラバイト級のデータ、高いトランザクション（読み込みがメイン）
• 重度にシャーディングされた複数のクラスタ• 管理が重荷（作業量が膨大で、エラーが起こりやすい）• 可用性の要件を満たせない（地理的な分離）
ソリューション
• 現在は「グリーンバッジ」で実際に利用• まもなく Cassandraをプライマリデータストアに
• データセンターとラックに対応したレプリケーション
ケース 2: Twitter
Twitterは、ユーザーがツイートと呼ばれる 140字以内のテキストを投稿したり読んだりすることができるソーシャルネットワーキングサービス。いわゆるマイクロブログサービスである。
Alexa.comランキング 12位。
MySQL
• テラバイト級のデータ、˜1,000,000 ops/s
• 必要なのは重度のシャーディングと軽いレプリケーション• スキーマの変更が（不可能ではないにせよ）非常に困難• 人手によるシャーディングは作業量が膨大• シャーディングとレプリケーションの自動化が困難
ケース 3: Facebook
Facebookは、ユーザーがプロフィールを作成したり、友人を追加したり、友人にメッセージを送信したりできるソーシャルネットワーキングサイト。ユーザーは、住んでいる場所や共通の興味などをテーマに作られたグループに参加できる。
Alexa.comランキング 2位。
Inbox Search
• 100TB
• 160ノード
• 1日 5億回の書き込み（2年前の数字？）
ケース 4: Mahalo
Mahalo.comは、ウェブディレクトリと知識交換のためのサイト。よく使われる検索語の多くを対象に、結果セットを手作業で追跡・構築している点が特徴。
（Mahaloはハワイ語で「ありがとう」の意味）
MySQL
• 部分的デプロイ、1,600万本のビデオ（さらに増加中）
• シングルボックスの制限をすぐに超えてしまう書き込み（と保管）
• 管理が大変（クラスタリングが面倒）• 可用性の面での懸念
アウトライン
..1 プロジェクトのこれまでの歩み
..2 解説
..3 ケーススタディ
..4 ロードマップ
0.6
• batch mutateコマンド
• 認証（基本）• 新しい整合性レベル、ANY
• ファットクライアント• メモリマップド I/Oリード（64ビット jvmではデフォルト）
• 書き込み整合性の向上（HH）
• ネットワークの最適化• 行キャッシング• 管理ツールの改善• キースペースごとのレプリケーションファクター
0.7
• より効率の高いコンパクション（メモリより大きな行サイズ）• カラムファミリの変更をさらに容易（ダイナミック？）に• SSTableのバージョニング
• SSTableの圧縮
• カラムファミリの切り捨てをサポート• 設定の取り扱いを改善• remove key range コマンド
• 管理ツールのいっそうの改善• ベクタークロックでサーバーサイドコンフリクトを解決
おわり