Apache CassandraとMongoDBの比較

Apache CassandraとMongoDBは広く採用されているNoSQLデータベースで、大量のデータの保存と管理を目的に設計されています。

これら2つのデータベース・システムの人気の理由のひとつは、高い拡張性と可用性にあります。どちらも10年以上にわたり利用されており、Cassandraは2008年にオープンソース・プロジェクトとしてリリースされ、MongoDBはその翌年にリリースされました。

共通点はあるものの、Apache CassandraとMongoDBはデータモデル、アーキテクチャー、その他のコンポーネントにおいて大きく異なります。これらの基盤的な違いが、主要な特性に関するパフォーマンスに影響を及ぼし、どのデータ管理ユースケースに最適かを左右します。

Apache CassandraとMongoDBを比較する前に、NoSQLデータベースについて理解しておくとよいでしょう。

NoSQLデータベースは「not only SQL」や「non-SQL」データベースとも呼ばれる分散データベースです。つまり、内部の情報は複数のノード（データを保存する個別のサーバー）に複製されます。この分散アーキテクチャーは高い可用性と耐久性を支え、1つ以上のノードがオフラインになっても残りのデータベースは稼働し続けます。

特筆すべきは、NoSQLデータベースがリレーショナル・データベース管理システム（RDBMS）の従来構造外でデータを保存・クエリーするよう設計されている点です。従来のリレーショナル・データベースに内在する厳格なテーブル構造に従うのではなく、非リレーショナル・データベース設計では厳密なスキーマを必要としません。これにより、構造化データ、半構造化データ、非構造化データを含む大規模データセットの管理に向けた迅速な拡張性が実現します。

（注：CassandraやMongoDBを含むNoSQLデータベースで評価される拡張性とは、水平方向の拡張性、すなわち「スケール・アウト」です。スケール・アウトではワークロードを複数のサーバーに分散できます。これに対し、SQLデータベースに関連する垂直方向の拡張性、すなわち「スケール・アップ」は、既存ハードウェアにメモリーを追加する必要があります。）

その性能、拡張性、柔軟性により、NoSQLデータベースはビッグデータ・アプリケーションやリアルタイムワークロードを支えるための第一選択肢となっています。Apache CassandraやMongoDBに加えて、AWSが提供するDynamoDB、Redis、CouchDBといった他のNoSQLデータベースも人気があります。

両者はいずれも2000年代初頭から数年後に登場しましたが、その歩みは異なります。

Apache Cassandraは2007年ごろのFacebookにさかのぼります。当時、エンジニアたちは拡大するメッセージング・プラットフォームのためにデータを保存できるシステムを求めていました。既存のNoSQLデータベース・モデルを組み合わせることで、効率的なデータ構造と、すべてのレプリカが時間の経過とともに一致する「最終的な整合性」を持つシステムを構築しました。エンジニアたちは2008年にCassandraをオープンソース・プロジェクトとして公開し、翌年にはApache Software Foundationが運営責任を引き継ぎました。

MongoDBは2007年、10Gen社が立ち上げたPlatform-as-a-Serviceプロジェクトの一環として誕生しました。社名の由来は「humongous（巨大な）」にちなんだもので、MongoDBを高速かつ使いやすいドキュメント指向データベースとして開発する方向へと軸足を移しました。¹

その後10Genは社名をMongoDB Inc.に変更し、2009年にMongoDBをオープンソース・プロジェクトとして公開しました。ただし、最新バージョンのMongoDBはServer Side Public License v1の下で公開されています。

Apache CassandraとMongoDBの基盤的な違いは、パフォーマンスや最適なユースケースに大きな影響を与えます。主な要素は次のとおりです。

• データ・モデル
• アーキテクチャーとストレージ
• クエーリとその他の言語

NoSQLデータベースは、次の4種類のデータモデルのいずれかに基づいています。

• ドキュメント・モデル：データは構造化されたドキュメントとして保存され、通常はJSON（JavaScript Object Notation）やBSON（Binary JSON）形式で表現されます。
• ワイド・カラム・モデル：データはスパース（疎）カラムを持つテーブルに保存され、各行が異なる数のカラムを持つことができます。
• キー・バリュー・モデル：データはキー・バリュー・ペア（識別子またはラベルと特定の値の組み合わせ）として保存されます。
• グラフ・モデル：データはノードとエッジとして保存され、エンティティーとその関係性を表します。

