CassandraもMongoDBも、最新のデータを必要とする企業に信頼性の高いスケーラビリティを提供するNoSQLデータベースです。この2つのデータベースシステムのリリースは近く、Cassandraは2008年に登場し、MongoDBはその1年後に登場しました。どちらもオープンソースで、サポートのための大規模なコミュニティが存在します。しかし、この2つの類似点はそこで終わっています。ここでは、CassandraとMongoDBを総合的に見て、2つのデータベースがお互いにどのように異なるかについて見ていきます。
Cassandra vs MongoDB: 主要な違い
- Cassandraはカラムとテーブルを使用してデータを保存しますが、MongoDBはJSONのようなドキュメントでデータを保存します。
- Cassandraはセカンダリインデックスを完全にはサポートしていませんが、MongoDBはデータを取得する際にほとんどインデックスに依存しています。
- Cassandraは独自のクエリ言語（CQL）を持っていますが、MongoDBはPythonやJavaなどの人気のあるサードパーティ製言語をサポートしています。
- Cassandraは集計をサードパーティのツールに依存していますが、MongoDBには集計フレームワークが組み込まれています。
- Cassandraは分散アーキテクチャを使用しているため可用性が高く、MongoDBがプライマリ/セカンダリアーキテクチャに依存しているのでフォールト・トレランスが低いのに対し、Cassandraは分散アーキテクチャを使用しています。
- Cassandraはよりスケーラビリティの高いMySQLスタイルのデータベースを求めている人に適しており、MongoDBは非構造化データの保存に最適です。
Cassandra vs MongoDB: 知っておくべきポイント
どちらのデータベースにも注目度の高い顧客がいます。Netflix、Instagram、Huluなどの巨大企業は、データ・ストレージのニーズを満たすためにCassandraを利用しています。同様に、Google、Adobe、Paypalなどの巨大企業もMongoDBを使用しています。しかし、2つのデータベースは、データの保存方法やデータの複製などの機能が異なります。ここでは、CassandraとMongoDBの主な違いについてご紹介します。
Table of Contents:
データ構造
Cassandraは、データを格納する方法という点ではリレーショナル・データベースに近いです。これは列指向のデータベースで、データをテーブルに格納します。しかし、リレーショナル・データベースとは異なり、その場でカラムやテーブルを作成することができます。さらに、Cassandraのすべての行が同じ列を持つ必要はありません。表型データベースは、データを取得する際、主キーに依存しています。
一方、MongoDBはオブジェクト指向のデータベースです。データを格納するためにBSON（バイナリJSON）を使用します。MongoDBは様々なオブジェクト構造をサポートしており、入れ子になったオブジェクト構造を作成することもできます。JSONのスキーマが不要なので、MongoDBはCassandraに比べてはるかに柔軟性があります。ただし、必要に応じてMongoDBでスキーマを作成することもできます。
セカンダリ・インデックス
セカンダリ・インデックスは、非キー属性であるデータにアクセスするのに便利です。Cassandraはセカンダリ・インデックスを完全にはサポートしていません。情報の取得はプライマリ・キーに依存します。
MongoDBは、クエリにインデックスを使用します。クエリ速度を向上させることができるセカンダリ・インデックスを完全にサポートしています。ネストされたオブジェクトを含め、オブジェクトの任意のプロパティを本当に素早くクエリすることができます。
データを統一化して革新を起こすデータチームへ
ソリューションエンジニアによる個別デモと30分のQ&Aセッションを受けることができます
クエリー言語
Cassandraは、データをフェッチするためにCassandra Query Language（CQL）を採用しています。CQLはSQLに非常に似ています。SQLに精通しているデータベース管理者は、CQLを扱うのが非常に簡単だと感じるはずです。
MongoDBはJSONのようなドキュメントでデータが保存されるため、クエリ言語のオプションがたくさんあります。管理者はMongoシェル、PHP、Perl、Python、Node.js、Java、Compass、Rubyを使ってMongoDBにクエリを実行することができます。
スケーラビリティ
Cassandraでは、複数のプライマリ・ノードを使用できるため、書き込みスケーラビリティが大幅に向上します。クラスタで必要なノード数を指定できます。ノード数が多いほど、データベースのスケーラビリティが向上します。
MongoDBでは、プライマリ・ノードはひとつしか使えません。クラスタ内の他のノードはすべてセカンダリです。データがプライマリ・ノードに書き込まれている間は、セカンダリ・ノードでしか読み込み操作ができません。プライマリ・セカンダリ・アーキテクチャのため、MongoDBはCassandraほどスケーラブルではありません。しかし、シャーディング技術を使えば、MongoDBのスケーラビリティを向上させることができます。ただし、そのためには多少の設定が必要になります。
2つのプライマリ・ノードの解釈方法の違いは、フォールトトレランスを決めることにもなります。Cassandraは複数のプライマリを許可しているので、ノードが故障してもクラスタに書き込むことができます。MongoDBでは、プライマリが1つしか使えないので、ノードが故障した場合の書き込み操作に10～40秒待たなければならないかもしれません。事実上、Cassandraは可用性の面ではMongoDBを凌駕しています。
集計
集計により、複雑なクエリを実行することができます。Cassandraには集計フレームワークがありません。管理者は、集計にHadoopやSparkなどのサードパーティ製ツールを使用する必要があります。
それに比べてMongoDBは、集計フレームワークを内蔵しています。これはETLパイプラインを実行して保存データを集計し、結果を返すことができます。しかし、データベースに内蔵されている集計は、中程度のトラフィックにしか効率的ではありません。規模が大きくなるにつれて、集計フレームワークの取り扱いはより複雑になります。
パフォーマンス
データベースがどのように動作するかには、多くの要因が絡んでいます。例えば、使用するスキーマの種類は、クエリの速度に極めて重要な役割を果たします。同様に、入力と出力の負荷特性もデータベースのパフォーマンスに影響を与えます。CassandraとMongoDBを比較した2018年のベンチマークレポートによると、Cassandraは書き込み集中型の操作で能力を発揮しています。
ライセンス
どちらのデータベースもオープンソースのフリー・ソフトウェアとして提供されています。DatastaxなどのサードパーティベンダーがエンタープライズグレードのCassandraを提供しています。一方、MongoDBは、その名を冠したソフトウェア会社が管理しています。どちらもサブスクリプションモデルで、ベーシックなものから上級者向けのものまで、さまざまなレベルのプランが提供されています。また、AWSマーケットプレイスでCassandraとMongoDBを見つけて、パブリッククラウドにホストすることもできます。
まとめ
どちらのデータベースにも長所と短所があります。選ぶべきデータベースは、優先順位によって異なります。可用性の面では、Cassandraが優位に立っています。高度に分散されたアーキテクチャを採用しているため、ノードが故障してもクラスタへの書き込みを継続することができます。一方、MongoDBは構造化されていないデータを保存するのに適しています。スキーマフリーのアーキテクチャなので、高速なキャッシングやロギングに適しています。リアルタイムの分析やストリーミングアプリケーションは、高速なキャッシングやロギングを利用しています。MongoDBはセカンダリインデックスをサポートしているので、高速なクエリ時間を実現するのにも最適です。しかし、データ操作を迅速にスケーリングしたいのであれば、Cassandraの方が適しているでしょう。
どんなデータベースもIntegrate.ioがお手伝いします。
ユースケースに応じてどのようなデータベースを選んでも、Integrate.ioは他のデータソースと素早く統合し、迅速なデータ分析を行うことができます。Integrate.ioのドラッグ＆ドロップインターフェースは、複雑なコーディングなしで、数分以内にETLパイプラインを構築することができます。Integrate.ioがどのようにデータ統合を簡単かつシンプルにするのか、ぜひご自身で確かめてみてください。
