AWS MySQL RDSとAWS DynamoDB [終了]


109

私はMySQLをしばらく使用しており、その構造やSQLクエリなどに慣れています。

現在AWSで新しいシステムを構築していて、私はDynamoDBを見てきました。現在私はそれについて少ししか知りません。

一方が他方より優れていますか?

DynamoDBの利点は何ですか?

MySQLクエリなどからこのフラットスタイルDBへの移行はどうですか?

回答:


67

AWSの説明については、こちらをご覧ください

つまり、主にルックアップクエリがある(結合クエリではない)場合は、DynamoDB(およびその他のNoSQL DB)の方が適しています。大量のデータを処理する必要がある場合、MySQL(およびその他のRDBMS)を使用すると制限されます。

MySQLクエリやデータスキーマを再利用することはできませんが、NoSQLの学習に労力を費やすと、ツールボックスに重要なツールが追加されます。DynamoDBが最も簡単なソリューションを提供している多くの場合があります。


262

本当にDynamoDBとMySQLはリンゴとオレンジです。DynamoDBはNoSQLストレージレイヤーですが、MySQLはリレーショナルストレージに使用されます。アプリケーションの実際のニーズに基づいて、何を使用するかを選択する必要があります。実際、一部のアプリケーションは両方を使用することで十分に機能する場合があります。

たとえば、単一のキーまたはキー/範囲の組み合わせに対して検索できるリレーショナルスキーマ(ツリー構造、スキーマなしのJSON表現など)に適さないデータを保存している場合、DynamoDB(または他のいくつかのNoSQLストア)がおそらく最善の策です。

リレーショナル構造にうまく適合できるデータの明確に定義されたスキーマがあり、さまざまな方法でデータをクエリする柔軟性が必要な場合(もちろん、必要に応じてインデックスを追加する)、RDSがより良いソリューションになる可能性があります。 。

DynamoDBをNoSQLストアとして使用する主な利点は、クラスター化されたデータストアの管理を気にすることなく、必要なレベルで読み取り/書き込みスループットが保証されることです。したがって、アプリケーションで毎秒1000回の読み取り/書き込みが必要な場合は、DynamoDBテーブルをそのレベルのスループットにプロビジョニングするだけでよく、基盤となるインフラストラクチャについて心配する必要はありません。

RDSには、インフラストラクチャ自体を気にする必要がないという同じ利点がありますが、インスタンスの最大サイズが維持できなくなるところまで大量の書き込みを行う必要が生じた場合、オプション(リードレプリカを使用して、読み取り用に水平方向にスケーリングできます)。

更新されたメモ:DynamoDbはグローバルセカンダリインデックスをサポートするようになったため、ハッシュまたはハッシュと範囲キーの組み合わせ以外のデータフィールドに対して最適化されたルックアップを実行する機能が利用できるようになりました。


10
あなたの答えを100票上げることができれば、そうします。
サリル

情報モデルのある種の問題は、NoSQLのような実装によく似ています。このような問題に出くわしたときは、NoSQLデータベースを使用することが理にかなっているかどうかを自問してください。これらの事業体のいくつかは以下のとおりです。ログ、時系列データ、ソーシャルネットワーク、コンテンツ管理、製品カタログなど
user398039

150

すべてのDynamoDBテーブルをRDS MySQLに移行しました。

特定のタスクにDynamoDBを使用することは理にかなっているかもしれませんが、DynamoDBの上に新しいシステムを構築することは本当に悪い考えです。最善の計画など、常にDBからの追加の柔軟性が必要です。

DynamoDBから移行した理由は次のとおりです。

  1. インデックス作成-新しいテーブルを作成しないと、オンザフライでキーを変更または追加できません。
  2. クエリ-データのクエリは非常に制限されています。特に、インデックス付けされていないデータをクエリしたい場合。もちろん結合は不可能であるため、コード/キャッシュレイヤーで複雑なデータ関係を管理する必要があります。
  3. バックアップ-このような退屈なバックアップ手順は、RDSの滑らかなバックアップと比較して、残念な驚きです。
  4. GUI-悪いUX、限定された検索、おもしろくない。
  5. 速度-応答時間は、RDSと比較して問題があります。RDSの内部キャッシングで解決した場所でそれを補うために、精巧なキャッシングメカニズムを構築していることがわかります。
  6. データの整合性-流動的なデータ構造の概念はそもそもいいように聞こえますが、一部のデータは「堅固なもの」になっています。小さなバグがデータベースを破壊しようとするとき、強い型付けは祝福です。DynamoDBを使用すると、何でも可能であり、実際に問題が発生する可能性があります。

現在、一部のシステムのバックアップとしてDynamoDBを使用しており、特定の明確に定義されたタスクで将来使用することになると確信しています。これは悪いDBではなく、コアシステムの100%を提供するDBではありません。

利点に関して言えば、スケーラビリティと耐久性です。それは信じられないほど透過的にスケーリングし、常に(ある程度)アップしています。これらは本当に素晴らしい機能ですが、欠点を補うものではありません。


11
非常に具体的な長所/短所。すばらしい答え
stevendesu

10
これの一部は古くなっています。たとえば、1は真ではなくなります。
mbroshi 16

2
非常によく文書化された答え。ただし、これらの懸念の一部は、まれなユースケースに固有のものである場合があります。番号2-「結合はもちろん不可能」-DynamoDBデータ構造には関係があってはなりません-期間。テーブルは完全に非正規化する必要があります。つまり、一部の属性が複製されます。このような場合は、ダイナモトリガーまたは条件付き書き込みを使用します。ユーザーが条件付き書き込みのレイテンシを処理できない場合は、アプリケーションとダイナモの間にSQSキューを配置します。さらに、ポイント番号6は、DynamoDBの「整合性」に疑問を投げかけるポイントに誤って名前が付けられています
doles

1
Dynamoはクエリ中に柔軟性を欠いています。GSIは非常に役立ちますが、それでもRDBMSスキーマを使用してデータをより適切にモデル化できます。
パヴァン

1
DynamoDB内のクエリ機能にはいくつかの「落とし穴」があることを付け加えます。たとえば、主キーがハッシュのみで構成されている場合、Dynamoクエリは1つのエントリのみを返すことができます。クエリ時にハッシュのみのキーに範囲を指定することはできません。また、特定のハッシュを知らずにクエリすることもできません。あなたが探しているアイテム。BatchGetは、リクエスト内の100件の取得、1MBの合計応答サイズまたは1MBの合計クエリサイズのいずれか早い方を受け入れます。スキャンは柔軟な検索を提供しますが、非常に非効率的でコストがかかり、フィルタリングする前にテーブル全体を返します。
ブルックス

12

DynamoDBを使用する場合は、DynamoDBのアイテム/レコードが400KBに制限されていることも知っておく必要があります(DynamoDBの制限を参照)。多くのユースケースではこれは機能しません。したがって、DynamoDBは、すべてではなく、いくつかの点で優れています。同じことが他の多くのNoSQLデータベースにも当てはまります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.