DynamoDBを使う際の基本的なところ整理したメモ

• 1‐1. パーティションキー（必須）とソートキー（任意）の選定
• 1-2. データ型（String / Number / Binary / Boolean / Null/ List / Map / Set）の制限
• 1-3. 属性数の上限（400項目まで）
• 1-4. 属性名の予約語・長さ制限（255バイト以内）

• 2-1. グローバルセカンダリインデックス（GSI）の数と制限
• 2-2. ローカルセカンダリインデックス（LSI）の使用可否（作成時のみ追加可能）
• 2-3. インデックス更新のコスト
• 2-4. インデックスの整合性（Eventually Consistent:結果整合性）

• 3-1. キャパシティモード（オンデマンド vs プロビジョンド）
• 3-2. 読み込みスループットの制限
• 3-3. 強い整合性 vs 結果整合性
• 3-4. プロジェクション（読み取り対象属性の絞り込み）
• 3-5. トランザクションの利用有無

• 4-1. 書き込み単位のサイズ制限（最大400KB/アイテム）
• 4-2. 書き込みスループットの制限
• 4-3. バルク書き込み（BatchWriteItem）の制約（最大25件／16MB）
• 4-4. 条件付き書き込みの活用（ConditionExpression）
• 4-5. TTL（Time To Live）設定

• 5-1. BatchWriteItem / BatchGetItem の件数・サイズ制限
• 5-2. バッチ処理のリトライ戦略（未処理項目の再送）
• 5-3. トランザクションとの違い（部分失敗の扱い）
• 5-4. パーティション分散への配慮（ホットパーティション対策）

• 6-1. テーブル削除保護（コンソールまたはAPIで設定）
• 6-2. アプリケーションからの誤削除防止（IAM権限制御）
• 6-3. データの論理削除 vs 物理削除

• 7-1. オンデマンド vs プロビジョンドの料金体系
• 7-2. GSI/LSIの追加コスト
• 7-3. ストレージ使用量と課金対象（すべてのインデックス含む）
• 7-4. データ転送コスト（リージョン間通信など）

• 8-1. IAMによるアクセス制御
• 8-2. テーブルレベル vs 項目レベルのアクセス制御
• 8-3. 暗号化（KMSによるサーバーサイド暗号化）
• 8-4. VPCエンドポイントの利用可否

• 9-1. CloudWatchによるメトリクス監視
• 9-2. DynamoDB Streamsの有効化と用途
• 9-3. Auto Scalingの設定
• 9-4. アクセスパターンのモニタリングと最適化

• パーティションキー: 必須。物理的なパーティションを決める主キーの一部。
• ソートキー: 任意。Partition Keyが同じアイテムを並べるための「主キーの2つ目の要素」。
• DynamoDBにおける主キーは以下2種類存在。
  • シンプルな主キー: パーティションキーのみ。
  • 複合主キー: パーティションキーとソートキーを合わせたもの。

✅ 特徴

• 値が一意である必要はない。
• ハッシュ関数で内部的に分散される。

✅ 特徴

• 同じパーティションキーを持つアイテムを並べる順序を決める。
• これを使って「グループ内での絞り込み・ソート」ができる。

例
UserID (Partition Key) + CreatedAt (Sort Key) → ユーザーごとのアクティビティログ

• ソートキーは複数の属性を連結して構成することも多い。（例：Type#Timestamp）
• 後からパーティションキーは変更不可。（テーブルの作り直しが必要）

📝 例:

• こんにちは → 約 15 バイト（1文字 = 3バイト）
• Hello → 5 バイト（1文字 = 1バイト）

📝 例:

• 12345678901234567890123456789012345678 → ✅ OK（38桁）
• 123456789012345678901234567890123456789 → ❌ NG（39桁）

📝 注意:

• 実データサイズではなく、Base64化後のバイト数が適用される
• 大きなファイルは S3に保存し、DynamoDBにはメタ情報だけを持たせるのが一般的

📝 補足:

• プライマリキーには使えないが、FilterExpression での絞り込みなどに便利

📝 補足:

• Null値は attribute_exists や attribute_type 関数で検出可能

