224

最近、 Cassandraに関する話題が多くあります。

Twitter、Digg、Facebook などはすべてそれを使用します。

次のような場合に意味があります。

  • カサンドラを使用し、
  • Cassandra を使用しない、および
  • Cassandra の代わりに RDMS を使用します。
4

18 に答える 18

182

特効薬のようなものはありません。すべてが特定の問題を解決するために構築されており、それぞれに長所と短所があります。どのような問題ステートメントを持ち、その問題に最適な解決策は何かは、あなた次第です。

あなたが尋ねたのと同じ順序で、あなたの質問に一つずつ答えようとします. Cassandra は NoSQL ファミリのデータベースに基づいているため、質問に答える前に NoSQL データベースを使用する理由を理解することが重要です。

NoSQL を使用する理由

RDBMS の場合、このカテゴリの MySQL、Oracle、MS SQL、PostgreSQL などのすべてのデータベースが、ACID 特性を重視したほぼ同じ種類のソリューションを提供するため、選択は非常に簡単です。NoSQL に関しては、NoSQL データベースごとに異なるソリューションが提供されており、アプリやシステムの要件に最適なソリューションを理解する必要があるため、決定が難しくなります。たとえば、MongoDB は、システムがスキーマのないドキュメント ストアを必要とするユース ケースに適しています。HBase は、検索エンジン、ログ データの分析、または巨大な 2 次元の結合のないテーブルのスキャンが必要な場所に適している可能性があります。Redis は、ツリー、キュー、リンクされたリストなどのさまざまなデータ構造のインメモリ検索を提供するように構築されており、リアルタイムのリーダーボード、pub-sub のようなシステムを作成するのに適しています。同様に、このカテゴリ (Cassandra を含む) には、さまざまな問題ステートメントに適合する他のデータベースがあります。それでは、元の質問に移り、1 つずつ答えていきましょう。

Cassandra を使用する場合

Cassandra は NoSQL ファミリの一部であるため、要件の 1 つに非常に重い書き込みシステムが必要であり、保存されたデータの上に非常に応答性の高いレポート システムが必要な場合の問題に対するソリューションを提供します。リクエストごとにログ データが保存される Web 分析のユース ケースを考えてみましょう。分析プラットフォームを構築して、1 時間あたり、ブラウザー別、IP 別にリアルタイムでヒット数をカウントする必要があります。このブログ投稿を参照して、Cassandra が適しているユース ケースについて詳しく理解してください。

Cassandra の代わりに RDMS を使用する場合

Cassandra は NoSQL データベースに基づいており、ACID およびリレーショナル データ プロパティを提供しません。ACID プロパティ (財務データなど) に対する強い要件がある場合、Cassandra はその場合には適していません。もちろん、回避策を講じることはできますが、ACID プロパティをシミュレートするために大量のアプリケーション コードを記述することになり、市場投入までの時間が大幅に短縮されます。また、Cassandra でそのようなシステムを管理するのは、複雑で面倒です。

Cassandra を使用しない場合

上記の説明が理にかなっていれば、答える必要はないと思います。

于 2015-06-21T11:33:24.650 に答える
57

分散データシステムを評価するときは、CAP定理を考慮する必要があります。整合性、可用性、およびパーティションの許容度の2つを選択できます。

Cassandraは、結果整合性をサポートする、利用可能なパーティション耐性のあるシステムです。詳細については、私が書いたこのブログ投稿を参照してください:NoSQLシステムのビジュアルガイド

于 2010-04-20T19:01:38.050 に答える
34

Cassandra は、特定の問題に対する答えです。データが多すぎて 1 つのサーバーに収まらない場合はどうしますか? すべてのデータを多くのサーバーに保存し、銀行口座を壊さず、開発者を狂わせるにはどうすればよいでしょうか? Facebook は、毎日 4 テラバイトの新しい圧縮データを取得しています。そして、この数はおそらく 1 年以内に 2 倍以上増加するでしょう。

これほど多くのデータがない場合、または Enterprise Oracle/DB2 クラスターのインストールとそのセットアップと保守に必要な専門家に何百万ドルも支払う必要がある場合は、SQL データベースで問題ありません。

ただし、Facebook は cassandra を使用しなくなり、MySQL のみを使用してアプリケーション スタック内のパーティショニングを移動し、パフォーマンスの高速化と制御の向上を図っています。

