読者です 読者をやめる 読者になる 読者になる

cassandra勉強会第五回@ぐるなび に行ってきた

勉強 nosql

ちょっと遅くなってしまったけれど、「ブログを書くまでが勉強会です」ということなので、書いてみた。
スライドは↓にあり。
http://www.intheforest.jp/blog/2010/05/cassandra.html
概ねこのスライドにのっているんですが、、その他、メモったことを箇条書き。

    • Cassandraへのwrite時、timestampが一緒に記録されるが、これはクライアントから渡すタイムスタンプになるので要注意。(後から書き込んでも時計が遅れていると、最新データにならない可能性がある。)NTP前提。逆に意図的に未来日付で何かを入れて、、みたいなことも考えられる。
    • ConsistencyLevelが"zero"の書き込みで、クライアントの接続先がデータを保持するノードとは違うとき、hint付きのコミットログを書き込んで、send messageをした時点で応答を返す。
    • ConsistencyLevelが"any"の書き込みだとどれか1台。"quarrum"だと複製数の3分の2以上から応答があってから応答を返す。
    • CassandraのAPIでの書き込みで保証できるのは、OSに書き込み依頼をするところまでで、実際にはOSがバッファに溜め込んだだけかもしれないので、ConsistencyLevelを上げても、Oracleのfsync?ばりの耐障害性は望めない。(Oracle知らないので、コマンド名は違うかも。)
    • ノードが落ちた時、自動的にリングからそのノードを抜いて"rebalance"(=データの再配備)をすることは無い。一見、そうしてくれたほうが便利そうだが、実際の運用ではノードの障害は一時的なもので、ほとんどが後から復旧されるので、その度に"rebalance"が走るのは逆に不便な時がある。Facebookの論文にその辺りの話が出ているそう。(ちなみに、ROMAは自動で"rebalance"的なことをするそうです。)
    • ↑でノードを分離する必要がある時は、明示的にコマンドを叩く。"decommission","removetoken"というのがあるそうで、この2つの違いはあやふな感じだったので、要調査。http://wiki.apache.org/cassandra/Operations
    • リードリペアはバックグラウンドで常時動いている(はず)。

もう1個、cassandra × hadoop という凄く興味深いネタの発表もあったのですが、
2人の発表者の方のうちの1人の方が急遽参加できなくなり、
次回に完結ということになりそうなので、その時にまとめようかなと思います。


懇親会にも参加し、相当な刺激をいただきました。。
やっぱり、もっとソースを読まないとダメだな==


railuteさんをはじめ、今回の開催に尽力いただいた皆様ありがとうございました。
次回も都合つくといいな〜。ネタも探さないと!?