AWS DYNAMODB VISUALIZER

DynamoDB データモデル

ミリ秒レベルのレイテンシを実現するフルマネージドNoSQLデータベースサービス

シナリオ

DynamoDB のテーブル → アイテム → 属性の階層と、スキーマレスの仕組みをステップで理解する

ステップ1 / 6

◎

ステップ

テーブルの作成 — 定義するのはキーだけ

テーブル作成時に定義するのはパーティションキー（HASH）とソートキー（RANGE）だけ。RDB のように列を定義する必要がない。これが DynamoDB のスキーマレスの出発点です。

DATA MODEL DIAGRAM

DynamoDB のテーブル → アイテム → 属性の階層構造と、スキーマレスの仕組みを見ていこう

STEP 1

CODE VIEW

── DynamoDB テーブル作成 ──
 
$ aws dynamodb create-table \
    --table-name Orders \
    --key-schema \
      '[
        {"AttributeName": "OrderId",   "KeyType": "HASH"},
        {"AttributeName": "CreatedAt", "KeyType": "RANGE"}
      ]' \
    --attribute-definitions \
      '[
        {"AttributeName": "OrderId",   "AttributeType": "S"},
        {"AttributeName": "CreatedAt", "AttributeType": "S"}
      ]' \
    --billing-mode PAY_PER_REQUEST
 
  ✓ テーブル "Orders" を作成しました
 
  → 定義したのは KeySchema（PK + SK）だけ
  → RDB のように列（Column）は定義していない

完了

ステップ

Primary Key

未到達

解説

📌
DynamoDB とは

DynamoDB は AWS が提供するフルマネージドの NoSQL データベースサービスです。Key-Value ストアとドキュメントストアの両方の特性を持ち、サーバーのプロビジョニングやパッチ適用を一切気にせずに使えます。

主な特徴

サーバー管理不要 -- インフラの運用を AWS に完全委任
自動スケーリング -- トラフィックに応じてキャパシティを自動調整
ミリ秒レベルのレスポンス -- 一桁ミリ秒の読み書きレイテンシ
事実上無制限のスループット -- テーブルサイズやリクエスト量に上限なし

RDB（MySQL / PostgreSQL）との根本的な違い

SQL を使わない -- API ベース（GetItem, PutItem, Query など）
JOIN がない -- テーブル間の結合は不可。単一テーブル設計が基本
スキーマレス -- 主キー以外の属性は事前定義不要

どんな時に使うの？

セッション管理ゲームのスコア/状態IoT データEC の商品カタログモバイルアプリのバックエンド

SAA Tips: 試験で「サーバーレス + 高速 + スケーラブル」なデータベースが求められたら DynamoDB を選びましょう。Lambda + API Gateway + DynamoDB はサーバーレスアーキテクチャの定番構成です。

📌
DynamoDB と RDB の違い

RDB（MySQL 等）は Excel のような表形式です。すべての行が同じ列を持ち、列の追加には ALTER TABLE が必要 ── つまり「型が先にあってデータが後から入る」イメージです。

一方 DynamoDB は JSON のような自由な構造です。アイテム（行に相当）ごとに属性（列に相当）が違っても OK。定義が必要なのは主キーだけで、それ以外はアイテムごとに好きな属性を付けられます。

身近な例: RDB は「印刷済みの申込書」（全員が同じ欄を埋める）、DynamoDB は「自由帳」（ページごとに書く内容が違ってOK）と考えるとわかりやすいです。

項目	RDB	DynamoDB
データモデル	テーブル / 行 / 列	テーブル / アイテム / 属性
スキーマ	固定（事前定義必須）	スキーマレス（主キーのみ定義）
クエリ言語	SQL	API（GetItem, Query, Scan）
JOIN	可能	不可（単一テーブル設計）
トランザクション	ACID（標準）	TransactWriteItems（最大100アイテム）
スケーリング	垂直（インスタンスサイズ変更）	水平（パーティション自動分散）
料金モデル	インスタンス時間課金	RCU/WCU or オンデマンド
最大アイテムサイズ	行サイズ制限は DB 依存	400KB

