DynamoDBとMongoDBの5つの重要な違いは以下の通りです。

  • MongoDBはベンダーに依存しないオープンソースで、どこにでもデプロイできます。DynamoDBはAWS上でしか利用できません。
  • DynamoDBはフルマネージドなAWSサービスですが、MongoDBはセルフインストールもしくは、MongoDB Atlasを使ったフルマネージドも利用可能です。
  • DynamoDBを統合されたAWSサービスとして利用することで、エンドツーエンドのソリューション開発が容易になります。
  • DynamoDBはテーブル、アイテム、アトリビュートを使用しますが、MongoDBはJSONライクなドキュメントを使用します。
  • DynamoDBは限られたデータ型と小さいアイテムサイズをサポートしていますが、MongoDBはより多くのデータ型をサポートしており、サイズの制限が少ないのが特徴です。

MongoDB vs DynamoDB: どちらを選べば良いでしょうか?PoCを開始する少数チームの場合でも、高スループットと高負荷に立ち向かうしっかりしたチームでも、この記事はあなたの意思決定プロセスの指針となります。詳細に入る前に、これらのテクノロジーがどのようにして登場したのかについての簡単な歴史のレッスンが必要です。 この記事は、お客様の意思決定プロセスの道標としてご利用いただけます。詳細に入る前に、これらのテクノロジーがどのようにして登場したのかについての簡単な歴史のレッスンが必要です。

Table of Contents:

  1. NoSQLの登場
  2. CAP定理
  3. NewSQL
  4. DynamoDB vs MongoDB: 6 Critical Differences
  5. AWSの統合における注意
  6. 最後に

NoSQLの登場

ビッグデータの時代が来る前は、リレーショナルデータベース管理システム(RDBMS)の独壇場でした。リレーショナルモデルは、本質的に構造化されたデータ上で動作する従来のクライアント・サーバー型のビジネスアプリケーションと相性の良い仕組みです。古典的なリレーショナルデータベースは、ACIDプロパティに従います。つまり、データベースのトランザクションは、Atomic、Consistent、Isolated、Durableでなければなりません。一言で言えば、これは一貫性を保証するもので、データを変更するたびに、データベースはある一貫した状態から別の一貫した状態に移行します。

しかし、これらのシステムの多くは、大量の非構造化データをコスト効率よくスケーリングすることができず、エンジニアリングチームは代替案を探し始めました。NoSQL(「SQLだけではない」)は、MapReduceやBigtable、Cassandra、MongoDB、DynamoDBなどの製品により注目され出しました。NoSQLの本当の利点は水平スケーリング(または「シャーディング」)であり、リソースのプールにより多くのマシンを追加してスケーリングすることを意味します。たとえば、各行は独立して保存され、クラスタ内のノード間で均等に分散することができます。これは、ノードやインスタンスの数を増やすのではなく、単一のインスタンスやノードのサイズと計算能力を増加させる垂直スケーリングとは対照的です。

Related Reading: NoSQL vs SQL

CAP定理

2000年、エリック・ブリュワー博士は、"Towards Robust Distributed Systems" "と呼ばれる分散コンピューティングの原則会議で基調講演を行いました。ここで彼はCAP定理を提唱しました。これは、分散型(つまりスケーラブル)システムでは、一貫性、可用性、パーティション許容度を同時に保証することはできないというものです。

  • AP: 利用可能性(A)が高く、パーティション耐性(P)があるが、一貫性(C)がない。
  • CP: 一貫性(C)があり、パーティション耐性(P)があるが、利用可能性(A)は高くない。
  • CA: 利用可能性(A)が高く、一貫性(C)があるが、パーティション耐性(P)がない。

RDBMSシステムは主にCAシステムとしての特徴を持っています。パーティションの許容範囲がないため、通常はシングルノードとして実装され、結果として高価な垂直スケーリングになってしまいます。

NoSQL分散データベースが一貫性よりも可用性を選択した場合(それはAPシステムである)、ACIDトランザクションを提供することは不可能です。その代わりに、このようなシステムは通常、トランザクションの信頼性を弱めるBASE(Basically Available, Soft state, Eventual consistency)と呼ばれるプロパティのセットを提供します。

イェール大学のDaniel J. Abadi氏は「Consistency Tradeoffs in Modern Distributed Database System Design」という論文を書き、CAPの欠点のいくつかを概説しました。PACELC定理は、パーティショニングがない場合(すなわち、ネットワークが健全な場合)のシナリオを探っています。頭字語は、ネットワークのパーティショニング(P)に悩まされた場合、可用性(A)と一貫性(C)のどちらかを選択しなければならず、そうでない場合(E)は、遅延(L)と一貫性(C)のどちらかを選択しなければならないことを意味します。PACはCAPの下位概念であり、ELCはその拡張です。

NewSQL

NewSQLリレーショナルデータベース管理システム(DBMS)の出現に関して言及しておく必要があるでしょう。これは、トランザクションにRDBMSレベルのACIDコンプライアンスを与えながら、OLTP(オンライントランザクション処理)のためにNoSQLシステムの弾力的なスケーラビリティとパフォーマンスを一致させることを目的としています。VoltDBは良い例で、強力な一貫性(CP)を提供し、可用性(A)よりも一貫性(C)を選択し、また、パーティション耐性を提供します。

Integrate Your Data Today!

Try Xplenty free for 7 days. No credit card required.

DynamoDB vs MongoDB: 6 Critical Differences

1) フルマネージド

