リレーショナルデータベースが万能でした時代は終わり、アプリケーションの要件に応じてデータストアを選択する時代になった。大量のデータを高速に読み書きする必要がある場合、スキーマの柔軟性が求められる場合、あるいは地理的に分散した環境でのデータレプリケーションが必要な場合など、NoSQLデータベースが真価を発揮するユースケースは多いです。
しかし、NoSQLと一口に言っても、その設計思想やデータモデルは製品ごとに大きく異なります。本記事では、ドキュメント型のMongoDB、キーバリュー型のDynamoDB、ワイドカラム型のCassandraという3つの代表的なNoSQLデータベースを比較し、それぞれの特性と適切な利用シーンを整理します。
MongoDBはドキュメント指向のNoSQLデータベースです。JSON（正確にはBSON）形式でデータを格納し、スキーマレスな設計が最大の特徴です。コレクション内のドキュメントは異なる構造を持つことが許容されるため、アプリケーションの進化に合わせてデータ構造を柔軟に変更できます。
リッチなクエリ言語を備えており、集約パイプライン（Aggregation Pipeline）による複雑なデータ処理も可能です。セカンダリインデックス、テキスト検索、地理空間インデックスなど、多彩なインデックス機能を持っている点も強みです。
MongoDBのレプリケーションはレプリカセットと呼ばれる仕組みで実現されます。プライマリノードとセカンダリノードで構成され、プライマリがダウンした場合は自動的にフェイルオーバーが行われます。シャーディングによる水平スケーリングにも対応していますが、シャードキーの設計がパフォーマンスに大きく影響するため、慎重な検討が必要です。
MongoDBは以下のようなシーンで特に力を発揮します。
DynamoDBはAWSが提供するフルマネージドのキーバリュー型データベースです。パーティションキーとオプションのソートキーで構成されるプライマリキーにより、データのアクセスパターンを定義します。設計の核となるのは、アクセスパターンを事前に決定し、それに最適化したテーブル設計を行うという考え方です。
一桁ミリ秒のレイテンシでの読み書きが保証されており、DAX（DynamoDB Accelerator）を使えばマイクロ秒レベルのキャッシュ層も追加できます。オンデマンドモードとプロビジョンドモードの2つのキャパシティモードがあり、トラフィックパターンに応じて選択できます。
DynamoDBのインフラはAWSが完全に管理します。3つのアベイラビリティゾーンにまたがってデータが自動的にレプリケーションされるため、高い耐障害性を持つ。グローバルテーブル機能を使えば、複数のAWSリージョン間での自動レプリケーションも可能です。パーティション管理、パッチ適用、バックアップといった運用作業はすべてAWS側で行われます。
Cassandraは、Facebookが開発しApache Software Foundationに寄贈されたワイドカラム型のNoSQLデータベースです。Amazon DynamoのパーティショニングとGoogleのBigTableのデータモデルを組み合わせた設計思想を持つ。CQL（Cassandra Query Language）というSQLに似たクエリ言語を提供しており、RDBMSに慣れたエンジニアでも比較的学習しやすい。
Cassandraの最大の特徴はマスターレスアーキテクチャです。すべてのノードが対等であり、単一障害点が存在しません。コンシステントハッシュによりデータが各ノードに分散され、レプリケーションファクターにより冗長性が確保されます。書き込み性能が非常に高く、リニアにスケールする特性を持つ。
整合性レベルはクエリごとに指定でき、強い整合性から結果整合性まで柔軟に制御可能です。ただし、CAP定理におけるAP型のデータベースであり、ネットワーク分断時には可用性を優先する設計ですことを理解しておく必要があります。
運用負荷の観点では、DynamoDBが圧倒的に楽です。インフラ管理が不要で、スケーリングも自動です。MongoDBはMongoDB Atlasを使えばマネージドで運用できるが、セルフホストの場合はレプリカセットやシャーディングの管理が必要になります。Cassandraはセルフホストが基本で、ノードの追加やリバランスなど運用の知見が求められます。DataStax Astra DBというマネージドサービスもあるが、AWSでのDynamoDBほどのエコシステム統合はありません。
コスト構造は製品ごとに大きく異なります。DynamoDBは読み書きのキャパシティユニットに対する課金であり、アクセスパターンが予測しにくい場合はオンデマンドモードの費用が膨らみやすい。MongoDBとCassandraはセルフホストであればインフラコストのみだが、運用人件費を含めた総コストで比較する必要があります。
開発者の学習コストという観点では、MongoDBが最もとっつきやすい。JSONライクなデータモデルはWebアプリケーション開発者にとって馴染みがあり、ドキュメントやコミュニティも充実しています。DynamoDBはシングルテーブルデザインなどの独自の設計パラダイムに慣れる必要があります。Cassandraはパーティションキーの設計やデータモデリングに独特のアプローチが求められ、RDBMSの考え方をそのまま持ち込むと失敗しやすい。
筆者がこれまで複数のプロジェクトでNoSQLを採用してきました中で、最も重要だと感じているのは「アクセスパターンに基づいた選定」です。データの構造や量ではなく、どのようにデータを読み書きするかが選定の鍵です。頻繁な更新とリッチなクエリが必要ならMongoDB、キーベースの高速アクセスならDynamoDB、大量の書き込みとリニアスケーリングならCassandraというのが、大まかな指針です。
また、NoSQLを選択する前に、本当にRDBMSでは対応できませんのかを冷静に評価することも大切です。PostgreSQLのJSONB型やパーティショニング機能は非常に優秀であり、中途半端なスケールであればRDBMSで十分対応可能なケースも多いです。技術選定は流行ではなく、具体的な要件に基づいて行うべきです。
入会申込
ログイン
