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

勉強 nosql

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

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

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


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


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