目次

MongoDB と DynamoDB はどちらを選ぶべきでしょうか。

２人組のチームがコンセプトの実証実験を始めるにせよ、既存のチームが高いスループットと重い負荷に立ち向かうにせよ、本記事は、みなさんの意思決定プロセスの道しるべとなることでしょう。

その前に、この両技術がどのように誕生したのか、簡単に歴史を振り返っておきましょう； このシステムを動かすための最適な条件と、実際の運用方法をきちんと理解した上で、どちらか選ばないといけませんからね。

Integrate.io のネイティブ MongoDB コネクタの詳細については、Integrate のページをぜひご覧ください。

NoSQLの登場

ビッグデータの時代以前は、RDBMS（リレーショナルデータベース管理システム）の天下でした。リレーショナルモデルは、構造化されたデータを本質的に操作する従来のクライアント・サーバー型ビジネスアプリケーションと相性が良く、従来のリレーショナル・データベースは、ACIDの性質に従います。つまり、データベーストランザクションは、ACID（Atomic, Consistent, Isolated, and Durable）でないといけません。一言で言えば、これは一貫性を保証するもので、データに対する変更はどれも、データベースをある一貫性のある状態から別の一貫性のある状態に移行させるということです。

しかし、そのシステムの多くは、大量の非構造化データに対してコスト効率よく拡張することができず、そこでエンジニアリングチームは代替案を探し始め、MapReduce や Bigtable、Cassandra、MongoDB、DynamoDB といった NoSQL（「Not Only SQL」）が登場しました。

NoSQL の本当の利点は、水平方向のスケーリング（または「シャーディング」）です。つまり、リソースのプールにさらにマシンを追加することでスケーリングするということです。例えば、各行が独立して保存されるため、クラスタ内のノード間で均等に分配することができます。これは、ノードやインスタンスの数を増やすことなく、単独のインスタンスやノードのサイズや計算能力を上げることができる「垂直方向のスケーリング」とは対照的です。

CAP 定理

２０００年に開催された Principles of Distributed Computin（分散型コンピューティングの原理）で、エリック・ブリュワー博士が「Towards Robust Distributed Systems（強固な分散型システムへ向けて）」と題する基調講演を行いました。ここで彼は、「分散型（スケーラブル）システムは、一貫性（ Consistency）、可用性（Availability）、分断耐性（Partition Tolerance）を一体として保証することはできず、３つのうち２つしか保証されない」というCAP定理を提起しました：

  • AP： 可用性が高く分断耐性があるが、一貫性がない。
  • CP：一貫性があり、分断耐性があるが、可用性が高くない。
  • CA：可用性が高く一貫性があるが、分断耐性がない。

RDBMS システム（リレーショナルデータベース管理システム）は主に CA システムとして特徴づけられています。分断耐性がないため、通常単独ノードとして実装され、結果として高価な垂直スケーリングとなります。

NoSQL 分散データベースが一貫性よりも可用性を重視する（APシステムである）場合、ACIDトランザクションを提供することはできません。その代わりに、このようなシステムは通常、トランザクションに対して弱い信頼性を提供するもの『BASE（Basically Available、Soft state、Eventual consistency）』と呼ばれる一連の特性を提供します。

イエール大学のダニエル・J・アバディ氏は、「Consistency Tradeoffs in Modern Distributed Database System Design（最新の分散データベースシステム設計における一貫性のトレードオフ）」という論文を書き、CAPの欠点をいくつか概説しています。PACELC定理は、分断がない場合（すなわち、ネットワークが健全な場合）のシナリオを探るものであり、この頭字語は、ネットワークの分断（Partitioning）に悩まされた場合、可用性（Availability）か一貫性（Consistency）のどちらかを選択しなければならず、そうでない場合（Else）は、遅延（Latency）か一貫性（Consistency）のどちらかを選択しなければならないということです。PAC は CAP の下位互換で、ELC はその延長線上にあります。

NewSQL

NewSQL の DBMS（リレーショナルデータベース管理システム）の出現は要チェックです。このような DBMS は、OLTP（オンライントランザクション処理）において NoSQL システムの弾性的なスケーラビリティとパフォーマンスに匹敵することを目指す一方で、トランザクションにおいて RDBMS レベルの ACID コンプライアンスを提供します。VoltDB は良い例で、強い一貫性（CP）を提供し、可用性（A）よりも一貫性（C）を選択し、分断耐性も提供します。

DynamoDB と MongoDB: 7つの決定的な違い

