第1回HBaseとCassandraの討論会のメモ

HBaseとCassandraの討論会　第1回（Togetter：第1回HBaseとCassandra討論会）に参加したので、そのメモです。
…例によって、聞き逃し・理解不足・誤解誤認はあるとは思いますが(汗)

---

最初にkimteaさんの2010-02-15の分散データベースのページを見ながら話を聞く。
第1世代…Google BigTable
第2世代…Amazon Dynamo
第3世代…Microsoft SQL Azure（→リレーショナルモデルに変更された。中で使われているAzure TableはKVS）
第4世代…Cassandra

KVSはオブジェクト指向で、業務システムを作るのが難しい。（◆●オブジェクト指向という理由で難しいの？）
GAE/JのSlim3はその難しい部分を隠蔽してくれる。（JDOは失敗した（広まらなかった）が、GoogleはJDOを推している。JPAは遅い）

Cassandraの特徴
・O(1) DHT…分散ハッシュテーブル
・Eventual Consistency…BASEに基づく結果整合性
・Consistencyが調整可能
・分散DBでは削除の仕組みが難しい→0.7β2からVersioned Clockが実装される（Vector Clockはつまずいた）（◆●そういえばそんなツイートを見た覚えが）

---

で、ここから四方山話討論へ。
実際にCassandra・HBaseを使っている人達の苦労話や解決策の会話は非常に興味深い。

・Cassandraのロードバランスは、コマンドを実行すると重くなり、リングから外れてしまう→コマンドは休日に実行すべしｗ
・大量にデータを入れるとリング内で連鎖してCPUが100％になってしまう→Memスレショルド（◆●RowWarningThresholdInMBのこと？）を1MBにすると軽減される（◆●ちょっと裏技っぽい？）
・Cassandra0.6.6から起動が軽くなった
・Cassandraはローリングアップデートが可能

・HBaseでデータが破損すると復旧は大変（HDFSが落ちてコミットログがおかしくなるようなケース）
・Lunixのfd（ファイルディスクリプター）を増やしておく
・5台以上ほしい→スモールスタートがやりにくい

・Cassandraはキー毎にデータが分散しているから、範囲検索はスケーリングしない
・HBaseは逆の発想で、キーはかたまっているからショートレンジスキャンが得意
・HBaseCassandraはキーが偏ると一部のノードだけに負荷がかかる
・HBaseはROW単位でデータを管理しているが、実際はHDFSのリージョンサーバーがデータを持つ。（1～2日くらい経つと）メジャーコンパクションにより配置が最適化されて速度が上がる
・データの移動中は数秒くらいアクセスできなくなる。こういうところが「可用性を犠牲にして一貫性を保つ」部分

・MongoDBはよく固まる。ファイルサイズが倍々になるので、コピーに時間がかかる為
・HBaseもディスクを大量に使う

・Cassandraでデータ（ファイル？）を別マシンに持っていくとキーが見えなくなる（データを読めない）→「このトークンはこのリング」「Ring上で、このTokenはこのノード」という情報をホスト名で管理している為→hostsファイルでホスト名を持てばIPアドレスを変更しても大丈夫
・データの位置情報は、Cassandraはハッシュ関数、HBaseは.META.テーブルで管理している

・CassandraでCQLというSQLっぽいものが開発されているらしい
・Clustrix（クラストリックス）…バックグラウンドがKVSで、SQLが使えるらしい（有償）
・VoltDBもSQLが使えると言っているが、色々制限がある

・Cassandraは構築は楽だが、故障時故障後の復旧作業が面倒（復旧方法が色々あるし、リバランスに時間がかかる）
・HBaseはデータは他のリージョンにあるので故障時のデータコピーはマスターによってすぐ行われるHDFS上にリージョン等の実ファイルを保存しており、故障時は“各スレーブノードが担当するリージョンの再割り当て”がマスターノードによってすぐ行われる（HBaseは構築は手間だが、故障時は楽）
（Oracleなら故障したらOracleの人が謝ってくれるが、CassandraやHBaseは自分達が謝るしかない＾＾；）
（◆●話を聞いていると、思っていたより故障が多い印象。ノード数が少ない為か？Google並にノード数が多ければ故障してもただ放っておけばいいのかもしれないが＾＾；）
・Cassandraでノードを追加すると、今までは「リングの最後尾に追加されていた」が、「データ量が多いところを分割する」ように変更される（ロードバランスをしなくても済むようになる）
・Cassandraのデータコピーは遅い：ストリーミングが帯域を喰う／HintedHandOffがヒープを喰う→GCが発生してOutOfMemoryになり、ノードが応答しなくて切り離され、別のマシンへデータコピーしようとする→という連鎖が発生して全体が固まる（ノード数が3台とか5台で発生する。ノードが多いと大丈夫かも？）
・Amazon EC2 スモールインスタンスだとメモリーが1.7GBしか無い。専用サーバーの推奨スペックなら、Cassandraは4GB以上、HBaseは8GB（Hadoopを使うなら+4GB）
・Cassandra+Hadoopは遅い。HBase+Hadoopはデータの局所性を認識してくれる（HBaseは物理的にデータファイルのある場所でMapReduceの処理が行われる。Cassandra0.6はデータファイルのある場所とは無関係なので、通信に時間がかかる）

・HBaseの構築には色々な設定が必要（Linuxのファイルディスクリプターを増やす、ZooKeeperを設定する、HDFSを構築する）
・Puppetもユーザーキーは扱いづらい。設定を書く（設定内の定義を共有する）のが大変。拡張ドキュメントも足りない
・Puppetと同様なツールで「シェフ」というのがあるらしい
（◆●Puppetは象本やNTTデータの報告書でも紹介されていて良さそうな印象だったが、やはり実際は面倒な面もあるんだなぁ）

・RDBMSと比べると、KVSはキーをスケールするように設計するのが重要→（キーによってはデータが一部のノードに偏るので）１ノードにデータが集中してしまうとRDBの方がスループットが良いかもしれない
・CassandraはMySQLよりメモリーを喰う（MySQLは500MBくらいでいい）
・RDBとNoSQLの連携に関しては、RDBからデータをコピーして処理し、RDBに戻すのがいいかも（クリティカルなデータをNoSQLだけで保持するのはまだ怖い）
（元となるデータは別（RDBやファイル）にあり、NoSQLにロードできる状況が向いていそう。あるいは更新が頻繁に行われるデータはNoSQLに向いていない）
・RDBでも、データのバックアップはとるよね？（Amazon EC2も定期的にスナップショットは取れる）
・HBaseのデータのレプリケーション（複製）：規模が大きければクリティカルなデータもいけるかも
・Adobeでは、HBaseからMySQLへリストアする仕組みを作った→Adobe の HBase 事例

・Cassandraでトランザクションってどうするの？→キューに入れて、1つのスレッドが書き続ける
・Cassandraではカウント処理が出来ないので、ZooKeeperでやってる（HBaseにはカウント機能はある（ただし遅い））

---

実際に使っている人の“感想”を聞けたのは貴重でした。
宣伝文句や想像している理想通りには動作しないってことですね、やはり＾＾；

討論会の次回のネタは未定とのことですが、聞きたいことを事前に募っておいて、答えられそう・面白そうなところから議論していくのもいいかも？