RDS で「表を作って SQL で引く」ことは分かってきた。ところが、サーバーレスの構成図にはたいてい Amazon DynamoDB が出てくる。NoSQL と言われても、SQL が無いデータベースで何をどう引くのかが想像できない。パーティションキーやソートキー、GSI といった言葉も、試験の選択肢で見るたびに別々に覚えてしまう——そんな段階にいる人向けの記事です。
DynamoDB は「キーを渡すと項目が返ってくる」ことに特化したデータベースです。この1点を先に掴むと、キーの決め方も、インデックスの意味も、RDS との使い分けも、同じ理屈で説明できるようになります。
この記事の結論
- Amazon DynamoDB は、キーを指定して項目を読み書きすることに特化した、サーバーを管理しない NoSQL データベースです。
- 項目を一意に決める主キーは、パーティションキーだけか、パーティションキーとソートキーの組み合わせのどちらかです。
- DynamoDB の設計は、表の形からではなく「どんな条件で、どう引くか」というアクセスパターンの一覧から始めます。
- 後から別の条件で引きたくなったときは、グローバルセカンダリインデックス（GSI）を足して Query で引きます。
- 負荷が読めないならオンデマンド、安定して見積もれるならプロビジョンドを選びます。
- 結合や自由な集計が中心なら RDS、決まった引き方で大量の読み書きをさばくなら DynamoDB が向きます。
Amazon DynamoDB とは何か
Amazon DynamoDB は、AWS が提供するフルマネージドの NoSQL データベースです。サーバーの台数やディスクの容量を利用者が決める必要はなく、テーブルを作れば、どの規模でも1桁ミリ秒台の応答を返すように AWS が内部を分散させます（公式の開発者ガイドの説明）。
データの持ち方は3段です。
- テーブル: 項目の集まり。RDS の「表」に近いものです。
- 項目（アイテム）: 1件のデータ。RDS の「行」に当たります。1項目の大きさには上限があり、公式のクォータでは 400 KB です（属性名の長さも含みます）。
- 属性: 項目の中の値。RDS の「列」に近いものですが、主キー以外は項目ごとに違う属性を持ってよいのが大きな違いです。
DynamoDB が得意なのは「このキーの項目をください」という頼まれ方です。利用者 ID を渡してプロフィールを返す、注文 ID を渡して注文を返す、セッション ID を渡してログイン状態を返す、といった読み書きが中心の処理です。反対に、「条件に合う項目をすべて集めて合計する」「2つの表を結合する」といった問い合わせは、RDS のほうが素直に書けます。
HOW DATA IS HELDデータの持ち方
置き場所はパーティションキー、並びはソートキー
-
テーブル
項目の集まり
RDS の「表」に近い。サーバーの台数は決めない
-
項目
1件のデータ。主キー以外の属性は項目ごとに違ってよい
1項目の上限は 400 KB（属性名を含む）
-
PK
パーティションキー — 値で置き場所が決まる
利用者 ID・機器 ID のように値の種類が多いもの
-
SK
ソートキー — 同じ PK の中の並び順
計測時刻・注文日時。範囲で引ける
パーティションキーとソートキーとは
DynamoDB のテーブルを作るときに決めるのは、ほぼ主キーだけです。主キーには2つの形があります。
| 主キーの形 | 何で項目が一意になるか | 向いている引き方 |
|---|---|---|
| パーティションキーだけ | パーティションキーの値1つ | 利用者 ID でプロフィールを1件引く |
| パーティションキー＋ソートキー | 2つの値の組み合わせ | 機器 ID を指定し、計測時刻の範囲で複数件を引く |
パーティションキーは「置き場所」を決める
DynamoDB は、パーティションキーの値をもとに、データを内部の複数の置き場所（パーティション）に振り分けます。ここから大事な性質が出てきます。同じパーティションキーの値に読み書きが集中すると、その置き場所だけが混み、テーブル全体の性能を使い切れません。これをホットパーティションと呼びます。
パーティションキーには、利用者 ID や機器 ID のように値の種類が多く、読み書きが散らばる値を選びます。当日の日付や「都道府県」のように、値の種類が少ない・同じ時間帯に同じ値へ集中する値は、パーティションキーに向きません。
ソートキーは「同じ棚の中の並び順」を決める
ソートキーは、同じパーティションキーを持つ項目どうしを、どの順に並べるかを決めます。機器 ID をパーティションキーに、計測時刻をソートキーにすれば、「この機器の、昨日の9時から10時まで」を範囲で引けます。並び順を使った「〜から始まる」「〜の間」といった条件は、ソートキーに対して書くものです。
CHECK 1ここまでの確認
DynamoDB のパーティションキーに向いているのは、どんな値?
答えと解説
答え: 2. 種類が多く、読み書きが特定の値に偏りにくい値（利用者 ID など）
パーティションキーの値でデータの置き場所が決まります。同じ値に読み書きが集中すると一部の置き場所だけが混みます。「パーティションキーとソートキーとは」の章を読み直してください。並べる順番を決めるのはソートキーの役割です。
なぜ「アクセスパターンから設計する」のか
RDS では、まずデータを表に正規化し、問い合わせは後から SQL で考えることができました。DynamoDB は順番が逆です。公式の設計ガイドも、答えるべき問いが分かるまでスキーマの設計を始めないように書いています。
DESIGN FROM QUERIES発想の置き換え
表の形からではなく、引き方の一覧から設計する
RDB の発想
DynamoDB の発想
RDB の発想: 表を正規化してから、問い合わせを考える
DynamoDB の発想: 引き方の一覧を先に作り、キーを決める
RDB の発想: 条件は後から SQL で足す
DynamoDB の発想: 新しい条件は GSI を足して Query で引く
RDB の発想: 結合して1回で取る
DynamoDB の発想: 一緒に使うデータを同じキーの近くに置く
Query と Scan の差
DynamoDB の読み取りには大きく2つあります。
| 操作 | 何を読むか | 向いているとき |
|---|---|---|
| GetItem | 主キーを完全に指定した1項目 | ID で1件を引く |
| Query | 1つのパーティションキーの項目（ソートキーの条件で絞れる） | 1人の注文を新しい順に引く |
| Scan | テーブル（またはインデックス）の全項目 | 移行や一括処理など、まれな全件処理 |
Scan は条件を付けても、いったん全件を読んでから絞り込みます。データが増えるほど時間も読み取りの消費も増えるので、画面の表示のような日常の処理を Scan に頼る設計は避けます。日常の引き方は、すべて GetItem か Query で書ける形にする——これが「アクセスパターンから設計する」の中身です。
引き方が増えたら、インデックスを足す
運用を始めてから「配送ステータスごとに一覧したい」のような新しい引き方が出てきたら、セカンダリインデックスを使います。
| インデックス | キー | いつ作れるか | 読み取りの整合性 |
|---|---|---|---|
| グローバルセカンダリインデックス（GSI） | テーブルと別のパーティションキー（＋ソートキー） | 既存のテーブルにも後から足せる | 結果整合性のみ |
| ローカルセカンダリインデックス（LSI） | テーブルと同じパーティションキー＋別のソートキー | テーブルを作るときだけ | 強い整合性も選べる |
GSI は、元のテーブルとは別のキーで Query できる「引き方の追加」です。書き込みはテーブルから GSI へ非同期に反映されるので、GSI からの読み取りは結果整合性（書いた直後の値がまだ見えないことがある）になります。直後の値が必ず要る処理は、テーブル本体を強い整合性で読みます。
CHECK 2ここまでの確認
作ったあとのテーブルに「別の属性で一覧したい」という新しい要件が来たとき、まず検討するのは?
答えと解説
答え: 2. その属性をキーにしたグローバルセカンダリインデックス（GSI）を足し、Query で引く
GSI は既存のテーブルにも後から足せて、別のキーで Query できます。LSI はテーブルを作るときにしか作れません。Scan は全件を読むので、量が増えるほど遅く高くなります。「アクセスパターンから設計する」の章を読み直してください。
オンデマンドとプロビジョンドはどう選ぶか
DynamoDB は、読み書きの処理能力（キャパシティ）の払い方を2つから選びます。
CAPACITY MODEキャパシティの払い方
決め手は1つ、負荷を前もって見積もれるか
オンデマンド
- 見積もり不要
- 急な山に自動で追従
- リクエストの分だけ払う
プロビジョンド
- 処理能力を先に決める
- Auto Scaling で調整
- 安定した負荷で費用を抑えやすい
支点は「負荷を見積もれるか」
| オンデマンド | プロビジョンド | |
|---|---|---|
| 何を決めるか | 決めない（リクエストの量に合わせて追従） | 1秒あたりの読み取り・書き込みの処理能力を先に決める |
| 払い方 | 読み書きのリクエストの分だけ | 決めた処理能力の分（使わなくても） |
| 向いている負荷 | 新しいサービス、急な山がある、見積もれない | 安定していて、前もって見積もれる |
| 超えたとき | 追従するが、それまでの山を大きく超える急な伸びではスロットリングが起きることがある | スロットリング（処理を断られる）が起きる。Auto Scaling で調整する |
判断の軸は1つで、負荷を前もって見積もれるかです。見積もれないうちはオンデマンドで始め、利用の形が安定して読めるようになったらプロビジョンド（Auto Scaling つき）に切り替えて費用を比べる、という順番が取りやすい進め方です。どちらのモードでも、スロットリングの応答を受けたアプリは、少し待って間隔を広げながらやり直す（指数バックオフ）ように作ります。AWS の SDK は標準でこの再試行を持っています。
単価や無料利用枠の値は改定されることがあるため、この記事には書きません。AWS の DynamoDB の料金ページで確認してください。
知っておくと構成図が読める機能
DynamoDB の周りには、構成図や試験でよく出る機能がいくつかあります。名前と役割だけ先に押さえておきます。
- TTL（有効期限）: 項目に期限の時刻を持たせると、期限切れの項目を自動で消します。セッションや一時データに使います。
- DynamoDB Streams: 項目の追加・更新・削除を順に記録し、AWS Lambda などの後続処理に渡します。
- ポイントインタイムリカバリ（PITR）: 有効にしておくと、保持期間の中の任意の時点に、新しいテーブルとして復元できます。
- グローバルテーブル: 複数のリージョンにテーブルの複製を置き、どのリージョンからも読み書きできるようにします。
- DynamoDB Accelerator（DAX）: DynamoDB 専用のインメモリキャッシュで、読み取りの多い処理を速くします。
CHECK 3ここまでの確認
放送の直後だけアクセスが跳ね上がり、ふだんはほとんど使われないテーブルに向くキャパシティモードは?
答えと解説
答え: 1. オンデマンドモード
オンデマンドは読み書きの量に合わせて自動で追従し、使った分だけ払います。負荷を前もって見積もれないときに向きます。「オンデマンドとプロビジョンドはどう選ぶか」の章を読み直してください。
RDS とどう使い分けるか
DynamoDB と RDS は、どちらが上というものではなく、得意な頼まれ方が違うデータベースです。
| 比べる点 | Amazon DynamoDB | Amazon RDS |
|---|---|---|
| データの形 | キーと項目（項目ごとに属性が違ってよい） | 表と列（スキーマを先に決める） |
| 問い合わせ | キーを指定した読み書きが中心 | SQL で自由に絞り込み・結合・集計 |
| 設計の起点 | アクセスパターンの一覧 | データの正規化 |
| 規模を大きくする方法 | AWS が内部で分散（台数を意識しない） | インスタンスの大きさ・リードレプリカ |
| サーバーの管理 | 無い（インスタンスを選ばない） | インスタンスの種類と台数を選ぶ |
| 向いている用途 | セッション・利用者ごとの状態・ゲームのスコア・IoT の計測値 | 業務システム・受発注・会計など、関係の多いデータ |
迷ったときは、次の2つを自分に問います。
- 引き方は今の時点で一覧にできるか。 一覧にでき、ほとんどがキーを指定した読み書きなら DynamoDB。検索条件が後から増えていく見込みが強いなら RDS。
- 結合や集計をデータベースに任せたいか。 任せたいなら RDS。大量のデータを横断して集計する分析は、どちらにも無理をさせず、分析用の仕組み（データウェアハウスやデータレイク）に分けます。
Web サーバーを横に増やすときにセッションを DynamoDB に外出しする、商品の在庫や注文は RDS に置く、というように、1つのシステムの中で両方を使うのはごく普通の構成です。
READ ALSO — 学習中向け・段2 構成
Amazon RDS とは何か｜マネージドの範囲と、EC2 に DB を置く場合との責任の違い
まとめ
- DynamoDB は「キーを渡すと項目が返る」ことに特化した、サーバーを管理しない NoSQL データベースです。
- 主キーはパーティションキー（置き場所）と、必要ならソートキー（並び順）で決まります。パーティションキーは値の種類が多く、読み書きが散らばるものを選びます。
- 設計はアクセスパターンの一覧から始め、日常の引き方を GetItem と Query で書ける形にします。新しい引き方は GSI で足します。
- キャパシティは、負荷が読めないならオンデマンド、見積もれるならプロビジョンドです。
- 結合や自由な問い合わせが中心なら RDS。1つのシステムで両方を使い分けます。
次は、DynamoDB と組み合わせて使われることの多い AWS Lambda に進むと、イベントを受けて DynamoDB に読み書きする、サーバーを持たない構成の全体が見えてきます。
参照ソース
- What is Amazon DynamoDB?（Amazon DynamoDB 開発者ガイド） — フルマネージドの NoSQL であること、規模によらず1桁ミリ秒台の応答という説明の根拠（2026-09 時点の記載）
- Core components of Amazon DynamoDB（同） — テーブル・項目・属性、主キーの2つの形、パーティションキーとソートキーの役割の根拠（2026-09 時点）
- Quotas in Amazon DynamoDB（同） — 1項目の最大サイズ 400 KB（属性名を含む）の根拠（2026-09 時点）
- NoSQL design for DynamoDB（同） — 答えるべき問いが分かる前にスキーマの設計を始めない、という設計の考え方の根拠（2026-09 時点）
- Improving data access with secondary indexes in DynamoDB（同） — GSI と LSI の違い（キー・作成できる時期）の根拠（2026-09 時点）
- DynamoDB read consistency（同） — GSI からの読み取りは結果整合性のみ、という記述の根拠（2026-09 時点）
- DynamoDB throughput capacity（同） — オンデマンドとプロビジョンドの違いと向いている負荷の根拠（2026-09 時点）
- Querying tables in DynamoDB（同） — Query がパーティションキーを指定し、ソートキーの条件で絞り込む操作であることの根拠（2026-09 時点）
- Using time to live (TTL) in DynamoDB（同）・Change data capture for DynamoDB Streams（同）・Point-in-time recovery（同）・Global tables（同）・DAX（同） — 周辺機能の役割の根拠（2026-09 時点）