DynamoDBはフルマネージドなソリューションです。フルマネージドサービスを使用することで、チームが運用に費やす時間を削減することができます。(ページャーデューティのアラートがない)、サーバーの更新、カーネルパッチの展開、SSDの交換、ハードウェアのプロビジョニング、セットアップ/設定、スループットのキャパシティプランニング、レプリケーション、ソフトウェアパッチ、クラスタのスケーリングなどが不要です。焦点は、真の価値があるアプリケーション・ロジックに移っていきます。一般的な経験則では、書き込みにはコストがかかり、一貫性のある読み取りには最終的には2倍のコストがかかるため、低スループットのアプリにはDynamoを選択することになります。 MongoDBのAtlasのコストは、インフラの可用性と外部マネージドサービスのバックアップから来ていますが、スループットは価格に含まれています。チームに専任の運用担当者がいない場合は、Dynamoの方が良いでしょう。

2) アウトオブザボックスのセキュリティ

DynamoDBはそのまま使うことができるセキュリティを提供します。セキュリティモデルはIAM(Identity and Access Management)をベースにしており、AWSのサービスやリソースへのアクセスを安全に管理することができます。AWSのユーザーやグループを作成して管理し、権限を使ってAWSリソースへのアクセスを許可・拒否することができます。IAMは実戦テスト済みで、限られた設定だけで直感的かつ協力的であることがわかっています。DynamoDBは直接アドレスを指定しておらず、リクエストはAPIゲートウェイを経由してルーティングされ、AWSはここから権限管理を行うため、オープンインターネットからアクセスすることはできません。MongoDBはセキュアですが、デフォルトの設定ではセキュアではありません。そのまま使うことができるセキュリティを提供していないため、特に侵害に対して脆弱な可能性があります。 

3) 集計

DynamoDBはキー・バリュークエリをサポートしています。集約、グラフトラバース、検索を必要とするクエリの場合は、Elastic MapReduceやRedshiftなどのAWSサービスにデータを投入する必要がありますが、その分、開発者のレイテンシ、コスト、認知負荷が増大します。これはマネージドサービスであるため、インデックスの使用、クエリ構造、データモデル、システム構成(ハードウェアやOSの設定など)、アプリケーションの設計など、特定のデータベース要素をチューニングすることで緩和することはできず、アプリケーションの全体的なパフォーマンスに大きな影響を与える可能性があります。MongoDBのクエリ言語を使えば、開発者はシングルキー、グラフトラバーサル、地理空間クエリ、範囲検索、ファセット検索など、さまざまな方法でデータをクエリして分析することができます。レイテンシは最小限で、必要に応じて最適化やチューニングを目的としたパフォーマンスメトリクスの粒度を、スループットメトリクス、データベースパフォーマンス、リソース利用率、リソース飽和、エラー(アサート)などの深いレベルで取得することができます。

4) ミュータブル(可変)・インデックス

MongoDBは、動的な開発状況に応じてドキュメントの構造を変更できるように、ミュータブルインデックスをサポートしています。バックエンドのコレクションスキーマを更新しなくても、ドキュメントの構造を変えることができます。DynamoDB のインデックスは不変です。新しい名前の新しいテーブルを作成して、古いテーブルを削除したりしなければなりませんが、安全な移行のためにはかなりのリソースがない場合は運用システムでそれを行うのは不可能です。

5) データタイプ

MongoDBと比較すると、DynamoDBは異なるデータタイプのサポートに制限があり、16MBまでのドキュメントサイズをサポートしているMongoDBとは対照的に、アイテムは400KBまでに制限されています。AWSはアイテムのサイズが1KBを超えるとかなり高い運用料金を請求し、より大きなオブジェクトについてS3で管理するよう提案しています。使い方によっては、これが実行可能な場合と不可能な場合があります。S3への書き込みは遅く、高いスループットが得られない場合もあります。Dynamoは1つの数値型しかサポートしておらず、日付型はサポートしていません。 

6) ベンダーロックイン

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(アイデンティティプール)、Elastic Map Reduce(EMR)、Data Pipeline、Kinesis、S3などのサービスとシームレスに統合できます。DynamoはStreams経由でAWS lambdaと緊密に統合されており、アプリケーションの負荷に応じた自動スケーリング、使用量に応じた従量課金、簡単に始められ、管理するサーバーがないというサーバーレスの理念に沿っています。 

DynamoDB vs MongoDB Trends

最後に

すべてに当てはまる適切なサイズはなく、運用されているすべてのシステムには独自のニーズやクセがあります。次の質問は、どれを選択すべきかという決断を固めてくれる回答を導いてくれるはずです。

あなたのチームは、手動での介入なしに常に高い可用性が必要なミッションクリティカルなアプリケーションを展開していますか?

あなたのチームは、プロプライエタリなソフトウェアの上で、制御もなく、何が起こっているのかもわからない状態で、快適に動作していますか?

どのデータベースシステムを選択したとしても、データの移行は深刻な問題を引き起こす可能性があります。もしあなたがデータ移行のボトルネックに悩んでいるなら、Xplentyの自動ETLプラットフォームが助けてくれます。Xplentyは、データ移行を簡単にするビジュアルでノーコードのインターフェースを提供します。何百ものすぐに使える統合機能をチェックするか、デモを予約して、XplentyがあなたのユニークなETLの課題にどのように役立つかを確認してください。

製品のデモに興味のある方は、以下のサイトより申し込みください。(予約サイトは英語ですが、日本語でデモします)

Xplentyのデモ紹介に登録して、無料でプラットフォームを試してみよう!

また、トライアルを試してみたい方は、以下のサイトよりお申し込みください。

Xplentyを無料で試してみよう!