mongodb - DynamoDB と MongoDB NoSQL の比較

Question

将来のプロジェクトで何を使用できるかを理解しようとしています。最初の 1 年間は 1 か月あたり約 50 万件のレコードを保存する予定です。今後数年間はさらに多くのレコードを保存する予定です。これは垂直アプリケーションであるため、これが、noSQL データストレージを選択することにした理由です。

私の頭に浮かんだ最初のオプションは mongo db でした。これは、コミュニティから多くのサポートを受けている非常に成熟した製品ですが、一方で、最高のパフォーマンスでマネージドサービスを提供する新しい製品を手に入れたので、これを開発します。しかし、(少なくとも今のところ) メンテナンスプランはないので、Amazon は柔軟なスケーリング方法を提供するので、これは大きな利点になると思います。

私の主な関心事はクエリ構造に関するものです。dynamoDB クエリ機能はまだ見ていませんが、ak/v データストレージであるため、これは mongo db よりも制限される可能性があると感じています。

プロジェクトを mongoDB から DynamoDB に移行した経験がある場合は、アドバイスをいただければ幸いです。

score 74 · Accepted Answer

最近、MongoDB を DynamoDB に移行し、3 つのブログを書いて、パフォーマンス、コストに関する経験とデータを共有しました。

MongoDB から AWS DynamoDB + SimpleDB に移行する

DynamoDB よりも MongoDB を使用すべき 7 つの理由

MongoDB よりも DynamoDB を使用すべき 3 つの理由

score 64 · Accepted Answer

50 万件のドキュメントがあるため、スケーリングする理由はまったくありません。SSD と 8 GB の RAM を搭載した典型的なラップトップは、何千万ものレコードを簡単に処理できます。最も気に入ったものを選択することをお勧めします。また、オンラインサポートが最も充実している場所を選択することをお勧めします。

score 23 · Accepted Answer

概要を簡単に比較するには、AWS DynamoDB と MongoDB など、比較ページがたくさんあるこのウェブサイトがとても気に入っています。http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

score 18 · Accepted Answer

簡単な答え: SQL から始めて、必要な場合にのみ NoSQL を追加します。（非常に単純なクエリ以外に何も必要ない場合を除きます）

私の個人的な経験: クエリに MongoDB を使用したことはありませんが、2015 年 4 月の時点で、DynamoDB は、最も基本的なキー/値クエリを超えるものに関しては、まだ非常に機能していません。基本的なものは気に入っていますが、クエリ言語が必要な場合は、実際の SQL データベースソリューションを検討してください。

DynamoDB では、ハッシュまたはハッシュと範囲キーでクエリを実行でき、複数のセカンダリグローバルインデックスを持つことができます。4 つの可能なフィルターパラメーターを使用して単一のテーブルに対してクエリを実行し、結果を並べ替えています。これは、フィルター式でグローバルセカンダリインデックスを使用することで (ほとんど) サポートされていません。フィルターに一致する合計結果を取得しようとすると問題が発生します。フィルターに一致する最初の 10 個のアイテムを検索するだけでなく、10 個のアイテムをチェックし、有効な結果が 0 個になる可能性があり、再保持する必要があります。続行キーからのスキャン - 単純なシナリオでは首の痛みとテーブル読み取りクォータの消費が多すぎます。

クエリのフィルターに関する制限の問題について具体的に説明するには、これはドキュメント ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ) からのものです。

応答で、DynamoDB は一致するすべての結果を返します
制限値の範囲。たとえば、クエリを発行すると
または、制限値が 6 でフィルターなしのスキャン要求
式の場合、演算は最初の 6 項目を返します。
リクエスト パラメータに一致するテーブル。また、
FilterExpression、操作は内のアイテムを返します
フィルター要件に一致するテーブル内の最初の 6 つのアイテム。

私の結論は、FilterExpressions を含むクエリは非常にまれな場合にのみ使用可能であり、スケーラブルではありません。これは、各クエリが、非常に多くの DynamoDB 読み取りユニットを消費するテーブルのほとんどまたはすべてを簡単に読み取ることができるためです。使用する読み取りユニットが多すぎると、調整されてパフォーマンスが低下します。

専門家の意見: 2015 年 4 月 9 日の AWS サミットで、AWS のソリューションアーキテクチャ担当マネージャーである Brett Hollman は、最初の 1,000 万ユーザーへのスケーリングに関する講演で、SQL データベースから始めて、理にかなっている場合にのみ NoSQL を使用することを提唱しています。遅かれ早かれ、おそらくスタックのどこかに SQL サーバーが必要になるからです。彼のスライドはこちら: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users スライド 28 を参照してください。

score 14 · Accepted Answer

