CassandraとMongoDB
次のプロジェクトのデータストアとしてCassandraまたはMongoDBを検討していますか？ 2つのデータベースを比較しますか？ CassandraとMongoDBはどちらも「NoSQL」データベースですが、実際には大きく異なります。それらは非常に異なる強みと価値提案を持っているので、どんな比較も微妙なものでなければなりません。最初の要件から始めましょう…これらのデータベースはどちらもRDBMSに置き換わるものでも、「ACID」データベースでもありません。したがって、正規化と一貫性が主要な要件であるトランザクションワークロードがある場合、これらのデータベースはどちらも機能しません。 MySQL、PostgreSQL、Oracleなどの従来のリレーショナルデータベースを使用することをお勧めします。リレーショナルデータベースが邪魔にならないようになったら、決定に役立つCassandraとMongoDBの主な違いを考えてみましょう。この投稿では、特定の機能については説明しませんが、選択に役立ついくつかの高レベルの戦略上の違いを指摘します。
1。表現力豊かなオブジェクトモデル
MongoDBは、リッチで表現力豊かなオブジェクトモデルをサポートしています。オブジェクトはプロパティを持つことができ、オブジェクトは互いにネストすることができます（複数のレベルの場合）。このモデルは非常に「オブジェクト指向」であり、ドメイン内の任意のオブジェクト構造を簡単に表すことができます。階層の任意のレベルで任意のオブジェクトのプロパティにインデックスを付けることもできます-これは非常に強力です！一方、Cassandraは、行と列を備えたかなり伝統的なテーブル構造を提供します。データはより構造化されており、各列には作成時に指定できる特定のタイプがあります。
評決：問題のドメインに豊富なデータモデルが必要な場合は、MongoDBホスティングの方が適しています。
2。セカンダリインデックス
セカンダリインデックスは、MongoDBのファーストクラスの構造です。これにより、ネストされている場合でも、MongoDBに格納されているオブジェクトのプロパティに簡単にインデックスを付けることができます。これにより、これらのセカンダリインデックスに基づいてクエリを実行するのが非常に簡単になります。 Cassandraは、セカンダリインデックスを大まかにサポートしているだけです。セカンダリインデックスも、単一の列と同等性の比較に制限されています。主キーでクエリを実行する場合は、Cassandraが適しています。
評価：アプリケーションにセカンダリインデックスが必要であり、クエリモデルに柔軟性が必要な場合は、MongoDBの方が適しています。
3。高可用性
MongoDBは、「シングルマスター」モデルをサポートしています。これは、マスターノードといくつかのスレーブノードがあることを意味します。マスターがダウンした場合、スレーブの1つがマスターとして選出されます。このプロセスは自動的に行われますが、時間がかかり、通常は10〜40秒かかります。この新しいリーダー選出の期間中、レプリカセットはダウンしており、書き込みを行うことができません。これはほとんどのアプリケーションで機能しますが、最終的にはニーズによって異なります。 Cassandraは「マルチマスター」モデルをサポートしています。単一ノードが失われても、クラスターが書き込みを行う能力には影響しないため、書き込みの稼働時間を100％達成できます。
評決：100％の稼働時間が必要な場合は、Cassandraの方が適しています。
4。スケーラビリティの書き込み
「シングルマスター」モデルを備えたMongoDBは、プライマリでのみ書き込みを行うことができます。セカンダリサーバーは読み取りにのみ使用できます。したがって、基本的に3つのノードのレプリカが設定されている場合、マスターのみが書き込みを行い、他の2つのノードは読み取りにのみ使用されます。これにより、書き込みのスケーラビリティが大幅に制限されます。複数のシャードをデプロイできますが、基本的にデータノードの1/3のみが書き込みを行うことができます。 「マルチマスター」モデルを備えたCassandraは、任意のサーバーで書き込みを行うことができます。基本的に、書き込みのスケーラビリティは、クラスター内にあるサーバーの数によって制限されます。クラスタ内のサーバーが多いほど、拡張性が向上します。
評決：書き込みのスケーラビリティが重要な場合は、Cassandraの方が適しています。
5。クエリ言語のサポート
Cassandraは、SQLに非常によく似たCQLクエリ言語をサポートしています。データアナリストのチームがすでにいる場合は、大規模な組織にとって非常に重要なSQLスキルの大部分を移植できます。ただし、CQLは本格的なANSI SQLではありません。いくつかの制限（結合サポートなし、OR句なし）などがあります。現時点では、MongoDBはクエリ言語をサポートしていません。クエリはJSONフラグメントとして構造化されています。
評決：クエリ言語のサポートが必要な場合は、Cassandraの方が適しています。
6。パフォーマンスベンチマーク
パフォーマンスについて話しましょう。この時点で、データベースのパフォーマンスベンチマークの比較を期待している可能性があります。パフォーマンスベンチマークは意図的に比較に含めていません。いずれの比較でも、リンゴ同士の比較を行っていることを確認する必要があります。
1.データベースモデル -テスト対象のアプリケーションのデータベースモデル/スキーマは大きな違いを生みます。一部のスキーマはMongoDBに最適であり、一部はCassandraに最適です。したがって、データベースを比較するときは、両方のデータベースで適切に機能するモデルを使用することが重要です。
2。 負荷特性 –ベンチマーク負荷の特性は非常に重要です。例えば。書き込みが多いベンチマークでは、CassandraがMongoDBをスモークすることを期待します。ただし、読み取りが多いベンチマークでは、MongoDBとCassandraのパフォーマンスは類似している必要があります。
3。 一貫性の要件 -これはトリッキーなものです。指定された読み取り/書き込みの整合性要件が両方のデータベースで同一であり、1人の参加者に偏っていないことを確認する必要があります。多くの「マーケティング」ベンチマークでは、ノブが反対側に不利になるように調整されていることがよくあります。したがって、一貫性の設定に細心の注意を払ってください。
最後に覚えておくべきことは、ベンチマークの負荷がアプリケーションのパフォーマンスを反映している場合と反映していない場合があることです。したがって、ベンチマークが役立つためには、アプリケーションのパフォーマンス特性を反映するベンチマーク負荷を見つけることが非常に重要です。確認したいベンチマークは次のとおりです。
-NoSQLパフォーマンスベンチマーク
-Cassandravs.MongoDB vs. Couchbase vs. HBase
7。使いやすさ
数年前にこの質問をしたとしたら、MongoDBが勝者となるでしょう。 MongoDBを起動して実行するのは非常に簡単な作業です。しかし、ここ数年で、カサンドラは製品のこの側面で大きな進歩を遂げました。 CassandraのプライマリインターフェイスとしてCQLを採用したことで、これはさらに一歩進んだものになりました。これにより、多くのSQLプログラマーがCassandraを非常に簡単に使用できるようになりました。
評決：どちらもかなり使いやすく、立ち上がることができます。
8。ネイティブアグリゲーション
MongoDBには、データベースに格納されているデータを変換するためにETLパイプラインを実行するための組み込みフレームワークがあります。これは中小規模のジョブには最適ですが、データ処理のニーズが複雑になるにつれて、集計フレームワークのデバッグが困難になります。 Cassandraには組み込みの集約フレームワークがありません。これには、Hadoop、Sparkなどの外部ツールが使用されます。
9。スキーマレスモデル
MongoDBでは、ドキュメントにスキーマを適用しないことを選択できます。これは、新しいバージョンの以前のバージョンではデフォルトでしたが、ドキュメントにスキーマを適用するオプションがあります。 MongoDBの各ドキュメントは異なる構造にすることができ、データを解釈するのはアプリケーション次第です。これはほとんどのアプリケーションには関係ありませんが、場合によっては、追加の柔軟性が重要になります。新しいバージョン（デフォルト言語としてCQLを使用）のCassandraは、静的型付けを提供します。非常に列のタイプを事前に定義する必要があります。
ここに要約すると、表形式の重要な違いは次のとおりです。 
完全なインフォグラフィックを表示したい場合は、CassandraとMongoDBの比較ページにアクセスしてください。