１．フルマネージド

DynamoDB は、フルマネージドソリューションです。フルマネージドサービスを利用することで、運用に費やす時間を削減することができます。（PagerDuty通知なし）サーバーのアップデート、カーネルパッチの展開、SSDの交換、ハードウェアプロビジョニング、設定/構成、スループット能力計画、レプリケーション、ソフトウェアパッチ、クラスタースケーリングなどが不要であり、本当に価値があるアプリケーション ロジックに焦点が移ります。

一般的な経験則では、書き込みは高価であり、一貫した読み出しは最終的に一貫した読み出しの２倍のコストがかかるため、低スループットのアプリには Dynamo を選びます。MongoDBの Atlas のコストは、外部のマネージドサービスのインフラ可用性とバックアップに由来し、スループットは価格設定に含まれています。チーム内に専任の運用担当者がいない場合は、Dynamoを選択する方がいいでしょう。

２．すぐに使えるセキュリティ

DynamoDB のセキュリティは、IAM（Identity and Access Management）に基づいており、それによって例えば、 AWSのユーザーやグループを作成・管理してAWSリソースへのアクセスを許可・拒否するための権限を使用することができるといったように、 AWS のサービスやリソースへのアクセスの安全な管理ができるようになります。また、IAMは実戦で検証され、直感的で協調性があり、設定も限定的であることが判明しています。

DynamoDB は直接アドレスがなく、リクエストは API ゲートウェイを経由し、AWS はここから認可を管理するため、オープンインターネットからアクセスすることはできなません。MongoDB は安全ですが、デフォルトの構成は安全ではありません。デフォルトのセキュリティは提供されていないため、特に侵害されやすいと言えます。

３．アグリゲーション

DynamoDB は、キーバリュークエリに対応しています。集計、グラフトラバーサル、検索を必要とするクエリでは、EMR（Elastic MapReduce）や Redshift などの AWS の補完的なサービスにデータをさらに投入する必要があり、本質的にデベロッパーのレイテンシ、コスト、認識負荷が上がります。また、これはマネージドサービスのため、インデックス使用、クエリー構造、データモデル、ハードウェアや OS の設定などのシステム構成、アプリケーション設計など、特定のデータベース要素のチューニングによる軽減はできず、それがアプリケーションの全体的なパフォーマンスに大きな影響を与える可能性があります。

MongoDB のクエリ言語では、単独キー、グラフトラバーサル、地理空間クエリ、レンジ、ファセット検索など、さまざまな方法でデータを照会・分析することができます。また、待ち時間が少なく、スループットメトリクス、データベースパフォーマンス、リソース利用率、リソース飽和、エラー（アサート）など、必要に応じて最適化やチューニングのために深いレベルのパフォーマンスのメトリクスの粒度を得ることが可能です。

４．ミュータブルインデックス

MongoDB はミュータブル（変更可能）インデックスに対応しており、動的な開発条件に基づいてドキュメントの構造を変更することができます。また、バックエンドでコレクションスキーマを更新することなく、ドキュメントの構造の変更が可能です。一方、DynamoDB のインデックスは不変であるため、新しい名前で新しいテーブルを作成し、古いテーブルを削除する必要がありますが、これは安全に移行するためのリソースがない本番システムでは不可能です。

５．データの種類

MongoDB と比べると、DynamoDB は異なるデータタイプの対応が限られ、ドキュメントサイズは１６MBまで対応できる MongoDB に対して、アイテムは４０KBに制限されています。AWS では、アイテムのサイズが１KBを超えると運用価格が大幅に高くなり、より大きなオブジェクトを S3 で永続化することを推奨しています。ただ S3 の書き込みは遅い場合があり、高いスループットが得られない可能性があるため、使い方によっては実行できないかもしれません。また、Dynamo は数値型は１つしか対応しておらず、日付は対応していません。

６．スケーラビリティ（拡張性）

MongoDB との通信にはソケット接続が必要で、ユースケースによっては、アプリケーションのパフォーマンスのボトルネックになることがあります。一方、DynamoDB は、HTTPS API エンドポイントという広く使われている方法に依存しています。なので、同時実行モデルとパフォーマンスの予測は、DynamoDB の方がはるかに簡単です。

７．レプリケーション と ディストリビューション

AWS のマネージドサービスである DynamoDB は、マルチAZ および マルチリージョン のデータレプリケーションをすぐに提供します。MongoDB はマルチノードクラスターに対応できますが、セットアップが難しい場合があります。また、Mongo Atlas はプロセスをシンプルにできますが、DynamDB で提供されるようなシンプルさにはまだ欠けます。