📝 例:

"tags": ["news", "event", "sale"]
"history": [ { "type": "created", "at": "2024-01-01" }, { "type": "updated", "at": "2024-01-02" } ]

📝 例:

"profile": { "name": "Taro", "age": 29, "prefs": { "email": true, "push": false } }

📝 例:

"tagSet": ["news", "event", "sale"]
"intSet": [1, 2, 3]

※ Pythonなど一部のSDKでは set() をそのまま扱えるが、型の指定に注意。

📝 補足:

• 以下のようなアイテムは NG（401個の属性）

  {
    "attr1": "val",
    "attr2": "val",
    ...
    "attr401": "val"
  }
  

• 以下のように Map でまとめれば 属性数としては1つ

  {
    "meta": {
      "attr1": "val",
      "attr2": "val",
      ...
      "attr500": "val"
    }
  }
  

🛠️ 推奨戦略:

• 検索が不要な補足情報は Map にまとめる。
• 属性が動的に増えうる場合は、構造を Map に寄せて設計する。※但しデータ量の合計サイズ400KB以内におさめなければNG

📝 補足:

• バイト制限なので、日本語などを使うと早めに制限に到達することがあります。
  例: 商品名（6バイト）など
• 以下のように #name で予約語を回避し、マッピングすることで解決できます。

input := &dynamodb.UpdateItemInput{
    ExpressionAttributeNames: map[string]*string{
        "#name": aws.String("name"),
    },
    UpdateExpression: aws.String("SET #name = :val"),
}

📚 主な予約語（抜粋）:

• ABORT, ACTION, ADD, ALL, ALTER, ANALYZE
• SIZE, NAME, TYPE, SET, SELECT, DELETE, UPDATE など

🔗 参考: DynamoDB Reserved Words

• グローバルセカンダリインデックス（GSI） は、DynamoDBテーブルのデータに対して異なるパーティションキーとソートキーを使ってデータを検索・クエリできる仕組み。
• これにより、データアクセスのパターンに合わせた効率的な検索が可能。
• GSIは 最大20個 まで作成可能で、各インデックスにはパーティションキーとソートキーを指定が可能。

📝 例:

• 商品テーブルに対して、「カテゴリ」ごとに商品を検索するためのGSIを作成し、カテゴリをパーティションキー、価格をソートキーに指定する。
• ユーザーが購入したアイテムを注文日別に検索する場合、UserID をパーティションキー、OrderDate をソートキーに設定するGSIを作成する。

📝 例:

• 定期的にデータを更新するシステムでは、GSIの数や設計を考慮して、更新処理がパフォーマンスに与える影響を最小限に抑える方法を検討する。

📝 例:

• ユーザーの「注文履歴」をインデックスで検索する際、UserID と OrderDate をキーとして設定する場合、最初の設計でどのようにインデックスを使うかを考え、後から変更できない点を理解しておくことが重要。

📝 例:

• 商品情報の管理において、GSIを使ってカテゴリごとの売上や価格帯別の人気商品などを高速に抽出する場合がある。
• イベントシステムで、特定の日時や地域に基づいて検索が行われる場合、GSIを使うことで、検索効率があがる。

📝 例:

• 投影の選択: インデックスに含める属性を慎重に選ぶことで、キャパシティ単位を節約し、コストを最小限に抑えられる。
• パフォーマンス監視: GSIの利用状況を監視し、アクセスパターンに変化があればインデックスを再設計することも重要。

• AWS公式ドキュメント - DynamoDB Global Secondary Indexes

• ローカルセカンダリインデックス（LSI） は、同じパーティションキーを持ちながら異なるソートキーでデータを検索できるインデックス。
• GSIとは異なり、LSIはテーブル作成時にしか定義できない。
• 最大で5個まで作成できる。

📝 例:

• ユーザーIDが同じアイテムを「作成日」「ステータス」など、異なるソート条件で取得したい場合に使う。

📝 例:

• 注文履歴を「注文日」や「注文ステータス」別に取得したいが、すべて同一ユーザー内で並び替えしたいときに有効。

📝 例:

