DynamoDBとMongoDB NoSQL [終了]

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

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

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

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

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

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

DynamoDBよりMongoDBを使用する必要がある7つの理由

MongoDBよりDynamoDBを使用する必要がある3つの理由

これは古いことはわかっていますが、比較を検索するとまだ表示されます。私たちはモンゴを使用しており、ほぼ完全にダイナモに移行しました。これが現在私たちの最初の選択肢です。より多くの機能があるからではなく、そうではありません。Mongoにはより優れたクエリ言語があり、構造内でインデックスを作成できます。小さなことはたくさんあります。Dynamoの優位性は、OPが彼のコメントで述べたことにあります。それは簡単です。サーバーの世話をする必要はありません。Mongoシャードソリューションの設定を開始すると、複雑になります。ホスティング会社に行くこともできますが、それも安くはありません。Dynamoでは、より多くのスループットが必要な場合は、ボタンをクリックするだけです。自動的にスケーリングするスクリプトを作成できます。Dynamoをアップグレードするときは、あなたのために行われます。それはすべての貴重なストレスと費やされていない時間です。もしそうなら

したがって、デフォルトでDynamoを使用します。Mongoは、おそらくデータ構造が十分に複雑でそれを正当化できるのであれば、おそらくSQLデータベースに戻るでしょう。Dynamoは鈍感であり、それをどのように構築するかを考える必要があります。おそらく、ElasticcacheでRedisを使用して、複雑なもので機能させることができます。しかし、それを処理する必要がないのは確かに良いことです。あなたがコーディングします。それでおしまい。

50万件のドキュメントがあれば、スケールする理由はありません。SSDと8 GBのRAMを備えた一般的なラップトップは、数千万件のレコードを簡単に作成できるため、スケーリングのために選択しようとしても、選択は重要ではありません。私はあなたがあなたが最も好きなもの、そしておそらくあなたが最もオンラインでのサポートを見つけることができる場所を選ぶことをお勧めします。

概要をすばやく比較するために、私はこのウェブサイトが本当に好きです。たとえば、AWS DynamoDBとMongoDBのように、多くの比較ページがあります。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値のスコープ。たとえば、クエリを発行した場合
または、制限値が6でフィルターなしのスキャン要求
式では、操作は最初の6つのアイテムを返します 
リクエストパラメータと一致するテーブル。あなたも提供する場合
FilterExpression、操作は内の項目を返します 
フィルター要件に一致する表の最初の6項目。

私の結論は、FilterExpressionsを含むクエリはごくまれにしか使用できず、スケーラブルではないということです。各クエリは、DynamoDB読み取りユニットを大量に消費するテーブルのほとんどまたはすべてを簡単に読み取ることができるためです。使用する読み取りユニットが多すぎると、スロットルが発生し、パフォーマンスが低下します。

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

私たちはヘルスケア製品にモンゴ/ダイナモの組み合わせを選びました。基本的にmongoはより良い検索を可能にしますが、ホストされたDynamoは素晴らしいです。追加作業なしでHIPAAに準拠しているからです。そのため、標準設定ではmongo部分を個人データなしでホストし、amazonがインフラストラクチャの観点からHIPAA部分を処理できるようにします。関連するDynamoドキュメントのポインタ（ID）を含むドキュメントを表示するmongoから特定のアイテムをクエリできます。

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

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

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

私は両方と両方のファンの仕事をしました。

しかし、いつ、何のために何を使用するかを理解する必要があります。

すべてのデータベースをDynamoDBに移動するのは良い考えではないと思います。プライマリキーとセカンダリキーを除いてクエリが難しいため、インデックス作成が制限されており、DynamoDBでのスキャンは苦痛です。

私はハイブリッドな種類のDBを選びます。拡張可能なクエリや変更可能なデータがMongoDBにあり、拡張や変更を提供するために制約を受けると感じることのないすべての機能があります。

DynamoDBは非常に高速（MongoDBより高速）であるため、DynamoDBは、スケーラブルなアプリケーションでのセッションの代替としてよく使用されます。DynamoDBのベストプラクティスでは、使用率の低いデータが大量にある場合は、他のテーブルに移動することを推奨しています。

記事やフィードがあるとします。人々は先週のものや今月のものを探す可能性が高くなります。2年前のデータを訪問する機会は本当にまれです。これらの目的のために、DynamoDBは、月または年ごとに異なるテーブルにデータを格納することを好みます。

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

DynamoDBは、速度が重要な場合に使用する必要があります。一方、MongoDBには手や機能が多すぎるため、DynamoDBにはありません。

たとえば、MongoDBのレプリカセットを作成して、レプリカの1つが8時間前のデータインスタンスを保持するようにすることができます。DBで大きな時間をめちゃくちゃにして、以前のようにデータを取得したい場合は、本当に便利です。

それは私の意見ですが。

覚えておいてください、私はMongoDBで実験しただけです...

私が読んだことから、DynamoDBは機能の点で長い道のりを歩んできました。以前は、非常に限られたストレージとクエリ機能を備えた超基本的なKey-Valueストアでした。それから成長し、より大きなドキュメントサイズ+ JSONサポートおよびグローバルセカンダリインデックスをサポートするようになりました。DynamoDBとMongoDBの機能の違いは、月ごとに小さくなります。DynamoDBの新機能はここで拡張されます。

最近のDynamoDB機能の追加により、MongoDBとDynamoDBの比較の大部分は古くなっています。ただし、この投稿は、DynamoDBを選択するためのいくつかの他の説得力のあるポイントを提供します。データベースの選択に関するここでの別の議論は、少し古いですが、読むのは面白かったです。

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