オライリー Cassandraをいただきました！

Cassandra
	Eben Hewitt 大谷 晋平 オライリージャパン 2011-12-24 売り上げランキング : 7820 Amazonで詳しく見る by G-Tools

訳者の一人である小林さんから献本を頂いたので早速ざっと目を通してみました。
私自身、Cassandraは0.6辺りからずっと触っているのである程度は理解してはいるつもり。その上で読んだ感想です。

まず最初にRDBMSの説明と弱点。つまりCassandraを含むNoSQLが必要とされた背景の説明。次いでCassandraの説明がはいる。そこでブリューワのCAP定理の説明もはいる。CAP定理に関しては分かり易く説明されてると思う。

続いてCassandraの利用事例。NoSQLはDomain Specific Databaseなので用途や使い所を誤るともう目も当てられない。だからCassandraがどういう用途の為に作られ何に向いているのかはしっかり理解しておこうね。

続いてCassandraのインストールの話。まぁこれはまんますね。これに続いてCassandraのデータモデルの話。RDBMS一筋な仕事場から来た人が恐らく最初に躓く所だと思う。中々構造体を理解出来ない。まぁRDBMSのデータモデルが二次元で収まるのに対して、Cassandraのは3次元な構造だからね。イメージしづらいんだと思う。
ただCassandraのデータモデルはもう一方のNoSQLの雄、HBaseと酷似してるから覚えておいて損はないと思う。

Cassandraのアーキテクチャの話は結構重要だと思う。Cassandraを構成する各種技術やらアルゴリズムって最近流行の分散処理の基本的なモノが多いから、これらを理解しておく事はそういった方面の理解を深める事にもなると思う。仮にCassandra使わないけど分散処理するアプリを作るなら相当参考になると思う。
設定とデータの読み書きに関してかなり詳しく書いてあるのはヨサゲ。この辺り理解しておけばトラブった時にも対応が簡単になるしね。設定に関しては前章のアーキテクチャの話も結構絡んでくるね･･･。
あとここでCassandra最大の問題、レンジゴーストに言及してる。ただこれに関してはもうちっと説明欲しかったな。後対策。

監視やらメンテナンス、後パフォーマンスチューニング等運用に関する情報が多いのもいいね。実際RDBMSの運用と違ってDBが生きたまま、動いたままの状態でメンテやらなにやらやる事が多いから、監視と運用ノウハウは必須。パフォーマンスチューニングはCassandraが動き始めた後と、設計段階でのデータ設計でのチューニングがあるけどここでは基本前者のみかな。まぁデータスキーマの話の所でしっかり理解しておけば事前のチューンは充分出来ると思うけど。

Hadoop連携はまぁHadoop使える位だったら分かるしょ。CassandraよりHadoopの方が遙かに複雑だし･･･。

後は0.8～1.0で搭載された新機能の話。ここで一番大きいのはSQL見たいなQuery言語が使えるCQLかな。CQL使えばSQL脳な人でもかなり使いやすくなると思う。分散カウンタに着いての話もあるけどこっちの機能は･･･。

最後にNoSQL全般の俯瞰。最初の方でも言ったけどNoSQLはDomain Specific Databaseなのでそれぞれの用途と特性をしっかり理解して使わないと危険。そういう意味でここで他のNoSQLがどんなモンかをしっかり理解しておいた方がいいと思う。

まとめ
ネット上に散らばってるCassandraの情報は大体ここに収まってる感じ。だからこれからCassandraを使おうって人はこれ一冊あれば事足りるんじゃないかな。後Cassandraは使わんけど、分散システムには興味或るって人とか、或いは普通にｼｯステム開発してる人が読んでも結構勉強になると思うよ。

クラウドで実用に耐えるアプリはほぼ分散アーキテクチャなので、従来の構造のアプリしか作った事がない人はこれを読んで分散可能にするにはどうしたらいいかを学ぶといいと思う。

CassandraとHBaseを比較して入門するNoSQL