RDB を選ぶべきケース

複雑な JOIN や集計クエリが多い、厳密な ACID トランザクションが必要、データの関係性が複雑なアプリケーション（会計システム、ERP など）。

DynamoDB を選ぶべきケース

大量の読み書きを低レイテンシで処理したい、アクセスパターンが明確、スケーラビリティ最優先（ゲーム、IoT、セッション管理など）。

🔑
DynamoDB のデータ構造

DynamoDB のデータは テーブル → アイテム → 属性 の3層構造です。RDB の「テーブル → 行 → 列」に似ていますが、大きな違いがあります。

RDB ではテーブル作成時にすべてのカラムを定義しますが、DynamoDB で定義するのはテーブル名と主キーだけです。それ以外の属性はアイテムごとに自由に追加でき、アイテムによって属性が異なっても問題ありません。

テーブル（Table）

データの入れ物。作成時に定義するのはテーブル名と主キー（KeySchema）だけ。RDB のように全カラムを事前定義する必要はありません。キャパシティモード（オンデマンド / プロビジョンド）もここで指定します。

アイテム（Item）= RDB の「行」

主キーで一意に特定される1件のデータ。最大サイズは 400 KB。最大の特徴はアイテムごとに属性が異なって OK という点です。上の図のように Item 1 に「Status」があり Item 2 にはなくても問題ありません。

属性（Attribute）= RDB の「列」

各属性は名前 + 値 + 型のセットです。RDB では値が空でも NULL 列として存在しますが、DynamoDB では値を省略すれば属性自体が存在しません。これにより不要なデータを保存しなくて済みます。

プライマリキーの2パターン

ソートキーがあると何が嬉しいの？

同じ Partition Key に対して範囲クエリが使えます。between、begins_with、>= などの条件で効率的にフィルタできます。

// 複合キーの例: ユーザーの注文履歴

{
  "TableName": "Orders",
  "KeySchema": [
    { "AttributeName": "UserId",    "KeyType": "HASH"  },
    { "AttributeName": "OrderDate", "KeyType": "RANGE" }
  ]
}

// Query: UserId="u-001" AND OrderDate BETWEEN "2024-01" AND "2024-06"
// → u-001 の 2024年上半期の注文だけ取得

📋
属性の型（Data Types）

DynamoDB の属性には型（Type）があります。RDB ではカラム定義時に型を決めますが、DynamoDB では属性の値を書き込むときに型を指定します。

API やJSON形式で値を指定する際、型コード（S, N, BOOL など）をキーにして値を渡します。例えば文字列なら {"S": "hello"}、数値なら {"N": "42"} のように書きます。

// DynamoDB に保存されるアイテムの実際の形式

{
  "UserId":    { "S": "u-001" },
  "Age":       { "N": "25" },
  "IsActive":  { "BOOL": true },
  "Tags":      { "SS": ["premium", "jp"] },
  "Profile":   { "M": {
    "Name":    { "S": "田中太郎" },
    "Score":   { "N": "980" }
  }}
}

型コード一覧

スカラー型（1つの値）

S文字列（String）{"S": "hello"}主キーに使える

N数値（Number）{"N": "42"}主キーに使える。値は文字列で渡す

Bバイナリ（Binary）{"B": "dGVzdA=="}Base64エンコード。画像ハッシュ等

BOOL真偽値（Boolean）{"BOOL": true}

NULLNull{"NULL": true}値が存在しないことを明示

ドキュメント型（入れ子構造）

Lリスト（List）{"L": [{"S":"a"}, {"N":"1"}]}異なる型を混在可能

Mマップ（Map）{"M": {"Name": {"S":"太郎"}}}JSONオブジェクトのような入れ子

