大規模データ処理Hbase vs Cassandra

Question

大規模なデータストレージソリューションに関する調査の後、私はCassandra=に着陸しそうになりました。

両方とも同じキー/値ストレージであり、両方とも実行可能です（最近Cassandra）Hadoopレイヤーは、大きなデータの処理/分析が必要な場合にHadoopをより良い候補にします。

http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ でも両方についての詳細を見つけました

しかし、私はまだHbaseの具体的な利点を探しています。

Cassandra=ノードの追加とシームレスなレプリケーションのシンプルさ、障害点のない機能、そしてセカンダリインデックス機能を保持しているので、プラスになります。

cftarnas · Accepted Answer

どちらがあなたに最適かを決定しようとすることは、あなたがそれを何に使用するかに本当に依存します。それぞれに利点があり、詳細がなければ宗教戦争になります。参照した投稿も1年以上前のものであり、それ以来、両方とも多くの変更が行われています。また、最近のCassandraの開発についてはよく知らないことにも留意してください。

そうは言っても、HBaseコミッターのAndrew Purtellの言葉を変えて、私自身の経験をいくつか追加します。

HBaseは大規模な本番環境（1000ノード）にありますが、それはまだCassandraの〜400ノードのインストールのボールパークにあるため、実際にはわずかな違いです。
HBaseとCassandraは両方とも、クラスター/データセンター間のレプリケーションをサポートします。 HBaseの方がユーザーにより多く公開されるので、より複雑に見えますが、柔軟性も増すと思います。
強い一貫性がアプリケーションに必要なものである場合、HBaseの方が適しています。一貫性を保つためにゼロから設計されています。たとえば、Check and Put操作だけでなく、アトミックカウンター（Cassandraが取得したと思う）のより単純な実装を可能にします。
FacebookがメッセンジャーのためにHBaseを使用した理由の1つであったことから、書き込みパフォーマンスは素晴らしいです。
Cassandraの順序付けられたパーティショナーの現在の状態はわかりませんが、過去には手動でのリバランスが必要でした。 HBaseは、必要に応じてそれを処理します。順序付けられたパーティショナーは、Hadoopスタイルの処理にとって重要です。
CassandraとHBaseは両方とも複雑で、Cassandraはそれをより良く隠します。コードベースCassandraが階層化されているのと同じように見ると、HBaseはストレージにHDFSを使用することでさらに公開します。 DynamoとBigtableの論文を比較すると、Cassandraの動作理論は実際にはより複雑であることがわかります。
HBaseには、より多くの単体テストFWIWがあります。
すべてのCassandra RPCはThriftであり、HBaseにはThrift、RESTおよびネイティブJavaがあります。 ThriftとRESTはクライアントAPI全体のサブセットのみを提供しますが、純粋な速度が必要な場合は、ネイティブJavaクライアントがあります。
ピアツーピアとマスターツースレーブの両方に利点があります。通常、マスター-スレーブのセットアップにより、デバッグが容易になり、かなり複雑さが軽減されます。
HBaseは従来のHDFSだけに結び付けられているのではなく、ニーズに応じて基礎となるストレージを変更できます。 MapR とても面白そうで、自分では使っていませんが、良いことを聞いています。

jbellis · Answer

Cassandra開発者として、質問の反対側に答えるのが上手です。

Cassandraのスケーラビリティが向上しました。 Cassandraは、クラスター内の400以上のノード ;にスケーリングすることが知られています。 FacebookがHBaseの上にメッセージングを展開したとき、彼らはそれを 100-node HBase sub-clusters で分割する必要がありました。
Cassandraは数百、数千のColumnFamiliesをサポートしています。 " HBaseは現在、2つまたは3つの列ファミリを超えるものではうまく機能しません。"
「特別な」ノードまたはプロセスのない完全分散システムとして、Cassandraはセットアップと操作が簡単で、トラブルシューティングが容易で、より堅牢です。
Cassandraのマルチマスターレプリケーションのサポートにより、地理的冗長性、ローカルレイテンシーなど、複数のデータセンターの明らかな能力が得られるだけでなく、リアルタイムおよび分析ワークロードをリアルタイム、双方向それらの間の複製。これらのワークロードを分割しないと、それらは見事に競合します。
各Cassandraノードは独自のローカルストレージを管理するため、Cassandraにはパフォーマンスが大幅に向上する可能性があります。（たとえば、Cassandra commitlogを別のデバイスに配置して、読み取り要求からのランダムI/Oによって妨げられずに順次書き込みを実行できるようにする標準的な方法です。）
Cassandraでは、操作ごとに一貫性を要求する強度を選択できます。「カサンドラは強い一貫性を与えない」と誤解されることがありますが、それは間違っています。
Cassandraは、RandomPartitionerと、よりBigtableに近いOrderedPartitionerを提供します。 RandomPartitionerは、ホットスポットになりにくいです。
Cassandraは、memcachedに匹敵するパフォーマンスを備えたオンまたはオフヒープキャッシングを提供しますが、キャッシュの一貫性の問題や追加の可動部品を必要とする複雑さはありません。
非Javaクライアントは二流市民ではありません

私の知る限り、HBaseの現在の主な利点（HBase 0.90.4およびCassandra 0.8.4）は、Cassandraが透過的なデータ圧縮をまだサポートしていないことです。（これは Cassandra 1.0に追加されました、10月初旬に予定されていましたが、今日はHBaseにとって真の利点です。）HBaseは、 Hadoopバッチ処理。

また、必ずしも良くも悪くも、単に異なるとは限らないものもあります。 HBaseは、各列が暗黙的にバージョン管理されるBigtableデータモデルにより厳密に準拠しています。 Cassandraはバージョニングを削除し、代わりにSuperColumnsを追加します。

お役に立てば幸いです！

dhruba · Answer

100ノードのhBaseクラスターを使用する理由は、HBaseが大きなサイズに拡大縮小しないためではありません。これは、サービス全体をダウンさせることなく、ローリング方式でhBase/HDFSソフトウェアのアップグレードを行う方が簡単だからです。別の理由は、単一のNameNodeがサービス全体のSPOFになるのを防ぐためです。また、HBaseは（FBメッセージだけでなく）さまざまなサービスに使用されており、100ノードポッドアプローチに基づいて多数のHBaseクラスターをセットアップするためのcookie-cutterアプローチが賢明です。 100という数値はアドホックであり、100が最適であるかどうかに焦点を合わせていません。