Amazon DynamoDB

は、サーバーを管理せずに使えるキーと値・ドキュメント型のデータベースです。規模によらず一桁ミリ秒で読み書きでき、データが増えても自動で分散します。DEA-C01 では、アクセスパターンから決めるキーとインデックスの設計、キャパシティモードと、による期限切れデータの削除、Streams・へのエクスポート・などのデータの出し入れと保護が問われます。

Point

NoSQL: リレーショナル (SQL) 以外のデータベースの総称です。DynamoDB は結合を前提にしません。
TTL = Time to Live (生存期間) です。項目ごとに期限を持たせ、過ぎたら自動で削除します。
PITR = Point-in-Time Recovery (ポイントインタイムリカバリ) です。過去の任意の時点へ戻せます。
GSI = Global Secondary Index、LSI = Local Secondary Index です。

概要

は、テーブル・項目 (行に相当)・属性 (列に相当) でデータを持ちます。項目ごとに属性が違ってもよく、1項目の大きさは最大 400 KB です。

リレーショナル DB は「データを正規化してから、クエリで自由に結合する」設計ですが、DynamoDB は「先にアクセスパターン (どのキーで何を取るか) を決め、それに合わせてキーとインデックスを作る」設計です。試験では、アクセスパターンからキーを選ぶ問題と、分析のためにデータを外へ出す方法の問題がよく出ます。

主要技術

①プライマリキーとアクセスパターンからのスキーマ設計 ⚠️ 頻出

キー	構成	できる問い合わせ
のみ	1つの属性	キーを指定した1件の取得 (GetItem)
複合キー	パーティションキー +	同じパーティションキーの中で、ソートキーの範囲・前方一致・並べ替え (Query)

パーティションキーの値をハッシュして、データを内部のパーティションへ分散します。1つのパーティションが処理できるのは、毎秒 3,000 読み取りユニットと 1,000 書き込みユニットまでです。値の種類が少ないキー (日付、ステータスなど) を選ぶと、一部のパーティションへ集中してが起きます (ホットパーティション)。

設計の手順	内容
1. アクセスパターンを列挙	「顧客 ID で注文一覧を新しい順に」「注文 ID で1件」など
2. パーティションキーを選ぶ	カーディナリティが高く、アクセスが均等に分かれる属性
3. ソートキーを選ぶ	範囲や並べ替えに使う属性 (日時など)。`ORDER#2026-10-17` のように複数の情報を連結することもある
4. 足りないパターンにインデックス	別の属性で引く必要があれば /

関連するデータを1つのテーブルにまとめ、ソートキーの接頭辞で種類を分ける設計 (シングルテーブル設計) を使うと、1回の Query で関連する項目をまとめて取れます。

Scan はテーブル全体を読むため、大きなテーブルでは遅く、容量も大量に消費します。日常のアクセスパターンを Scan で満たす設計は避けます。

②セカンダリインデックス (GSI と LSI)

観点
キー	別の + 任意の	元と同じパーティションキー + 別のソートキー
作成	いつでも追加・削除できる	テーブル作成時にしか作れない
整合性	結果整合性の読み取りのみ	強い整合性の読み取りもできる
容量	元のテーブルとは別に持つ	元のテーブルの容量を使う
制約	GSI の書き込みが追いつかないと、元のテーブルの書き込みもされる	同じパーティションキーの項目の合計が 10 GB まで

GSI には必要な属性だけを射影 (コピー) すると、保管と書き込みの費用を抑えられます。

③キャパシティモードとスロットリング ⚠️ 頻出

モード	課金	向く負荷
	読み書きのリクエスト数	予測できない、急に増える、新しいテーブル
プロビジョンド (+ )	設定した RCU・WCU の時間	予測でき、高い使用率で安定した負荷

プロビジョンドでは、1 RCU で 4 KB までの項目の強い整合性の読み取りが毎秒1回 (結果整合性なら2回)、1 WCU で 1 KB までの項目の書き込みが毎秒1回です。