セット型（同じ型の値の集合、重複なし）

SS文字列セット{"SS": ["red","blue"]}

NS数値セット{"NS": ["1","2","3"]}

BSバイナリセット{"BS": ["dGVzdA=="]}

主キーに使えるのはスカラー型のみ: Partition Key と Sort Key に指定できるのは S（文字列）、N（数値）、B（バイナリ）の3つだけです。BOOL やリスト・マップは主キーには使えません。

💡
スキーマレスの特徴と注意点

DynamoDB の「スキーマレス」とは、テーブル作成時に主キー以外の属性を定義する必要がないということです。各アイテムが異なる属性を持てるため、アプリケーションの進化に柔軟に対応できます。

メリット

ALTER TABLE 不要 -- 新しい属性をいつでも自由に追加
NULL カラム不要 -- 属性自体を省略すれば済む
アプリケーション進化に柔軟 -- マイグレーション作業が激減
異なるバージョンの共存 -- v1 と v2 のデータを同じテーブルに格納可能

注意点

アプリケーション側でのバリデーション責任 -- DynamoDB はデータの整合性を強制しない
型の不一致が検知されない -- "age" に "abc" を入れてもエラーにならない
GSI の射影属性に注意 -- 存在しない属性は GSI に射影されずクエリ制限が発生
アクセスパターンの事前設計が必須 -- スキーマレスでも Single Table Design の設計は最初に行う

SAA で押さえるべき DynamoDB パターン

400KB 制限: データ本体は S3 に格納し、DynamoDB にはメタデータ + S3 URL を保存

Streams + Lambda: テーブル変更をリアルタイムにキャプチャして集計・通知処理

TTL: アイテムの自動削除。セッション管理やログの有効期限に最適

Global Tables: マルチリージョンでの自動レプリケーション。DR と低レイテンシを両立

DAX: マイクロ秒レベルのインメモリキャッシュ。読み取りが多いワークロードに

ConditionExpression: 楽観的ロック（Optimistic Locking）で競合を防止

📝
AWS 認定試験（SAA）レベルの問題

Q1.DynamoDB テーブルの作成時に定義が必要なのはどれですか？

A.すべての属性名と型

B.Primary Key（Partition Key と Sort Key）のみ

C.Primary Key と GSI のすべての属性

D.最低1つのアイテムのサンプルデータ

Q2.同じ Partition Key を持つ2つのアイテムを DynamoDB テーブルに格納するにはどうすればよいですか？

A.同じ PK のアイテムは格納できない

B.Sort Key を異なる値にすれば格納できる

C.GSI を作成する必要がある

D.別のテーブルに格納する

DynamoDB データモデル

📌
DynamoDB とは

📌
DynamoDB と RDB の違い

🔑
DynamoDB のデータ構造

📋
属性の型（Data Types）

💡
スキーマレスの特徴と注意点

📝
AWS 認定試験（SAA）レベルの問題

関連コンテンツ

DynamoDB DAX

DynamoDB パーティショニング

DynamoDB 読み取り整合性

DynamoDB キャパシティモード

DynamoDB Streams + Lambda

DynamoDB トランザクション

📌DynamoDB とは

📌DynamoDB と RDB の違い

🔑DynamoDB のデータ構造

📋属性の型（Data Types）

💡スキーマレスの特徴と注意点

📝AWS 認定試験（SAA）レベルの問題

関連コンテンツ

DynamoDB DAX

DynamoDB パーティショニング

DynamoDB 読み取り整合性

DynamoDB キャパシティモード

DynamoDB Streams + Lambda

DynamoDB トランザクション

📌
DynamoDB とは

📌
DynamoDB と RDB の違い

🔑
DynamoDB のデータ構造

📋
属性の型（Data Types）

💡
スキーマレスの特徴と注意点

📝
AWS 認定試験（SAA）レベルの問題