于 2010-04-24T19:30:22.863 に答える
29

NoSQL の一般的な考え方は、アプリケーションに最適なデータ ストアを使用する必要があるということです。財務データのテーブルがある場合は、SQL を使用します。リレーショナル スキーマにマップするために複雑な/遅いクエリを必要とするオブジェクトがある場合は、オブジェクトまたはキー/値ストアを使用します。

もちろん、実際に遭遇する問題はすべて、これら 2 つの極端な問題の中間にあり、どちらのソリューションも完璧ではありません。各ストアの機能と、いずれかを使用した場合の結果を考慮する必要があります。これは、解決しようとしている問題に非常に固有のものです。

于 2010-04-14T22:22:11.203 に答える
15

Cassandra を使用する場合と使用しない場合についての上記の回答に加えて、Cassandra を使用することを決定した場合は、Cassandra 自体を使用しないことを検討することをお勧めします。

上記のいくつかの回答は、Cassandra と多くのプロパティを共有するさまざまな「NoSQL」システムをすでに指摘しており、大小さまざまな違いがあり、特定のニーズに対して Cassandra 自体よりも優れている可能性があります。

さらに、最近 (この質問が最初に尋ねられてから数年後)、Scylla と呼ばれる Cassandra クローン ( https://en.wikipedia.org/wiki/Scylla_(database)を参照) がリリースされました。Scylla は、C++ で Cassandra をオープンソースで再実装したもので、元の Java Cassandra よりもスループットが大幅に高く、レイテンシが低いと主張していますが、(機能、API、およびファイル形式において) ほとんど互換性があります。そのため、すでに Cassandra を検討している場合は、Scylla も検討することをお勧めします。

于 2017-11-07T09:51:11.463 に答える
10

Cassandra をデプロイしている最中に誰かと話していると、多対多をうまく処理できません。彼らは最初のテストを行うためにハッキングの仕事をしています。これについて Cassandra のコンサルタントと話をしたところ、この問題が発生した場合はお勧めしないとのことでした。

于 2010-06-06T22:21:04.403 に答える
4

実際のケースをいくつか読んでみましょう。

http://planetcassandra.org/apache-cassandra-use-cases/

この記事: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

彼らは、MySql を選択しなかった理由を詳しく説明しました。これは、データベースの同期が遅すぎるためです。

(これも2句コミット、FK、PKによる)


Cassandra は Amazon Dynamo ペーパーに基づいています

特徴:

安定

高可用性

バックアップがうまく機能する

読み取りと書き込みは HBase よりも優れています (Java の BigTable クローン)。

ウィキhttp://en.wikipedia.org/wiki/Apache_Cassandra

彼らの結論は次のとおりです。

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

2018年現在、

バックサポートが必要な場合は、ScyllaDB を使用して従来の cassandra を置き換えることをお勧めします。

Postgres kv プラグインも cassandra よりも高速です。マルチインスタンスのスケーラビリティはありません。

于 2014-10-07T03:59:00.010 に答える
3

選択を容易にするもう 1 つの状況は、sum、min、max などの集計関数と複雑なクエリ (上記の金融システムのように) を使用する場合です。その場合、リレーショナル データベースはおそらく nosql データベースよりも便利です。実際に多くの逆インデックスを使用しない限り、nosql データベースでは不可能です。nosql を使用する場合は、コードで集計関数を実行するか、独自の列ファミリに個別に格納する必要がありますが、これによりすべてが非常に複雑になり、nosql を使用して得たパフォーマンスが低下します。

于 2010-04-28T04:31:41.807 に答える
0

Mongodb には、非常に強力な集計関数と表現力豊かな集計フレームワークがあります。開発者がリレーショナル データベースの世界で使い慣れている多くの機能を備えています。たとえば、ドキュメント データ/ストレージ構造により、Cassandra よりも複雑なデータ モデルが可能になります。

もちろん、これにはすべてトレードオフが伴います。したがって、データベース (NoSQL、NewSQL、または RDBMS) を選択するときは、解決しようとしている問題とスケーラビリティのニーズを確認してください。1 つのデータベースですべてを処理できるわけではありません。

于 2013-04-09T14:06:23.270 に答える