DynamoDBとMongoDBのNoSQL
私は将来のプロジェクトに何を使うことができるのかを解明しようとしています。最初の年には月に50万件のレコードを保存する予定です。このため、データベース、私はnoSQLデータストレージを選択することを決めた理由です。
私の頭に浮かんだ最初の選択肢はmongo dbだったので、コミュニティから多くの支持を得ている非常に成熟した製品ですが、その一方で私たちは最高のパフォーマンスでマネージドサービスを提供する真新しい製品を手に入れました。アプリケーションはありますが（少なくとも現在のところ）メンテナンス計画はありません。Amazonが柔軟に拡張する方法を提供しているので、私はそれが大きな利点になると思います。
私の主な関心事は、クエリ構造についてです。私はまだdynamoDBクエリ機能を見ていませんが、k/vデータストレージであるため、これはmongo dbよりも制限される可能性があると思います。
誰かがmongoDBからDynamoDBにプロジェクトを移行した経験がある場合は、どんなアドバイスでも完全に評価されます。
私は最近自分のMongoDBをDynamoDBに移行し、3つのブログを書いてパフォーマンスとコストに関する経験とデータを共有しました。
MongoDBからAWS DynamoDB + SimpleDBへの移行
私はこれが古くなっているのを知っています、しかし、あなたが比較を探すとき、それはまだ出てきます。私たちはMongoを使用していましたが、ほぼ完全にDynamoに移行しました。これが現在の最初の選択肢です。より多くの機能があるからではなく、そうではありません。 Mongoはより良い問い合わせ言語を持っています、あなたは構造の中で索引をつけることができます、ささいなことがたくさんあります。 Dynamoの優位性は、OPが彼のコメントで述べたことにあります。それは簡単です。あなたはどんなサーバーの世話をする必要はありません。あなたがMongoの分割ソリューションを設定し始めると、それは複雑になります。あなたはいずれかのホスティング会社に行くことができますが、それはどちらも安くはありません。 Dynamoでは、もっとスループットが必要な場合は、ボタンをクリックするだけです。あなたは自動的にスケールするスクリプトを書くことができます。 Dynamoをアップグレードする時が来たとき、それはあなたのために終わりました。それはすべて多くの貴重なストレスと費やされていない時間です。あなたが熱心なopsの人々を持っていないなら、Dynamoは優秀です。
そのため、デフォルトでDynamoを使用しています。 Mongoさん、もしデータ構造がそれを正当化するのに十分に複雑であれば、おそらくSQLデータベースに戻るでしょう。 Dynamoは曖昧です、あなたはそれをどのように構築しようとしているのかを本当に考える必要があります、そしておそらくElasticcacheでRedisを使ってそれを複雑なもののために機能させるでしょう。しかし、世話をする必要がないのは確かにいいことです。あなたがコーディングします。それでおしまい。
500kの文書では、まったく拡大縮小する理由はありません。 SSDと8GBのRAMを搭載した一般的なラップトップは、数千万のレコードを簡単に処理することができます。私はあなたがあなたが最も好きなものを選ぶことをお勧めします、そしておそらくあなたがで最もオンラインサポートを見つけることができる場所。
概要を簡単に比較するために、私はこのウェブサイトがとても好きです。 http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB
簡単な答え：SQLから始めて、必要なときにだけNoSQLを追加してください。 （非常に単純なクエリ以外に必要なものがない限り）
私の個人的な経験：クエリにMongoDBを使用したことはありませんが、2015年4月現在、DynamoDBは最も基本的なキー/値クエリ以外のものになるとまだ非常に不自由です。私は基本的なことが大好きですが、クエリ言語が必要な場合は、実際のSQLデータベースソリューションを検討してください。
DynamoDBでは、ハッシュまたはハッシュと範囲キーに対してクエリを実行できます。また、複数のセカンダリグローバルインデックスを使用できます。私は、4つの可能なフィルタパラメータを持つ単一のテーブルに対してクエリを実行し、結果をソートしています。これは、フィルタ式でグローバル副次索引を使用することによって（やや）サポートされています。問題は、フィルタに一致する合計結果を取得しようとしたときに発生します。フィルタに一致する最初の10項目を検索することはできませんが、10項目がチェックされ、有効な結果が0になります。継続キーからスキャンする - 首が痛くなり、単純なシナリオではテーブル読み取りクォータを大量に消費します。
クエリ内のフィルタに関する制限の問題について詳しくは、ドキュメント（ http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ）を参照してください。 ：
応答として、DynamoDBは Limit値の範囲内のすべての一致結果を返します。たとえば、Limit値が6でフィルタ 式なしでQuery またはScan要求を発行した場合、この操作は テーブル内の最初の6項目を返します。リクエストパラメータを一致させます。 FilterExpressionも指定した場合、操作はフィルタ要件に一致するテーブル内の の最初の6項目内の項目を返します。
私の結論は、FilterExpressionsを含むクエリはごくまれにしか使用できず、スケーラブルではないということです。各クエリはテーブルの大部分または全部を簡単に読み取ることができ、非常に多くのDynamoDB読み取りユニットを消費します。使用する読み取りユニットが多すぎると、調整されてパフォーマンスが低下します。
専門家の意見：2015年4月9日のAWSサミットで、AWSのSolutions ArchitectureのマネージャであるBrett Hollmanが、最初の1000万人のユーザーへの問い合わせについて、SQLデータベースから始めて、意味がある場合にのみNoSQLを使用するよう主張しました。遅かれ早かれ、おそらくスタックのどこかにSQLサーバーが必要になるでしょう。彼のスライドはこちらです。 http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users スライド28を参照してください。
私達はヘルスケアプロダクトのためにMongo/Dynamoの組み合わせを選びました。基本的にmongoはより良い検索を可能にしますが、HIPAAは追加の作業なしで準拠しているので、ホストされているDynamoは素晴らしいです。そのため、標準設定で個人データなしでmongo部分をホストし、Amazonがインフラストラクチャの観点からHIPAA部分を処理できるようにします。関連するDynamoドキュメントのポインタ（ID）を持つドキュメントを表示する、mongoからの特定のアイテムを問い合わせることができます。
アプリケーション全体をdynamoでホストするのではなく、mongoを使用してこれを選択した主な理由は、2つの理由です。まず、mongoが優れていた当時はDynamoが優れていなかった場所ベースの検索を実行する必要がありましたが、現在は選択肢があります。
次に、一部のドキュメントは構造化されておらず、データが何であるかが事前にわからないため、たとえば、ユーザーaが次のように "form"コレクションでドキュメントを入力するとします。{"username"： "user1"、 "電子メール "：" [email protected] "}。そして別のユーザーがこれを同じコレクション{"phone"： "813-555-3333"、 "location"：[28.1234、-83.2342]}に入れます。 mongoを使えば、いつでもこれらの動的なフィールドや未知のフィールドを検索することができます。Dynamoを使用するとこれを実行できますが、検索可能な新しいフィールドが追加されるたびにインデックスを作成する必要があります。あなたのDynamoドキュメントにこれまでに電話フィールドがあったことがなく、その後突然突然その電話フィールドが追加された場合、完全に検索不能になることもあります。
今、これはあなたが言及したもう一つのポイントをもたらします。仕事に適したソリューションを選択することが、仕事に最適な製品を選択することを必ずしも意味するとは限りません。たとえば、作成したシステムを10年以上必要とし、使用する予定のクライアントがあるとします。仕事を終わらせるのに十分なSaaS/IaaSソリューションを使用することは、システムを長期にわたって維持し維持するためにAmazonに頼ることができるので、より良い選択肢かもしれません。
私は両方と両方のファンの種類に取り組んできました。
しかし、何をどの目的で使用するのかを理解する必要があります。
データベースをすべてDynamoDBに移動することはお勧めできません。クエリを実行するのが主キーと副キーを除いて難しいため、インデックス作成が制限され、DynamoDBでのスキャンが面倒です。
私は、広範囲のクエリ可能なデータがあるはずのハイブリッドな種類のDBを選びます。MongoDBは、そのすべての機能を備えているため、機能強化や変更を行うことに制約を受けることは決してありません。
DynamoDBは超高速（MongoDBより高速）なので、DynamoDBはスケーラブルアプリケーションのセッションの代替としてよく使用されます。 DynamoDBのベストプラクティスは、あまり使用されていないデータがたくさんある場合は、それを他のテーブルに移動することをお勧めします。
あなたが記事やフィードを持っているとしましょう。人々は先週のものや今月のものを探す傾向があります。 2年前のデータにアクセスする可能性はほとんどありません。これらの目的のために、DynamoDBは月ごとまたは年ごとに異なるテーブルにデータを保存することを好みます。
DynamoDBは一見したところスケーラブルなので、MongoDBで手動で実行する必要があります。ただし、スループットの分割と、その裏でスケーリングがどのように機能するかについて理解していないと、DynamoDBのパフォーマンスが低下します。
DynamoDBはスピードが重要な場合に使用する必要があります。一方、MongoDBには手と機能が多すぎるため、DynamoDBにはありません。
たとえば、レプリカの1つに8（または何でも）時間前のデータインスタンスが保持されるように、MongoDBのレプリカセットを作成できます。あなたがあなたのDBの中で何か大きな時間をめちゃくちゃにして、それが以前のようにデータを取得したいなら、本当に役に立ちます。
それは私の意見です。
心に留めておいて、私はMongoDBで実験しただけです...
私が読んだものから、DynamoDBは機能の面で長い道のりを歩んできました。非常に限られたストレージとクエリ機能を備えた超基本的なキーバリューストアでした。それはそれ以来成長し、現在 より大きな文書サイズ+ JSONサポート そして グローバルセカンダリインデックス をサポートしています。 DynamoDBとMongoDBが提供する機能の差は、月ごとに小さくなっています。 DynamoDBの新機能は ここ に拡張されています。
最近のDynamoDB機能の追加により、MongoDBとDynamoDBの比較の多くは古くなっています。しかし、 この投稿 はDynamoDBを選択するためのその他の説得力のあるポイントをいくつか提供しています。つまり、シンプルで、メンテナンスが簡単で、多くの場合、低コストです。 ここでもう1つ議論する データベースの選択肢については、やや古くても読むのがおもしろかったです。
私のテイクアウト：あなたが深刻なデータベースクエリをしているか、DynamoDBでサポートされていない言語で作業しているなら、MongoDBを使用してください。それ以外の場合は、DynamoDBを使用してください。