Cassandraのデータ・モデルはワイド・カラム・モデルであり、ワイド・カラム・ストアとも呼ばれます。Cassandraのテーブル内の各行はカラムの集合と一意のパーティション・キーを持ち、このキーによってデータはノードやデータセンター全体に分散されます。行はプライマリー・キーで識別され、これはパーティション・キーと、オプションでクラスタリング・キー（パーティション内または関連グループ内で行を一意に識別するカラム）で構成されます。

このアプローチは、固定されたカラム数にスペースが割り当てられるリレーショナル・データベースより柔軟です。Cassandraのデータ・モデルでは、必要な場合にのみカラムを使用するため、より効率的な保存と高速なクエリーが可能になります。²

一方、MongoDBはドキュメント・モデルを使用します。データは主にBSONとして保存され、これはMongoDBが開発したJSONのバイナリー表現です。

BSONは、データベースにおいて標準的なJSONが抱えていた課題に対応するために設計されました。具体的には、サポートできるデータ型が限られていること、オブジェクトに固定長がなく走査速度が遅くなること、メタデータが不足していてドキュメントの取得が遅くなることなどです。BSONはフォーマットや長さの情報をエンコードすることで速度と効率を最適化し、日付やバイナリー・データといったJSONには存在しないデータ型もサポートします。³

NoSQLデータベースとして、Apache CassandraとMongoDBはいずれも分散システムをサポートし、複数のコンピューティング・リソースにデータを分散保存することでダウンタイムを軽減します。しかし、その分散を支えるアーキテクチャーは、データモデルと同様に根本的に異なります。

Apache Cassandraはピア・ツー・ピア型アーキテクチャーを採用しています。Cassandraクラスター内のすべてのノードは対等であり、マスター・ノードに依存しません。データがクラスターに投入されると、その行のパーティション・キーにハッシュ関数が適用され、その出力によってデータが特定のノードに割り当てられます。さらに、そのデータは他のノードにもコピーされます。

Cassandraデータベースの複製要因は、データベース内に保存されるデータのコピー数を表します。Cassandraのストレージ・エンジンは、コミット・ログ、インメモリー・テーブル（memtable）、ソート済み文字列テーブル（SSTable）ファイルからなるステップ・バイ・ステップのフロー（書き込みパス）を使用しています。

これに対してMongoDBは、分散アーキテクチャーにプライマリー／セカンダリー・モデルを採用しています。MongoDBではレプリカ・セット（インスタンスのグループ）がプライマリー・ノードとセカンダリー・ノードで構成され、プライマリー・ノードがすべての書き込み処理（データの追加や変更）を担当し、セカンダリー・ノードはプライマリー・ノードのデータを反映します。

MongoDBでは、大規模データセットをシャーディングと呼ばれるプロセスを通じて複数のマシンに分散することも可能です。情報はシャード化されたクラスター（複数のレプリカ・セットと、アプリケーションからのクエリーをレプリカ・セットに転送するルーター）に分割され、データ要求を処理するシステムの能力を高めます。

両データベースはインデックス手法も異なります。Apache Cassandraではパーティション・キーがプライマリー・インデックスですが、Cassandraのドキュメントには、非パーティション列に対してインデックスを作成するストレージアタッチド・インデックスがほとんどのユースケースに適していると記されています。⁴また、Cassandraにはセカンダリー・インデックスもあり、インデックス対象の値とは別のテーブルに保存されるローカル・インデックスとして動作します。MongoDBは、地理空間インデックス、マルチキー・インデックス、テキスト・インデックスなど、ユースケースに応じて複数のインデックスタイプをサポートします。

定義上、NoSQLデータベースはリレーショナル・データベース用の標準プログラミング言語であるSQL（Structured Query Language）を使用しません。しかし、Apache CassandraとMongoDBはいずれも独自のクエリー言語を備えています。

Cassandra Query Language（CQL）：SQLをベースにしたカスタマイズ版で、見た目はSQLに似ていますが、重要な違いがあります。例えば、SQLは正規化されたテーブルを操作するのに対し、CQLはパーティション・キーに基づく非正規化データを扱うよう設計されています。また、SQLはトランザクション処理に最適化されていますが、CQLはリアルタイム・クエリーや大量の書き込み処理に最適化されています。

MongoDBはMongoDB Query Language（MQL）を使用します。ドキュメント・モデルをクエリーするために設計されており、MQLの構文はドキュメントと同じです。これにより、Cassandra Query LanguageよりもSQLから大きく乖離しています。MQLは、複雑なクエリー、アグリゲーション・パイプライン、地理空間データに対するクエリーなど、幅広いクエリーやデータ操作機能を可能にすると評価されています⁵。