の原因	対処
テーブル全体の容量不足 (プロビジョンド)	容量を増やす、Auto Scaling、オンデマンドへ切り替え
ホットパーティション (特定のキーへの集中)	高カーディナリティのキーにする、キーに接尾辞を付けて書き込みを分散する (書き込みシャーディング)
の書き込み容量不足	GSI の容量を増やす
一時的な急増	の付きの再試行、で書き込みを平準化する

パーティション単位の上限は、オンデマンドでも同じです。オンデマンドにすればホットパーティションが解決するわけではありません。

④TTL による期限切れデータの削除 ⚠️ 頻出

を有効にし、項目に期限 (Unix エポック秒) の属性を持たせると、期限を過ぎた項目をが自動で削除します。

特徴	内容
費用	削除に書き込み容量を消費しない
タイミング	期限後、通常数日以内に削除される。それまでは読み取りに出てくるため、Query で期限の条件を付けて除く
Streams との関係	TTL による削除も Streams に流れる (サービスによる削除として区別できる)
用途	セッション、一時データ、保持期間を過ぎた履歴

TTL の削除を Streams で受けてでへ書くと、期限切れの項目を DynamoDB から消しつつ、S3 にできます。

⑤データを外へ出す・取り込む

手段	内容	向くケース
Streams	項目の変更を24時間保持し、などへ時系列に渡す	変更を契機にした後続処理
for DynamoDB	変更を Kinesis Data Streams へ送る。保持期間が長く、多数のコンシューマーに配れる	やなど複数の処理への配信
へのエクスポート	全件または増分を S3 へ書き出す。が前提で、読み取り容量を消費しない	本番に影響を与えずに・・で分析
S3 からのインポート	S3 の CSV・DynamoDB ・Ion から新しいテーブルを作る	大量の初期データの投入 (書き込み容量を消費しない)
統合	やへ自動で複製する	パイプラインを作らずに分析・検索

Streams との使い分けは「変更データキャプチャ (CDC) と zero-ETL」の章で扱います。分析のためにテーブルを Scan する処理は、本番の容量を奪うため避けます。

⑥バックアップとバージョンの管理

機能	内容
	1〜35日で設定した期間内の任意の時点へ、新しいテーブルとして復元する
バックアップ	任意の時点の完全なバックアップ。削除するまで残る。でも管理できる
削除保護	テーブルの誤削除を防ぐ
	複数ので読み書きできるテーブル
	の前段に置く。マイクロ秒の読み取り

誤った一括更新でデータが壊れた場合、グローバルテーブルのレプリカにも同じ変更が伝わるため、PITR で戻します (「データの保護とレジリエンス」の章)。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの
アクセスパターンが決まっていて、一桁ミリ秒で読み書き
顧客ごとの注文を日付の範囲で取得	= 顧客 ID、 = 日付
別の属性でも検索したい (後から追加)
同じパーティションキーで別の並び順、強い整合性	(テーブル作成時)
特定のキーに書き込みが集中して	高カーディナリティのキー、書き込みシャーディング
負荷が予測できない新しいテーブル
一定期間後に項目を自動で削除、費用をかけない
期限切れの項目をに残したい	TTL + Streams + で S3 へ
本番に影響を与えずに全件を分析	S3 へのエクスポート → /
大量の初期データを書き込み容量なしで投入	S3 からのインポート
なしでで分析	統合
誤った更新の前の状態へ戻す

②よくある誤答

分析のために本番テーブルを毎日 Scan すること。容量を奪います。へのエクスポートを使います。
にすればホットパーティションのが消えると考えること。パーティション単位の上限は同じです。
で期限を過ぎた項目が即座に消えると考えること。数日かかることがあるため、読み取り側で除外します。
を既存のテーブルに後から追加しようとすること。LSI は作成時のみで、後からならです。
リレーショナル DB のように正規化して、アプリ側で結合する設計にすること。アクセスパターンから設計します。