導入
ゲームのスコアランキングや、ECサイトのショッピングカートのように、大量のアクセスをミリ秒単位でさばきたい場面があります。RDSやAuroraのようなリレーショナルデータベースは万能ですが、こうした超高速・大量アクセスの用途には別の選択肢もあります。
説明
Amazon DynamoDBは、AWSが提供するフルマネージドのNoSQLデータベースです。キーと値の組み合わせ（キーバリュー）やドキュメント形式でデータを保存し、1桁ミリ秒単位の応答速度と、事実上無制限に近い規模までのスケールを特徴とします。
リレーショナルデータベース（RDS/Aurora）との主な違いは次のとおりです。
| 観点 | RDS / Aurora（リレーショナル） | DynamoDB（NoSQL） |
|---|---|---|
| データ構造 | あらかじめ決めた表（スキーマ）に従う | 項目ごとに柔軟な構造を持てる（スキーマレス） |
| 操作方法 | SQLで複雑な検索・集計・JOINができる | キーを指定した高速な読み書きが中心。JOINはしない |
| 得意なこと | 複雑な関係性を扱うデータ（在庫・注文・会計など） | 超高速・大量アクセス・可変な形式のデータ（セッション情報・ランキング・IoTデータなど） |
| サーバー管理 | インスタンスサイズを意識する | 完全サーバーレス。容量管理を意識しなくてよい |
flowchart LR
Client["アプリケーション"] -->|キー指定で読み書き| DDB["DynamoDB テーブル"]
DDB --> Item1["項目: userId=1, name, score"]
DDB --> Item2["項目: userId=2, name, score, badge"]
上の図のように、DynamoDBの同じテーブルの中でも、項目ごとに持つ属性（列に相当するもの）が異なってかまいません。これがリレーショナルデータベースの「決まった表構造」との大きな違いです。
具体例
スマホゲームのリアルタイムランキングを作るとします。世界中の何百万人ものプレイヤーが、スコア更新のたびに読み書きを飛ばしてきます。
これをRDSでやると、アクセス集中でDBが悲鳴を上げ、応答も遅くなりがちです。DynamoDBなら、
userIdをキーにした読み書きが1桁ミリ秒で返り、何百万アクセスでも自動でスケールする- サーバー台数や容量を気にする必要がない（完全サーバーレス）
- しかも項目ごとに構造が自由。無課金プレイヤーは
userId, scoreだけ、課金プレイヤーはuserId, score, badge, itemsのように列がバラバラでも同じテーブルに入れられる
一方で「注文と在庫と会計をJOINして集計」のような複雑な関係の処理は苦手です。キー一発で超高速に引きたいランキングやカートやセッション情報はDynamoDB、複雑な関係はRDS/Aurora——このゲームの例で線引きがはっきりします。
読んでみよう
「複雑な関係を扱いたいならRDS/Aurora、とにかく速く・大量に・柔軟な形式で扱いたいならDynamoDB」という使い分けの軸を押さえておきましょう。