プログラミング言語のサポートにも違いがあります。MongoDBはJava、Python、Ruby、Node.jsなど10種類以上のプログラミング言語に対して公式ドライバーを提供しています。Cassandraもこれらを含む多くの言語に対応していますが、ドライバーの多くはサードパーティーによって提供されています。

こうしたApache CassandraとMongoDBの基盤的な違いは、性能特性にも影響します。これらの違いはCAP定理によって説明できます。

CAP定理は、分散システムが満たすべき次の3つの特性を示しています：整合性（Consistency）：すべてのクライアントが同じタイミングで同じデータを確認できること、可用性（Availability）：1つ以上のノードがダウンしていても、データ要求を行ったクライアントは必ず応答を受け取れること、分割耐性（Partition tolerance）：複数のノード間で通信障害が発生しても、クラスターが動作を続けられること。

CAP定理によると、分散システムは3つすべてを同時に満たすことはできず、2つだけを満たすことになります。Apache Cassandraは一般に「AP」データベースと分類され、可用性と分割耐性を重視することで高いパフォーマンスを発揮します。

一方、MongoDBは「CP」データベースとして知られ、分割耐性と整合性の面で優れています。しかし、両データベースには、性能が犠牲になるとされる特性――すなわちCassandraにおける整合性、MongoDBにおける可用性――を改善するための手段も存在します。

3つの求められる特性について、さらに詳しく見ていきましょう。

Cassandraは高可用性をサポートしています。これは、データが複数のノードに複製される分散型システムであるため、高いフォールトトレランスを備え、単一障害点が存在しないからです。1つのノードがダウンしても、同じデータのコピーを持つ他のノードがデータ要求を処理できます。さらに、世界中のデータセンターにデータが複製されているため、ローカル・ユーザーは低レイテンシーでアクセスできます。

一方、MongoDBのアーキテクチャーはプライマリー／セカンダリー・モデルに基づいているため、プライマリー・ノードがダウンすると単一障害点が発生する可能性があります。しかし、MongoDBのフェイルオーバーは堅牢であると考えられています。いわゆるレプリカ・セット選挙の際に、レプリカ・セットに属するノードが新しいプライマリー・ノードを選出し、利用できなくなったプライマリーを置き換えます。このプロセスにより、MongoDBも高可用性を提供しますが、短い遅延を伴います。つまり、新しいプライマリー・ノードが選ばれるまでは処理が再開されません。

MongoDBは、本質的に高い整合性を実現しています。すべてのクライアントが単一の正確なソースに対して書き込みを行うためであり、各レプリカ・セットには書き込み処理を受け付けるプライマリー・ノードが1つしか存在しません。これに対して、Apache Cassandraは最終的な整合性を提供します。クライアントは任意のノードにいつでも書き込みを行えますが、不整合は可能な限り迅速に調整されます。

さらにCassandraでは、ユーザーがいわゆる調整可能な整合性を通じて整合性を最適化（可用性を低優先にする）することも可能です。ユーザーは整合性レベルを選択でき、読み取りや書き込みをクライアント・アプリケーションに確認する前に、どの程度のレプリカが応答しなければならないかを設定します。高いレベルの整合性を選ぶと、より多くのレプリカからの応答が必要になりますが、その分レイテンシーが増加し、可用性が低下します。

Apache CassandraとMongoDBはいずれも分割耐性を提供します。これは、システムの一部で通信障害が発生しても機能を継続できるように設計されているためです。

Apache Cassandraでは、通信に問題が生じてもノードは利用可能な状態を維持しますが、分割が解消されるまで一部のノードは最新のデータを返せない場合があります。一方、MongoDBでは、分割の処理中にデータの整合性を確保するため、可用性が制限されます。

Apache Cassandraは、高スループット、グローバル分散、書き込み負荷の大きいワークロードに適しており、可用性と拡張性が重要となるユースケース――例えばストリーミングやエンターテインメント――で推奨されます。実際、Netflixのようなストリーミング・サービスはCassandraを利用して世界規模のユーザー・アクティビティーを処理しています。

MongoDBは、ドキュメント中心で柔軟なスキーマを必要とするユースケースに最適です。開発者の俊敏性や強力な整合性が求められるシナリオで活用され、企業はコンテンツ管理システムを支えるためにMongoDBを利用することがよくあります。MongoDBは多様なコンテンツ資産を保存・配信できるためです。

このように両データベースには違いがあるものの、Apache CassandraのユースケースとMongoDBのユースケースは重なる部分もあります。それぞれのデータベースに関する事例では、IoT（モノのインターネット）やEコマースなどの用途における有効性が示されています。