MongoDB と Cassandra：惑星規模の書き込み

MongoDBとApache Cassandraはいずれも大規模な分散データを扱えますが、アーキテクチャは根本的に異なります。MongoDBは、レプリカセットごとに単一のプライマリへ書き込むリーダー・フォロワー（プライマリ・セカンダリ）モデルを使用します。Cassandraは、どのノードでも任意の書き込みを受け付けられるリーダーレス（ピアツーピア）モデルを使用します。このアーキテクチャの違いが、両者のパフォーマンス、整合性、運用に関するあらゆるトレードオフを左右します。

Cassandraでは、リングトポロジー内のすべてのノードが対等なピアです。書き込みは任意のノード（コーディネーター）に送信でき、コーディネーターがその行のパーティションキーを担当するN個のレプリカノードへ転送します。書き込みを確認する必要があるノード数は、整合性レベル（ONE、QUORUM、ALLなど）で設定します。このアーキテクチャにより単一プライマリのボトルネックがなくなり、真のマルチマスター・マルチリージョン書き込みが可能になります。つまり、すべてのデータセンターで同時に書き込みを受け付けられます。

Cassandraは極めて高い書き込みスループットに最適化されています。書き込みは、ディスク（SSTable）へ一括フラッシュされる前に、コミットログと高速なインメモリ構造（Memtable）へ追記されます。この追記専用方式ではディスク上で書き込みが競合せず、ノード数に比例してスループットが拡大します。毎秒数百万件の測定値を取り込むIoTプラットフォーム、イベントログシステム、単一のMongoDBプライマリでは処理しきれない書き込み速度の時系列ワークロードは、Cassandraの代表的なユースケースです。

Cassandraの整合性レベルはクエリごとに調整できます。ONEは1つのレプリカが確認する設定で、最も高速ですが整合性は最も弱くなります。QUORUMはレプリカの過半数が確認する設定で、遅延と整合性のバランスが取れます。ALLはすべてのレプリカが確認する設定で、最も低速ですが整合性は最も強くなります。重要な式は、読み取り整合性 + 書き込み整合性 > レプリケーション係数の場合、強整合性が得られるということです。この柔軟性により、同じクラスター内でも異なるワークロードに応じたサービスを提供できます。

Cassandraのデータモデルは根本的にクエリ駆動型です。特定のクエリに効率よく答えられるようにテーブルを設計します。MongoDBのようなアドホッククエリエンジンはありません。テーブルはパーティションキー（行を格納するノードを決定します）でパーティション分割する必要があり、パーティション内の行はクラスタリングキーでソートされます。セカンダリインデックスも存在しますが、MongoDBのものよりはるかに機能が限られます。MongoDBが集約パイプラインで処理できる複雑なクエリ（結合、集計、複数フィールドのフィルター）は、標準のCQLでは実行できません。

MongoDBの集約パイプラインと豊富なクエリ演算子により、任意のフィールドに対するアドホッククエリが可能です。たとえば、過去30日間に特定の商品を購入したイスタンブール在住のユーザーをすべて検索したい場合、適切な複合インデックスを持つMongoDBクエリで直接実行できます。Cassandraでは、この特定のクエリ用にあらかじめテーブルを設計するか、データを複数のテーブルに非正規化するか、分析クエリにSparkを使用する必要があります。変化するクエリ要件に対しては、MongoDBのほうがはるかに柔軟です。

Cassandraのリーダーレスなマルチデータセンターレプリケーションでは、アクティブ・アクティブ構成が可能です。すべてのリージョンで同時に書き込みを受け付けられます。ニューヨークのユーザーが米国のデータセンターに書き込むと、そのユーザーのデータは欧州とアジアへ非同期に複製されます。MongoDBもレプリカセットの読み取り設定やグローバルクラスター（Atlas）によってマルチリージョンに対応しますが、書き込みは引き続き単一のプライマリリージョンへルーティングする必要があります。すべてのリージョンから遅延なく書き込めることが必要なアプリケーションでは、Cassandraが構造上有利です。

w: majorityを指定したMongoDBは強整合性を提供します。書き込みが確認されると、それ以降のすべての読み取りで新しい値が返されます。Cassandraのデフォルト設定は結果整合性です。ONEで確認された書き込みは、他のレプリカからの読み取りですぐに見えるとは限りません。アプリケーション側でこの状態を許容するか、QUORUMの読み取りと書き込みを設定して、遅延の増加と引き換えに強整合性を実現する必要があります。この違いはアプリケーションの複雑さに大きく影響します。

どちらのシステムにも運用の専門知識が必要ですが、求められる分野は異なります。MongoDBのレプリカセットアーキテクチャは十分に確立されており、Atlasによってほぼすべての運用を自動化できます。Cassandraのリングトポロジーでは、キャパシティプランニング、トークン管理、コンパクション監視、トゥームストーン管理を慎重に行う必要があります。Cassandraでの削除はトゥームストーンを生成し、時間の経過とともに蓄積して読み取り性能を低下させる可能性があります。MongoDBの削除モデルのほうが運用上は単純です。小規模から中規模のチームでは、一般にMongoDBの運用負荷のほうが低くなります。

どちらのデータベースもIoTや時系列ワークロードに使われますが、アプローチは異なります。Cassandraの時系列パーティショニング（デバイスごとにパーティション分割し、時間でクラスタリング）では、非常に高い書き込みスループットと、デバイスごとの効率的な時間範囲スキャンを実現できます。MongoDBのネイティブ時系列コレクション（5.0で追加）は、自動バケット化と列指向ストレージによって差の多くを縮めています。数千のデバイスから毎秒数百万件の書き込みが発生する規模では、依然としてCassandraが優位です。この規模未満で、より豊富なクエリが必要なワークロードでは、MongoDBの時系列機能のほうが実用的なことが多いです。

次の条件ではCassandraを使用します。書き込みスループットが毎秒数百万件である、マルチリージョンのアクティブ・アクティブ書き込みが必要である、アクセスパターンが非常に予測しやすい（クエリごとにテーブルを用意する）こと、データ保持のTTLが単純であることです。次の条件ではMongoDBを使用します。クエリパターンが頻繁に変化する、複雑な集計や結合が必要である、ドキュメントの柔軟性が重視される、チームが小規模から中規模である、またはドキュメント間の完全なACIDトランザクションが必要である場合です。

このレッスンでは、次のことを学びました。Cassandraのリーダーレスアーキテクチャは、MongoDBのプライマリ・セカンダリモデルでは実現できない、大規模な書き込みスループットと真のアクティブ・アクティブなマルチリージョン書き込みを可能にします。Cassandraのクエリモデルはスキーマ／テーブルファーストである一方、MongoDBは豊富なアドホッククエリをサポートします。そして両者の選択は、必要な書き込み規模、求められるクエリの柔軟性、チームが対応できる運用負荷によって決まります。次はMongoDBとDynamoDBを比較します。