• 将来的にアクセスパターンが増える可能性がある場合、柔軟な対応ができるGSIの方が適している。

🧱 イメージ
たとえば、下記のようなテーブル構成があるとする。

このとき、created_at をソートキーにしたLSIは以下のように置き換え可能：

• LSI1: ソートキーを priority にする → user_id = 'user1' の中で priority による並び替えが可能
• でも user_id を created_by に変えることはできない（パーティションキーの変更は不可）

📝 例:

• ユーザーが送信したメッセージを「送信時間」「既読フラグ」別でソート表示したいときにLSIを活用できる。

🎯 point:
LSIは「同じ主軸（パーティションキー）に対して、異なる並び替え条件が必要なとき」に適していて、
「別の観点からデータを取得したい（例: 投稿者・カテゴリ・ステータスなど別のキーで取り出したい）」なら、LSIではなく GSI（グローバルセカンダリインデックス） を使う必要がある。

📝 例:

• 「とりあえずLSIを付けておこう」は避けたほうがよい。必要なクエリが見えているときだけ利用する。

• AWS公式ドキュメント - DynamoDB Local Secondary Indexes

• DynamoDBでは、インデックス（GSI/LSI）も自動的に更新される。
• これはテーブルの更新（PutItem / UpdateItem / DeleteItem）に応じて、インデックス側でも該当アイテムの反映処理が走る。
• インデックスが多くなるほど、書き込みコストが増加する要因になる。

📝 例:

• GSIが3つあるテーブルに対して1件のPutItemをすると、GSIにも最大3回の書き込みが発生する。

📝 例:

• 通知ログのように1日に数千件追加されるデータに複数のGSIを張ると、予想外の課金が発生する可能性がある。

📝 例:

• 特定条件でしか使わないGSIを常に更新対象に含めてしまうと、使われないのにコストだけかかる。

📝 例:

• 「あとから検索で使うかも」という理由だけでインデックスを追加するのは危険。アクセスパターンが明確に存在する場合のみ定義する。

• DynamoDBの グローバルセカンダリインデックス（GSI） は「 結果整合性（Eventually Consistent）」を持つ。
• これは、インデックスと元データの間に一時的なズレが生じる可能性があるという意味。
• 一方、LSI（ローカルセカンダリインデックス）は強い整合性（Strong Consistency）。

📝 例:

• データを更新してすぐにGSIで検索しても、古い値が返ることがある。

📝 例:

• 通知一覧やログ閲覧など、「即時性」が求められない画面では問題にならない。

📝 例:

• フィード投稿を更新した後に「最新の投稿一覧」でGSIを使うと、反映されないまま数秒ズレることがある。

📝 例:

• 「支払いステータスが paid になった直後の検索」で反映されない場合、GSI結果を信用せず主キーで再取得して確認する。

• DynamoDBの読み書き性能（スループット）は、「キャパシティモード」 によって制御される。
• 選べるモードは以下の2種類：
  • オンデマンドモード：アクセス量に応じて自動スケーリング。事前設定不要。
  • プロビジョンドモード：読み書き性能（RCU/WCU）を固定で設定。手動スケーリング。

📝 どちらもユースケースによって使い分ける必要がある。

📝 例:

• ECサイトのようにセール時にスパイクするアクセスがあるならオンデマンドが向いている。

📝 例:

• 日中アクセスが集中するアプリでプロビジョンドを使っていてスロットリングが頻発していたケースでは、オンデマンドに切り替えて解消した例もある。

📝 例:

• 検証環境やβリリース直後はオンデマンド → 本番安定後にプロビジョンドに移行、という流れが多い。

• DynamoDB には、1秒あたりに許容される読み込み容量（RCU） の制限がある。
• 読み込みは以下の2種類の整合性によって消費 RCU が変わる：
  • 強整合（Strongly Consistent Read）：1件 = 1RCU（4KBまで）
  • 結果整合性（Eventually Consistent Read）：1件 = 0.5RCU（4KBまで）

📝 読み込み対象のサイズが 4KB を超えると、RCU の消費も倍増するので注意。

📝 例:

• 1KB のアイテムを1秒間に100回読み込む → 強整合で100RCU、最終整合なら50RCU

📝 例:

• ユーザプロフィールを大量に取得する API で、突発的にスロットリングが多発した → 読み込み頻度を間引いたりバッチ化して対応

📝 例:

• 一覧表示用に GSI 経由で大量データを読み込むケースで、必要な属性だけを含めるようインデックス設計を見直したことで、RCUコストが半減した。

• DynamoDB の読み込みには 2 種類の整合性モードがある：
  • 強い整合性（Strongly Consistent Read）：最新の書き込み結果が必ず反映された状態を返す。
  • 結果整合性（Eventually Consistent Read）：読み込み時点での最新状態ではない可能性があるが、最終的には整合性がとれる。

📝 デフォルトは「結果整合性」。API で明示的に指定しない限り強整合にはならない。

📝 例:

• 在庫のように「正確な値」が常に必要なケース → 強整合
• 投稿の「いいね数」のような多少のズレが許容される表示 → 結果整合

📝 例:

• フィード投稿後に画面に反映されない → 強整合で読み直す or 再読込ボタンで補う UI が必要

📝 例:

• 投稿の読み込みは結果整合で一覧表示 → 「自分の投稿だけ強整合で再取得」などのハイブリッド構成も可能

• プロジェクションとは、DynamoDBで「取得対象の属性（カラム）」を明示的に指定すること。
• 特にGSI / LSI の作成時には、どの属性をインデックスに含めるか＝プロジェクションの設計が必須。

📌 読み込み対象を絞ることで、RCU消費を削減し、パフォーマンスも改善できる。

📝 例:

• 投稿一覧表示に title と created_at だけ使う → プロジェクションを INCLUDE にして他の属性を省略

📝 例:

• GSIで ALL を使っていたら、更新時にGSI書き込みエラーが頻発 → INCLUDE にして軽量化した

📝 例:

• 一覧では title と status だけ、詳細では body を取得 → 一覧用GSIは INCLUDE、詳細は本体から GetItem

• DynamoDBはACIDトランザクションをサポートしており、TransactWriteItems・TransactGetItems で最大25件までの操作をまとめて実行できる。
• 書き込み系（Put/Update/Delete）と読み込み系（Get）でAPIが分かれている。

📝 単一操作で済まない一貫性の必要な処理（例：ポイント送信と残高減算）に便利。

📝 例:

• ユーザーAからBへのポイント移動 → 残高の減算と加算を1トランザクションにまとめる

📝 例:

• 同時送金トランザクションがリトライによって二重処理されないよう、トークンなどで冪等化

📝 例:

• アイテム購入時に「在庫減少 + 購入履歴保存 + ポイント加算」を一括で処理

• DynamoDBでは、1アイテムあたりの書き込みサイズ上限が 400KB（= 409,600バイト） に制限されている。
• これは「アイテム全体のJSONバイト数」を対象とするため、属性数や各属性のデータ量すべてを含む。

📌 データ構造や属性サイズの工夫が求められる設計制限。

📝 例:

• 投稿本文が長文＋コメントリスト＋タグリスト → サイズ超過でPutItemが失敗

📝 例:

• 本文＋画像URLリスト＋カテゴリ＋コメントで400KBギリギリ → 画像URLだけ外部ストレージへ移動

📝 例:

• ユーザー投稿データを「本体（タイトル＋本文要約）」と「S3保存された詳細本文」で分離

• DynamoDBでは、テーブルの書き込み処理数にスループット制限が存在する。
• キャパシティモード（オンデマンド or プロビジョンド）に応じて、制限の動き方が異なる。
• 書き込み過多になると ProvisionedThroughputExceededException やスロットリング（遅延・リトライ）が発生する。

📌 「急激なトラフィック増加」や「バッチ処理」に特に注意。

📝 例:

• バッチ処理で1秒間に1万件書き込み → WCU不足で大量に失敗

📝 例:

• 投稿APIが1KBのJSONを1秒に300回呼ばれる → 300WCU消費、WCU設定不足で失敗連発

📝 例:

• アクセスが特定時間に集中するEC系システム → Auto Scalingを夜間に備えて前倒し調整

• DynamoDBのBatchWriteItem操作では、1回のリクエストで最大25件までのアイテムを一括書き込みすることができる。
• 書き込みアイテムの合計サイズは、最大16MBまでとなっており、それを超えるとエラーとなる。

📌 バッチ処理の効率化には最適だが、サイズ制限と件数制限を常に意識する必要がある。

📝 例:

• 1回のリクエストで25件のデータがそれぞれ1MBの場合 → 合計で25MBとなりエラーが発生。

📝 例:

• 100件のアイテムをまとめてバッチ書き込み → 4回に分けてリクエストを行う（1回あたり25件まで）。

📝 例:

• バッチ書き込み時にエラーが発生 → UnprocessedItems を利用して未処理のアイテムを再送信。

• AWS公式ドキュメント - BatchWriteItem

• DynamoDBでは、ConditionExpressionを使用して条件付き書き込みを行うことができる。
• 条件を満たす場合にのみ、データの書き込みが実行される。これにより、競合状態を防いだり、書き込み前にデータの整合性をチェックすることができる。

📌 条件付き書き込みを活用することで、データの一貫性を確保し、無駄な書き込みを防ぐことができる。

📝 例:

• アイテムのstatus属性がactiveの時にのみ、statusをinactiveに変更する。
• attribute_not_exists(id)を使用して、まだ存在しないIDを持つアイテムのみ追加する。

📝 例:

• status = :newStatusの条件を設定しても、既存の値が異なる場合、書き込みが行われない。

📝 例:

• アイテムのstatusがactiveの場合のみ、statusをinactiveに更新する。
• attribute_not_exists(id)を使って、まだ存在しないIDを持つアイテムのみ挿入する。

• DynamoDB 条件式を理解する - ConditionExpression

• 🧾 AWS公式ドキュメント - Time To Live (TTL)

• 🧾 AWS公式ドキュメント - UpdateTable
• 🧾 DynamoDB のテーブル削除保護 - AWS公式ドキュメント

• 🧾 IAM ポリシーの例 - DynamoDB での削除制限
• 🧾 DynamoDB のアクセス管理 - AWS Identity and Access Management

• 🧾 DeleteItem - Amazon DynamoDB
• 🧾 DynamoDB の Time to Live (TTL)

• 🧾 AWS公式ドキュメント - DynamoDB オンデマンドモード
• 🧾 DynamoDB 料金詳細

• 🧾 GSIの使用に関する公式ドキュメント
• 🧾 LSIの使用に関する公式ドキュメント

• 🧾 DynamoDB ストレージ料金
• 🧾 AWS公式ドキュメント - DynamoDB ストレージ使用量

• 🧾 AWS公式ドキュメント - DynamoDBのデータ転送
• 🧾 DynamoDB 料金詳細

• 🧾 AWS公式ドキュメント - IAMでのアクセス管理
• 🧾 DynamoDBのIAMポリシー設定

• 🧾 AWS公式ドキュメント - DynamoDB アクセス制御
• 🧾 IAM ポリシーとアクセス制御のベストプラクティス

• 🧾 AWS公式ドキュメント - サーバーサイドの暗号化
• 🧾 AWS公式ドキュメント - KMSの設定

• 🧾 AWS公式ドキュメント - VPCエンドポイント
• 🧾 AWS公式ドキュメント - DynamoDB VPCエンドポイント設定ガイド

• 🧾 AWS公式ドキュメント - DynamoDBメトリクスの監視
• 🧾 AWS公式ドキュメント - CloudWatchアラームの設定

• 🧾 AWS公式ドキュメント - DynamoDB Streamsの概要
• 🧾 AWS公式ドキュメント - DynamoDB Streamsの利用

• 🧾 AWS公式ドキュメント - DynamoDB Auto Scaling
• 🧾 AWS公式ドキュメント - DynamoDB Auto Scalingの設定

• 🧾 AWS公式ドキュメント - DynamoDBアクセスパターンの設計
• 🧾 AWS公式ドキュメント - DynamoDBインデックスの最適化