第10回Cassandra勉強会で発表したスライドに、勉強会後に頂いたフィードバックを反映した物をSlideshareにUPしますた

Cassandraとh baseの比較して入門するno sql

View more presentations from Yutuki r.

Cassandra0.6.4の問題

■発生時
急激な書込処理を行う。
恐らく性能不足の為に書込処理が間に合わず、大量のassandraのCommitLogが発生。
続いて何らかの理由によりCassandra Cluster停止。再度Cassandra Nodeの起動を試みた所でOOMEが発生。

■原因予測
Source Levelではまだ未確認だが、恐らく起動時にCommitLogを全てMemoryに乗せようとしている？
その為にOOMEが発生している可能性がある。

■対応策
取り敢えずCommitLogのフォルダの中身を別に退避させてから起動を試みると問題なく起動する。
この為、退避したCommitLogを少量ずつ本来のフォルダに起いて再起動を繰り返す事で徐々にCommitLogを適用しつつデータの復旧を行う。

■調査する事
・現在のCassandra Clusterでの許容書込速度
・起動時にCommitLogの一斉読込を回避する方法
・CommitLogをファイル単位で適用する方法

Cassandraは起動時が非常に弱い。何らかの予防策対応策を準備する必要がある。
https://issues.apache.org/jira/browse/CASSANDRA-1014

ルイーダの酒場で学ぶOracle、HBase、Cassandraの違い

ルイーダの店 = データベース
旅人 = データ
勇者 = クライアント(APサーバなど)

■ルイーダの酒場　Oracleバージョン
世界に一店舗だけある巨大な酒場。
世界中から旅人が集まり、転職歴や力、素早さ、運の良さ、レベル、倒してきた敵等、その旅人が持つあらゆる情報で探し出す事が出来る。
仲間を捜す時は、ほしい仲間の条件を店主に言えば、条件に見合う旅人を連れてきてくれる。基本的に店主はどんなに複雑で難しい条件でも健気に探し出してきてくれる。
がしかし、店主自らが探しに行く為、あまりに条件が複雑過ぎると探すのに時間がかかってしまうので、運悪く自分よりも前の勇者が店主に複雑な条件を提示してしまうと、窓口に長蛇の列が出来てしまい待たされる事もある。

■ルイーダの酒場　HBaseバージョン
とある街に本社を置き、世界中に支店を持つ酒場である。
旅人がここの酒場に登録する際にID作る必要がある。ほとんどの場合自分が探してもらいやすい様に力や素早さなど自分のステータスを羅列した登録番号を作る事が多い。
また旅人を捜す時は基本的にその旅人の登録番号を指定するか、登録番号の範囲を指定する事でしか探し出すことができない。自分がほしい旅人の条件に見合っているかは、一度呼び出してもらってから自分で確かめる必要がある。
各支店には所属すべき登録番号の範囲が決められている為、登録した旅人達は自分登録番号に従い、自分が待機しているべき支店に移動して待機する事になる。本社は常に各支店にいる旅人達の数を把握しており、各支店がほぼ同じ人数の旅人を抱える様に各支店の担当登録番号の範囲を調整し、各支店に伝えている。
自分が所属すべき支店が変わった旅人達、あるいは所属している支店が魔物に襲われて破壊されてしまった場合は、その足で新しい所属支店へと移動する必要がある。
その為に例えば新しい所属支店において、勇者がとある旅人を指名したとしてもその旅人が新しい支店にたどり着かない限り、その勇者は酒場で待ち続けなければならない。(可用性の犠牲)
旅人を捜す窓口は各お店に一つしかないが、お店がたくさんある上、登録番号毎に分かれている為、同時に何人もの勇者が、旅人を捜す事が出来る。

