大規模なデータ処理HbaseとCassandra [クローズ]

大規模なデータストレージソリューションを研究した後、私はカサンドラに着陸するところです。しかし、一般的に、Hbaseは大規模なデータ処理と分析に適したソリューションであると言われています。

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

また、http：//ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/で両方の詳細を見つけました 。

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

Cassandraについては、ノードの追加とシームレスなレプリケーションが簡単で、障害点機能がないため、より確信が持てます。また、セカンダリインデックス機能も保持しているため、優れた利点です。

どちらがあなたに最適かを判断しようとすることは、あなたがそれを何に使用するかによって本当に異なります。それぞれに利点があり、詳細がなければ、宗教戦争になります。あなたが参照したその投稿も1年以上前のものであり、それ以来、両方とも多くの変更が加えられています。また、私は最近のカサンドラの開発に精通していないことを覚えておいてください。

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

• HBaseは、より大規模な本番環境（1000ノード）にありますが、Cassandraの約400ノードのインストールの球場にあるため、実際にはわずかな違いです。

• HBaseとCassandraはどちらも、クラスター/データセンター間のレプリケーションをサポートしています。HBaseはより多くのユーザーに公開されるため、より複雑に見えますが、柔軟性も向上すると思います。

• 強力な一貫性がアプリケーションに必要なものである場合は、HBaseの方が適している可能性があります。一貫性を保つようにゼロから設計されています。たとえば、アトミックカウンター（Cassandraがちょうどそれらを取得したと思います）のより簡単な実装と、チェックおよびプット操作を可能にします。

• FacebookがメッセンジャーのためにHBaseを採用した理由の1つであると私が理解していることから、書き込みパフォーマンスは素晴らしいです。

• Cassandraが注文したパーティショナーの現在の状態はわかりませんが、過去には手動でリバランスする必要がありました。必要に応じて、HBaseがそれを処理します。順序付けられたパーティショナーは、Hadoopスタイルの処理にとって重要です。

• CassandraとHBaseはどちらも複雑ですが、Cassandraはそれをより適切に隠します。コードベースを見ると、HBaseはストレージにHDFSを使用することで、より多くの情報を公開しています。Cassandraも同様に階層化されています。DynamoとBigtableの論文を比較すると、Cassandraの動作理論は実際にはもっと複雑であることがわかります。

• HBaseには、FWIWのユニットテストがさらにあります。

• Cassandra RPCはすべてThriftであり、HBaseにはThrift、REST、およびネイティブJavaがあります。ThriftとRESTは、クライアントAPI全体のサブセットのみを提供しますが、純粋な速度が必要な場合は、ネイティブJavaクライアントがあります。

• ピアツーピアとマスターツースレーブの両方に利点があります。マスター/スレーブのセットアップは、一般的にデバッグを容易にし、かなりの複雑さを軽減します。

• HBaseは従来のHDFSだけに関連付けられているのではなく、必要に応じて基盤となるストレージを変更できます。MapRは非常に面白く見え、私自身は使用していませんが、良いことを聞いています。

Cassandra開発者として、私は質問の反対側に答えるのが得意です。

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

私の知る限り、HBaseが現在持っている主な利点（HBase0.90.4およびCassandra0.8.4）は、Cassandraがまだ透過的なデータ圧縮をサポートしていないことです。（これは、10月初旬に予定されているCassandra 1.0に追加されましたが、今日ではHBaseにとって真の利点です。）HBaseは、Hadoopバッチ処理によって実行される範囲スキャンの種類に対しても最適化される可能性があります。

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

お役に立てば幸いです。

100ノードのhBaseクラスターを使用する理由は、HBaseがより大きなサイズにスケーリングしないためではありません。これは、サービス全体を停止することなく、hBase / HDFSソフトウェアのアップグレードをローリング方式で実行する方が簡単だからです。もう1つの理由は、単一のNameNodeがサービス全体のSPOFにならないようにするためです。また、HBaseは（FBメッセージだけでなく）さまざまなサービスに使用されており、100ノードのポッドアプローチに基づいて多数のHBaseクラスターをセットアップするためのクッキーカッターアプローチを使用するのが賢明です。100という数字はアドホックであり、100が最適かどうかには焦点を当てていません。