はじめに
NoSQLデータベースを検索している場合は、おそらくCassandraとMongoDBに出くわしたことでしょう。それでも、これら2つの人気のあるNoSQLの選択肢は、予想よりもはるかに共通点が少なくなっています。
このチュートリアルでは、CassandraとMongoDBの類似点と相違点について説明します。
CassandraとMongoDB：類似点
2つのデータベースシステムを比較する場合、通常、類似点も共有されていると推測されます。それらは存在しますが、CassandraとMongoDBに関しては、これらの類似点は限られています。
NoSQLデータベース
最も重要なことは、CassandraとMongoDBがNoSQLデータベースとして分類されていることです。 NoSQL（SQLだけでなく）は、従来のデータベースの一般的な代替手段です。私たちが知っているリレーショナルデータベースとは異なり、NoSQLは論理的なカテゴリやスキーマを必要とせずに大量のデータを保存できます。
従来のデータベースでは多くの非構造化データをリアルタイムで処理できなかったため、NoSQLデータベースは水平方向にスケーリングすることで課題に取り組みました。
したがって、CassandraはこれらのNoSQLデータベースの1つとして2008年にリリースされました。 1年後、MongoDBが作成されました。
オープンソースソフトウェア
これら2つの共通点は、無料のオープンソースソフトウェアであるということです。データベースパッケージをダウンロードし、セットアップし、構成することができます。
当初はFacebookの開発者によって作成されましたが、現在、CassandraはApacheプロジェクトの所有下にあり、そのオープンソースコミュニティの一部です。一方、MongoDBは、MongoDB開発者の強力なコミュニティを持つ、世界で最も人気のあるデータベース管理システムの1つです。
RDBMSとACIDを置き換えることはできません
CassandraもMongoDBも、従来のリレーショナルデータベース管理システム（RDBMS）を置き換えることはできないことに注意してください。行と列を使用して構造化された形式でデータを保存する必要がある場合は、利用可能な多くのリレーショナルデータベースの1つに固執してください。
さらに、ACID準拠のデータベースが必要な場合、NoSQLはおそらく最善のソリューションではありません。アトミック性、一貫性、分離性、耐久性を保証するデータベーストランザクションの場合、MySQLやPostgreSQLなどのリレーショナルデータベースを使用することをお勧めします。
CassandraとMongoDB：違い
データの可用性
MongoDBとCassandraの最も重要な違いの1つは、データの可用性に関する戦略です。この機能は、クラスター内のマスタースレーブの数に依存します。
MongoDB 複数のスレーブノードを指示する単一のマスターがあります。マスターノードがダウンすると、スレーブノードの1つがその役割を引き継ぎます。自動フェイルオーバーの戦略は確実に回復しますが、スレーブがマスターになるまでに最大1分かかる場合があります。この間、データベースはリクエストに応答できません。
カサンドラ 一方、別のモデルを使用します。マスターノードを1つ持つ代わりに、クラスター内で複数のマスターを利用します。複数のマスターが存在するため、ダウンタイムの心配はありません。冗長モデルにより、常に高可用性が保証されます。
スケーラビリティ
スケーラビリティは、クラスターモデルに直接リンクされている機能です。したがって、CassandraとMongoDBには、書き込みのスケーラビリティに大きな違いがあります。
マスターノードのみが入力の書き込みと受け入れを行うことができます。その間、スレーブノードは読み取りにのみ使用されます。したがって、 MongoDB マスターノードが1つしかないため、書き込みのスケーラビリティが制限されます。
複数のマスターノードがあると、カサンドラが増加します 書き込み機能。これにより、このデータベースは、すべてマスターからの多数の書き込みを同時に調整できます。したがって、クラスター内のマスターノードが多いほど、書き込み速度（スケーラビリティ）が向上します。
データモデル
それでは、これら2つのNoSQLデータベースのデータモデルを調べてみましょう。
MongoDBの データモデルは、オブジェクト指向とドキュメント指向に分類されます。これは、プロパティを持つことができる、または複数のレベルにネストすることさえできる、あらゆる種類のオブジェクト構造を表すことができることを意味します。
カサンドラに関しては、より伝統的なモデルがあります。 カサンドラ 行と列を使用したテーブル構造を持っています。それでも、各行が同じ列を持つ必要がないため、リレーショナルデータベースよりも柔軟性があります。作成時に、これらの列には使用可能なCassandraデータ型の1つが割り当てられ、最終的にはデータ構造に依存します。
クエリ言語
もう1つの際立った要素は、クエリ言語をサポートするデータベースが必要かどうかです。
MongoDB JSONフラグメントに構造化されたクエリを使用し、クエリ言語はまだサポートされていません。あなたまたはあなたのチームがSQLに慣れている場合、これは慣れるべきものです。ただし、管理は簡単です。
MongoDBとは異なり、 Cassandra CQL（Cassandra Query Language）と呼ばれる独自のクエリ言語があります。その構文はSQLに似ていますが、それでもいくつかの制限があります。基本的に、データベースは非リレーショナルであるため、データの保存と回復の方法が異なります。
クエリはどのように異なりますか？
以下の例では、MongoDBのクエリがCassandraで使用されているクエリとどのように異なるかを確認できます（デモ従業員での作業中） 表）。
レコードの選択 従業員テーブルから：
MongoDB
‘db.employee.find()’カサンドラ
‘SELECT * FROM employee;’レコードの挿入 従業員テーブルに：
MongoDB
‘db.employee.insert({ empid: '101', firstname: 'John', lastname: 'Doe', gender: 'M', status: 'A'})’カサンドラ
‘INSERT INTO employee (empid, firstname, lastname, gender, status) VALUES('101', 'John', 'Doe', 'M', 'A');’レコードの更新 従業員テーブル：
MondgoDB
'db.Employee.update({"empid" : 101}, {$set: { "firstname" : "James"}})'カサンドラ
‘UPDATE employee SET firstname = ‘James' WHERE empid = '101';’サポートされているプログラミング言語
MongoDB： Actionscript、C、C＃、C ++、Clojure、ColdFusion、D、Dart、Delphi、Erlang、Go、Groovy、Haskell、Java、JavaScript、Lisp、Lua、MatLab、Perl、PHP、PowerShell、Prolog、Python、R、Ruby、 Scala、Smalltalk
カサンドラ： C＃、C ++、Clojure、Erlang、Go、Haskell、Java、JavaScript、Perl、PHP、Python、Ruby、Scala
集約
MongoDBとCassandraのどちらを選択するかは、組み込みの集約フレームワークが必要かどうかによっても決まる場合があります。
MongoDB 組み込みの集約フレームワークがあります。この機能により、ELTマルチステージパイプラインを利用してドキュメントを集計結果に変換することにより、データを取得できます。ただし、このようなフレームワークは、小規模または中規模のデータトラフィックを処理する場合にのみ効率的です。
カサンドラ 集約フレームワークがなく、Hadoop、Sparkなどの外部ツールが必要です。
スキーマ
スキーマに関しては、柔軟なデータベースと固定データベースのどちらが必要かを決定する必要があります。
MongoDB はスキーマを必要としないデータベースであり、当然、変更への適応性が高くなります。以前のバージョンでは、デフォルト構成ではスキーマがまったく適用されていませんでした。今日では、スキーマが必要かどうかを決定できます。このような柔軟性は、データベースがさまざまな構造のドキュメントを入力し、ソフトウェアで一度解釈できることを意味します。
カサンドラ はるかに静止したデータベースです。静的型付けを容易にし、列の分類と定義を事前に要求します。
セカンダリインデックス
セカンダリインデックスの品質によって、データベース内のレコードにどれだけ効率的にアクセスできるかが決まります。これらのインデックスがサポートされる範囲は、MongoDBとCassandraで同じではありません。
MongoDB 高品質のセカンダリインデックスがあります。柔軟なデータモデルとセカンダリインデックスにより、保存されたオブジェクトの任意のプロパティにアクセスできます（ネストされている場合でも）。
または、カサンドラ セカンダリインデックスのカーソルサポートのみがあります。そのクエリは、単一の列と同等性の比較に制限されています。
パフォーマンス
これら2種類のデータベースのパフォーマンスに影響を与える要因はいくつかあります。
主に、データベースモデル（またはスキーマ） MongoDBに適しているものもあれば、Cassandraでうまく機能するものもあるため、パフォーマンス品質に大きな違いがあります。
さらに、負荷特性 データベースがサポートする必要のあるアプリケーションの中でも、重要な役割を果たします。重い負荷の入力が予想される場合は、複数のマスターノードを持つCassandraの方が良い結果が得られます。負荷の高い出力では、MongoDBとCassandraの両方が良好なパフォーマンスを示します。
最後に、多くの人が、一貫性の要件に関しては、MongoDBが優位に立つと考えています。 。それでも、これはアプリケーションによって異なる場合があります。また、設定した整合性基準を満たすようにCassandraを手動で構成することもできます。