85

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

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

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

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

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

4

3 に答える 3

117

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

  • カサンドラはより良くスケーリングします。Cassandraは、クラスター内で400を超えるノードに拡張できることが知られています。FacebookがメッセージングをHBaseの上にデプロイしたとき、100ノードのHBaseサブクラスター間でメッセージングをシャーディングする必要がありました。
  • Cassandraは、数百、さらには数千のColumnFamiliesをサポートします。「HBaseは現在、2つまたは3つの列ファミリーを超えるものではうまく機能しません。」
  • 「特別な」ノードやプロセスを持たない完全分散システムとして、Cassandraはセットアップと操作が簡単で、トラブルシューティングが簡単で、より堅牢です。
  • Cassandraのマルチマスターレプリケーションのサポートは、地理的な冗長性、ローカルレイテンシなど、複数のデータセンターの明らかな能力を得るだけでなく、リアルタイムと分析のワークロードを別々のグループに分割し、それらの間でリアルタイムの双方向レプリケーションを実行できることを意味します。これらのワークロードを分割しないと、見事に競合します。
  • 各Cassandraノードは独自のローカルストレージを管理するため、Cassandraには大幅なパフォーマンス上の利点があり、大幅に縮小される可能性はほとんどありません。（たとえば、Cassandra commitlogを別のデバイスに配置して、読み取り要求からのランダムなI / Oによって妨げられることなく順次書き込みを実行できるようにするのが標準的な方法です。）
  • 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を追加します。

お役に立てば幸いです。

于 2011-08-30T04:48:05.997 に答える
91

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

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

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

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

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

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

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

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

  • HBaseには、より多くのユニットテストFWIWがあります。

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

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

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

于 2011-08-31T02:14:07.413 に答える
23

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

于 2011-08-30T17:13:20.520 に答える