■ルイーダの酒場　Cassandraバージョン
世界中に支店を持つが、本社を持っていない。その為に書く支店間で常に連絡を取り情報共有を行っている。
こちらも旅人は登録する際に登録番号を生成し所属する支店を決める。が、それに加えて登録が終わると即座にその人のクローンを二人ほど作り上げ、本人とは別の店舗に配置しておく。更にこのクローンの作成を定期的に行い、新しいクローンが届いた支店では古いクローンと交換している。
とある旅人を探しに店を訪れた勇者がいたが、その旅人はこの支店ではなく、別の支店にいる事がわかった。が更に運悪くその探している旅人が所属している支店が魔物に破壊されている事がわかった。その様な時はすぐにクローンが所属している支店に移動し、そのクローンをつれてすぐに勇者は旅立つ事が出来る。
が、せっかくレベルアップしたのに複製を作る前に所属支店をなくしてしまった旅人を指名した勇者は、レベルアップ前の状態のクローンをつれて旅立たねばならなくなる。(一貫性の犠牲)
旅人を捜す窓口は各お店に一つしかないが、お店がたくさんあるので、同時に何人もの勇者が、旅人を捜す事が出来る。

Cassandraの不安点

■用語定義
*Data保持該当Node
書き込まれるデータのKeyのHash値を元に決定された、ReplicationFactorにて指定されたn個のNode という意味です。

shot6さんから回答をいただいたので追記

1.Data保持担当Nodeが自分以外の時、強度ANYで書込した際、書込要求転送先の決定方法は？

書き込み可能で生きているエンドポイントとそのノードから予測をたてる。ローカルアドレス、ラック、DCの近いほうから一致具合をみてきめる。場所でいうと、AbstractReplicationStrategy#getHintedEndpointsです。

2.Data保持担当Nodeが自分以外の時、強度ONEで書込した際、「全ての」保持担当Nodeに「同時に」要求を転送して一個から処理完了報告があったら応答を返す？

明らかにNOかと。投機的実行はしないです。

3.Data保持担当Nodeが自分以外の時、強度QUORAMで書込した際、「全ての」保持担当Nodeに「同時に」要求を転送して最小過半数から処理完了報告があったら応答を返す？

NOですね。StorageProxy#determineBlockForで書き込むノード数が最初に絞られています。というわけで全てのノードに同時に、とかはしないです。

4.強度ONEで読込した場合、Clientへの応答後に「必ず」ReadRepairが走る？

条件付でYESです。Read repairはONEの場合実行されます。ただし、OFFにすることも出来て、storage-conf.xmlのDoConsistencyChecksBooleanをfalseにするとOFFできます。

5.強度QUORAMで読込した場合、Data保持担当Node「全てに」Data要求をだし、最小過半数が返ってきた段階で、それらの値が一致しなかった場合、その中で「最も新しいTimestampを持つ値」を返し、その後に「必ず」ReadRepairが走る？

ミスマッチの場合最新の値を返すわけではなく、先にReadRepairしてもう一度読んで返してますね。1度ReadRepairしてもダメだとあきらめてDigestMismatchException返します。

6.Data保持担当Nodeが自分の時、強度ZEROで書込した際、どの様な処理が行われる？

まんま非同期でmutateします。返事もまたない感じ。StorageProxy#mutateです。

7.Data保持担当Nodeが自分の時、強度ANYで書込した際、どの様な処理が行われる？

Hintを書き込む意外はONEと同じ動きです。

TwitterがCassandraを使った理由と移行方法

相変わらずの意訳な上に要点のみの抜き出しです。
間違っていたらTwitterでもコメントでいいのでがんがん指摘してください。

===============
Twitterではデータ量、データ増加量が急加速している。
今まではMySQLとmemcashedで運用してきたが、特に運用要員の面で費用が莫大になってしまった。
その為により自動的でより高い分散容易性、より高い可用性を必要とした。

選択肢として上ったのが下記の二つ。

・MySQL Clusterの今以上の自動化
・KVS(HBase、Voldemort、MongoDB、MemcacheDB、Redis、Cassandra、HyperTable)への移行

次の検証を行う事で選択肢の絞り込みを行った