両者の決め手

この２つのテクノロジーは、どちらが優れているかということではありません。どちらの技術がいいかということではなく、最終的には、使う人の特定のユースケースに最適な機能を提供できるかということなのです。

トランザクション

バージョン4.0の時点で、Mongo は ACID トランザクションに対応しています。ただし、これは新しい機能であるため、多くのデベロッパーはそのトランザクション機能が他のデータベースより劣っていると感じるかもしれません。なのでトランザクション操作がアプリケーションにとって重要であれば、その分野で豊富な経験を持つ Dynamo 一択でいった方がいいかもしれません。

セキュリティ

MongoDB は、認証なしでデータへの無制限な直接アクセスを許可するデフォルトで実行されることから、デベロッパーは、Mongo のセキュリティを再設定するために、前もって余分に時間をかけないといけなくなるでしょう。一方、Dynamo は、デフォルトで静止時と転送時にデータを暗号化するため、デベロッパーは Dynamo を使い始める際に、それほど多くのセキュリティ設定を行う必要はありません。

速さ

MongoDB はクエリデータを RAM に保存するため、クエリパフォーマンスはDynamo の場合よりも大幅によくなります。つまり、Dynamo よりもクエリパフォーマンスが高いということです。なので、アプリケーションの速度が気になる場合は、MongoDB が最適な選択となるでしょう。

技能レベル

チームには Mongo を実装するスキルがありますか？また、それをサポートし、スムーズに動作するようにできるでしょうか？もしそうでないなら、マネージドソリューションとして Dynamo を利用する方がいいかもしれません。

プログラミング言語

データベースとの連携に柔軟性が必要な場合、MongoDB は C、C#、C++、Clojure、PHP、Perl、PowerShellなど、主要なプログラミング言語にほぼすべて対応しています。一方、DynamoDB は Java、JavaScript、Swift、Node.js、.NET、PHP、Python などのごく一部の言語にしか対応していません。

ベンダーロックイン

DynamoDB を使うと、ベンダーロックインに陥る可能性があります。AWS は独自のデータベースモデルを採用しており、他のクラウドプロバイダーに移行するとなると、新しいデータベースシステムを構築するために多大なリソースが必要となります。さらに、複数の AWS サービスに依存するようになると、マルチクラウド戦略に注力し難くなってきます。

核心的な問題は、技術の変更にかかるコストと、その結果生じるビジネスの中断のリスクです。MongoDB の SSPL（Server Side Public License）のライセンスは、OSI（Open Source Initiative）にはまだ承認されていませんが、FOSS（Free and Open-source software）コミュニティはこれを受け入れています。Fedoraプロジェクトの言葉を借りれば、「ボンネットが開けられず、何が悪いのか直せない、何が起きているのかわからないような車を買いますか？」ということです。

AWSとの統合についての注意点

すでに AWS のエコシステムにかなり投資してしまっている場合は、DynamoDB の方がいい選択となります。Redshift（大規模データ分析）、Cognito（IDプール）、Elastic Map Reduce（EMR）、データパイプライン、Kinesis、S3 などのサービスとのシームレスな統合を実現しますからね。また Dynamoは、Streams を介してAWS lambda と緊密に連携しており、アプリケーションの負荷に応じた自動スケーリング、使った分だけ支払う価格設定、簡単に始められる、管理するサーバーが不要、といったサーバーレス思想に合致しています。

まとめ

生産システムには万能なものはなく、それぞれニーズや癖があります。

以下の質問から、どの生産システムを選ぶべきか、あなたの立場をハッキリさせる答えが見つかるはずです。

  • 手動で操作することなく常に高い可用性が求められるミッションクリティカルなアプリケーションがチームに導入されているか
  • プロプライエタリソフトウェアで、コントロールすることなく、また、中で何が起こっているのか把握することなく、実行することに抵抗はないか

どのデータベースシステムを選んでも、データを移行する際に深刻な問題が発生する可能性があります。データ移行のボトルネックにお悩みなら、Integrate.io の自動 ETL プラットフォームが便利です。Integrate.io は、データ移行がしやすくなる視覚的なノーコードのインターフェースを提供します。

Integrate.io の何百もの統合機能をコチラでご覧いただくか、デモを予約して、Integrate.io が独自の ETL の課題にどのようにお手伝いできるかをぜひご覧ください。