DynamoDBとRDSの違い

結論

DynamoDBは、サーバーレスのNoSQLデータベースです。

RDSは、MySQLやPostgreSQLなどを使えるリレーショナルデータベースのマネージドサービスです。

ざっくり言うと、以下の使い分けです。

このサイトの問い合わせ保存では、DynamoDBを使う想定です。

理由は、保存するデータがシンプルで、複雑なリレーションが不要だからです。

DynamoDBとは

DynamoDBは、AWSのマネージドNoSQLデータベースです。

テーブルを作り、Partition Keyを中心にデータを保存します。

サーバーを自分で管理する必要はありません。

アクセス数に応じてスケールしやすく、Lambdaとの相性もよいです。

RDSとは

RDSは、リレーショナルデータベースをAWSで管理しやすくするサービスです。

代表的なエンジンには、MySQL、PostgreSQL、MariaDB、Oracle、SQL Serverなどがあります。

SQLを使って、テーブル同士をJOINしたり、トランザクションを扱ったりできます。

基本的な違い

どちらを使うべきか

DynamoDBが向いているケース

DynamoDBは、以下のようなケースに向いています。

• 問い合わせフォームの保存
• ユーザー設定の保存
• 回答履歴の保存
• セッション情報の保存
• Keyで取得できるデータ
• アクセスパターンが明確なデータ
• サーバーレス構成にしたい場合

このサイトでは、問い合わせデータを保存するだけなのでDynamoDBで十分です。

RDSが向いているケース

RDSは、以下のようなケースに向いています。

• 複数テーブルをJOINしたい
• SQLで柔軟に検索したい
• トランザクションが重要
• 会計や注文管理のように整合性が重要
• 既存のMySQLやPostgreSQLの知識を使いたい
• 管理画面で複雑な検索をしたい

たとえば、ECサイトの注文、在庫、決済、顧客を細かく結びつけるならRDSが候補になります。

このサイトでDynamoDBを選ぶ理由

このサイトのMVPで保存する動的データは、問い合わせ内容だけです。

保存する項目は以下です。

このデータは、複雑なJOINを必要としません。

まずは「保存できること」が重要です。

そのため、LambdaからDynamoDBへPutItemする構成で始めます。

RDSをMVPで使わない理由

RDSは強力ですが、個人開発MVPでは重くなりがちです。

理由は以下です。

RDSが悪いわけではありません。

今回のMVPには過剰という判断です。

試験で問われるポイント

Cloud Practitionerでは、DynamoDBはNoSQL、RDSはリレーショナルデータベースとして問われます。

SAAでは、可用性、スケール、読み取り性能、Multi-AZ、Read Replica、キー設計などが関係します。

よくある間違い

NoSQLなら何でも速いと思う

DynamoDBは強力ですが、キー設計を間違えると使いづらくなります。

「どう取得するか」を先に考えてテーブルを作る必要があります。

RDSは古いと思う

RDSは今でも重要です。

SQL、JOIN、トランザクションが必要なシステムでは有力な選択肢です。

とりあえずRDSにする

学習初期の個人開発では、RDSが過剰になることがあります。

問い合わせ保存、学習履歴、簡単な設定保存ならDynamoDBで始める判断もあります。

まとめ

DynamoDBとRDSは、どちらが上という話ではありません。

用途が違います。

DynamoDBは、サーバーレス構成でシンプルなデータを高速に扱いたい場合に向いています。

RDSは、SQLやリレーションが必要な業務データに向いています。

このサイトのMVPでは、問い合わせ保存だけが動的データなのでDynamoDBを採用します。

この判断を説明できること自体が、AWSポートフォリオとして大きな学習成果になります。