・新規Node追加の容易性
・SPoFの有無
・Scalingに伴いデータ書き込みもScalingするか
・管理作業はどれ程必要か
・OSSである場合、健全な運営団体を伴っているか
・準備、移行に必要な時間と労力はどれ程か
・それを取り扱う為に新たな技術を学ぶ必要があるか

等々

結果的にCassandraに絞られ、Cassandraの検証を開始した。
検証では特に書き込みに重点を置いた。
現在大量のmemcachedを利用しているが、中長期的にみてDBの前にCacheを置かずに運用出来るかも検証した。

結果、Cassandra採用の要因となったのは

・SPoFがない事
・書き込み能力がScalingする事
・Cassandraを支える母体が健全である事

今後Twitterの全てのシステムをCassandraに載せ替えるつもりだが完全移行までには時間がかかる。現段階では維持が最も重要で最も維持が困難なTweetとReTweetのテーブルをCassandraに移行している。これが追われた後は簡単だ。

この既存データの移行に関しては元々Twitter側にそれに適したシステムがあるのでそれを利用する。この機能を利用して漸進的に機能拡張を行っていく。

Twitterが今後行う移行作業は次の通り

1.CassandraとMySQLの両方にデータを書き込む。同時に各々の書き込みが即停止出来る様にしておく
2.徐々にCassandraへの書き込みを行う
3.バグの調査
4.Cassandraへの書き込みの停止
5.新規システムのバグ修正を行い、再度適用を行う
6.2へ戻る

上記作業が終了した次を行う

1.MYSQLのバックアップ
2.Cassandraへのデータインポート ※1
3.データのインポートが終わったら読込をCassandraから行う様にする
4.満足がいく性能がでれば徐々にCassandraからの読込に切り替え、MySQLの利用を停止していく。駄目ならMySQLに戻して再度調整を行う。

※1 BinaryMemtableを利用したが高速すぎてネットワークI/Oを食いつぶしてしまう為にやめて通常のThriftに戻した。この状態だと一週間かかる。もし無限のネットワーク帯域があれば7時間で終わるだろう。

上記手段を用いて移行を完遂する。

元ネタ
■Cassandra @ Twitter: An Interview with Ryan King

HBase vs Cassandraに関する河野氏からの意見

tatsuya6502

#Cassandra と #HBase の件ですが、Apacheのトップレベルプロジェクトなのか、サブプロジェクトなのかというのは、それぞれのプロジェクト自身が選択することなので、「Apache的にはこちらが優勢」といった考え方はないと思います
#Cassandra と #HBase は、それぞれ得意とする分野も異なりますので、両方に存在意義がありますし、開発メンバーも全く別なので、開発の優先順位をつける必要もないはずです

#HBase の場合は、 Hadoop の各コンポーネント（HDFS、ZooKeeper、Map Reduce）があって初めて成り立つ製品ですし、大規模なデータセットを意識していますので、 Hadoop のサブプロジェクトになっている現在の形が自然に思えます
#HBase は、元々の用途が、 Wikipedia の自然言語検索エンジンなので、HTMLとそれに関連するタグ情報といった「非定型のデータ」で、さらに、数十億レコード規模の「大規模なデータセット」といった条件で最高の性能を発揮します
また #HBase は「Map Reduce」との相性もいいですし、従来のDBのように「strong consistency」モデルを採用しています。さらに、オプションで、２次インデックスや楽観的ロック方式のトランザクションも使えたりと機能は豊富です

#Cassandra は、設計の出発点が、Amazonの「ショッピングカート周辺のデータセット」で「レスポンスの早さ」を実現するためのものだったのですが、さらに、 HBase が得意な「非定型のデータ」も扱えるよう拡張されています
#Cassandra は、基本は eventual consistency モデルで動作しますが、クエリーごとに「consistencyの強度が選べる」ので、 strong consistencyも使えます
一般的なウェブの用途だと、 #Cassandra がフィットするケースの方が多そうです。 #HBase は、大規模データセットで Map Reduce が使われるケースに最適なのではないでしょうか