ヘルスケア製品に Mongo/Dynamo の組み合わせを選択しました。基本的には mongo の方が優れた検索が可能ですが、ホストされている Dynamo は追加の作業なしで HIPAA に準拠しているため優れています。そのため、標準的なセットアップで個人データなしで mongo 部分をホストし、Amazon がインフラストラクチャの観点から HIPAA 部分を処理できるようにします。関連する Dynamo ドキュメントのポインタ (ID) を持つドキュメントを表示する mongo から特定のアイテムをクエリできます。

アプリケーション全体を dynamo でホストするのではなく、mongo を使用してこれを行うことにした主な理由は 2 つあります。まず、mongo が得意とするロケーションベースの検索を実行する必要がありましたが、当時 Dynamo は得意ではありませんでしたが、現在はオプションがあります。

2 つ目は、一部のドキュメントが構造化されておらず、データがどのようなものになるか事前にわからなかったことです。たとえば、ユーザーが「フォーム」コレクションに次のようにドキュメントを入力するとします: {"username": "user1","メール": "me@me.com"}. そして、別のユーザーがこれを同じコレクション {"phone": "813-555-3333", "location": [28.1234,-83.2342]} に入れます。mongo を使用すると、これらの動的で不明なフィールドをいつでも検索できます。Dynamo を使用すると、これを行うことができますが、検索可能にする新しいフィールドが追加されるたびにインデックスを作成する必要があります。そのため、Dynamo ドキュメントに電話番号フィールドがなかった場合、突然誰かが追加してしまい、完全に検索できなくなります。

さて、これはあなたが言及した別のポイントをもたらします。仕事に適したソリューションを選択しても、必ずしも仕事に最適な製品を選択するとは限りません。たとえば、作成したシステムを 10 年以上使用する必要があるクライアントがいるとします。仕事を成し遂げるのに十分なSaaS / IaaSソリューションを使用することは、Amazonに頼ってシステムを長期にわたって維持および維持できるため、より良い選択肢になる可能性があります.

score 12 · Accepted Answer

私は両方に取り組んでおり、どちらのファンでもあります。

ただし、いつ、何を、どのような目的で使用するかを理解する必要があります。

すべてのデータベースを DynamoDB に移行するのは良い考えではないと思います。理由は、プライマリキーとセカンダリキーを除いてクエリが難しく、インデックス作成が制限され、DynamoDB でのスキャンが面倒だからです。

拡張や変更を提供することに制約を感じることのないすべての機能を備えた、クエリ可能な広範なデータが存在する必要があるハイブリッドな種類の DB を選びます。

DynamoDB は超高速 (MongoDB よりも高速) であるため、DynamoDB はスケーラブルなアプリケーションのセッションの代わりとしてよく使用されます。DynamoDB のベストプラクティスでは、あまり使用されていないデータがたくさんある場合は、それを他のテーブルに移動することも提案しています。

記事やフィードがあるとします。人々は先週のものや今月のものを探す可能性が高くなります。人々が 2 年前のデータにアクセスする可能性は非常にまれです。これらの目的のために、DynamoDB は異なるテーブルに月または年ごとにデータを保存することを好みます。

DynamoDB は非常にスケーラブルであり、MongoDB で手動で行う必要があります。ただし、スループットパーティションと、舞台裏でスケーリングがどのように機能するかを理解していないと、DynamoDB のパフォーマンスが低下します。

DynamoDB は速度が重要な場合に使用する必要があります。一方、MongoDB には手と機能が多すぎて、DynamoDB に欠けているものがあります。

たとえば、レプリカの 1 つが 8 時間前 (またはそれ以外) のデータインスタンスを保持するような方法で、MongoDB のレプリカセットを持つことができます。DB で大きな問題が発生し、以前のデータを取得したい場合に、非常に便利です。

それは私の意見ですが。

score 7 · Accepted Answer

覚えておいてください、私はMongoDBでしか実験していません...

私が読んだ限りでは、DynamoDB は機能面で長い道のりを歩んできました。以前は、ストレージとクエリ機能が非常に制限された超基本的なキー値ストアでした。それ以来成長し、現在はより大きなドキュメントサイズ + JSON サポートとグローバルセカンダリインデックスをサポートしています。DynamoDB と MongoDB が提供する機能の差は、月を追うごとに小さくなっています。DynamoDB の新機能は、こちらで拡張されています。

最近 DynamoDB 機能が追加されたため、MongoDB と DynamoDB の比較の多くは古くなっています。ただし、この投稿では、DynamoDB を選択するための他の説得力のあるポイント、つまりシンプルでメンテナンスが少なく、多くの場合低コストであることを示しています。ここでのデータベースの選択に関する別の議論は興味深いものでしたが、少し古いものでした。

私の結論: 重大なデータベースクエリを実行している場合、または DynamoDB でサポートされていない言語で作業している場合は、MongoDB を使用してください。それ以外の場合は、DynamoDB を使用してください。

mongodb - DynamoDB と MongoDB NoSQL の比較

8 に答える 8

Related

Reference