回答:
AWSの説明については、こちらをご覧ください。
つまり、主にルックアップクエリがある(結合クエリではない)場合は、DynamoDB(およびその他のNoSQL DB)の方が適しています。大量のデータを処理する必要がある場合、MySQL(およびその他のRDBMS)を使用すると制限されます。
MySQLクエリやデータスキーマを再利用することはできませんが、NoSQLの学習に労力を費やすと、ツールボックスに重要なツールが追加されます。DynamoDBが最も簡単なソリューションを提供している多くの場合があります。
本当にDynamoDBとMySQLはリンゴとオレンジです。DynamoDBはNoSQLストレージレイヤーですが、MySQLはリレーショナルストレージに使用されます。アプリケーションの実際のニーズに基づいて、何を使用するかを選択する必要があります。実際、一部のアプリケーションは両方を使用することで十分に機能する場合があります。
たとえば、単一のキーまたはキー/範囲の組み合わせに対して検索できるリレーショナルスキーマ(ツリー構造、スキーマなしのJSON表現など)に適さないデータを保存している場合、DynamoDB(または他のいくつかのNoSQLストア)がおそらく最善の策です。
リレーショナル構造にうまく適合できるデータの明確に定義されたスキーマがあり、さまざまな方法でデータをクエリする柔軟性が必要な場合(もちろん、必要に応じてインデックスを追加する)、RDSがより良いソリューションになる可能性があります。 。
DynamoDBをNoSQLストアとして使用する主な利点は、クラスター化されたデータストアの管理を気にすることなく、必要なレベルで読み取り/書き込みスループットが保証されることです。したがって、アプリケーションで毎秒1000回の読み取り/書き込みが必要な場合は、DynamoDBテーブルをそのレベルのスループットにプロビジョニングするだけでよく、基盤となるインフラストラクチャについて心配する必要はありません。
RDSには、インフラストラクチャ自体を気にする必要がないという同じ利点がありますが、インスタンスの最大サイズが維持できなくなるところまで大量の書き込みを行う必要が生じた場合、オプション(リードレプリカを使用して、読み取り用に水平方向にスケーリングできます)。
更新されたメモ:DynamoDbはグローバルセカンダリインデックスをサポートするようになったため、ハッシュまたはハッシュと範囲キーの組み合わせ以外のデータフィールドに対して最適化されたルックアップを実行する機能が利用できるようになりました。
すべてのDynamoDBテーブルをRDS MySQLに移行しました。
特定のタスクにDynamoDBを使用することは理にかなっているかもしれませんが、DynamoDBの上に新しいシステムを構築することは本当に悪い考えです。最善の計画など、常にDBからの追加の柔軟性が必要です。
DynamoDBから移行した理由は次のとおりです。
現在、一部のシステムのバックアップとしてDynamoDBを使用しており、特定の明確に定義されたタスクで将来使用することになると確信しています。これは悪いDBではなく、コアシステムの100%を提供するDBではありません。
利点に関して言えば、スケーラビリティと耐久性です。それは信じられないほど透過的にスケーリングし、常に(ある程度)アップしています。これらは本当に素晴らしい機能ですが、欠点を補うものではありません。
DynamoDBを使用する場合は、DynamoDBのアイテム/レコードが400KBに制限されていることも知っておく必要があります(DynamoDBの制限を参照)。多くのユースケースではこれは機能しません。したがって、DynamoDBは、すべてではなく、いくつかの点で優れています。同じことが他の多くのNoSQLデータベースにも当てはまります。