テーブル、アイテム、プライマリキー

Amazon DynamoDBは、あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現するよう設計された、フルマネージド型のサーバーレスキーバリューおよびドキュメントデータベースです。リレーショナルデータベースとは異なり、DynamoDB はスキーマレスです。プライマリキーが存在していれば、各アイテムは異なる属性セットを持つことができます。

DynamoDB はテーブルにデータを保存します。テーブルは SQL のテーブルに相当する最上位のコンテナです。テーブルは複数の AZ にまたがる複数のストレージノードに自動的に分散されるため、利用者による設定なしで組み込みの冗長性が提供されます。

DynamoDB のテーブルにはアイテムの集合が格納され、各アイテムは属性の集合です。属性は型付きの値であり、String (S)、Number (N)、Binary (B)、Boolean (BOOL)、Null (NULL)、List (L)、Map (M)、Set 型（SS、NS、BS）があります。

テーブル内のすべてのアイテムにはプライマリキー属性を含める必要があります。その他の属性はすべて任意であり、アイテムごとに異なっていてもかまいません。1 つのアイテムのサイズは、すべての属性名と値を含めて最大 400 KB です。

シンプルプライマリキーは、パーティションキー（ハッシュキーとも呼ばれます）という 1 つの属性で構成されます。DynamoDB はパーティションキーの値に内部ハッシュ関数を適用し、そのアイテムを保持するストレージパーティションを決定します。同じパーティションキー値を持つすべてのアイテムは、まとめて保存されます。

シンプルプライマリキーでは、テーブル内の 2 つのアイテムが同じパーティションキー値を持つことはできません。パーティションキー値が各アイテムを一意に識別するためです。この設計は、ユーザー ID や注文 ID など、常に一意の識別子でデータにアクセスするテーブルに適しています。

複合プライマリキーは、パーティションキーとソートキー（レンジキーとも呼ばれます）の両方を使用します。同じパーティションキーを持つアイテムはまとめて保存され、ソートキーの値で並べ替えられるため、パーティション内で範囲クエリを実行できます。

この設計は非常に柔軟です。ソートキーが異なっていれば、複数のアイテムが同じパーティションキーを共有できます。たとえば、Orders テーブルでパーティションキーに CustomerId、ソートキーに OrderDate を使用すると、顧客ごとのすべての注文を日付順にクエリできます。

適切なパーティションキーの選択は、DynamoDB の設計で最も重要な判断です。適切なパーティションキーはカーディナリティ（異なる値の数）が高く、アクセスをパーティション間に均等に分散します。選択を誤ると、1 つのパーティションにトラフィックが偏るホットパーティションが発生し、スロットリングの原因になります。

避けるべきアンチパターンには、ブール値フラグ（値が 2 つしかない）、当日の書き込みをすべて同じグループにまとめる日付、カーディナリティの低いステータスフィールドがあります。適切な選択肢は、ユーザー ID、デバイス ID、ランダムな UUID、または tenantId#entityType のような複合値です。

DynamoDB の基本的なアイテム操作は次の 3 つです。

• PutItem：新しいアイテムを書き込むか、同じプライマリキーを持つ既存のアイテムを完全に置き換えます
• GetItem：完全一致するプライマリキーで 1 つのアイテムを取得します（完全なキー、つまりパーティションキーと、複合キーの場合はソートキーが必要です）
• DeleteItem：完全一致するプライマリキーでアイテムを削除します

これら 3 つの操作はすべて、アイテム単位でアトミックです。デフォルトでは、GetItem は結果整合性のある読み込みを使用します。--consistent-read を追加すると、最新の書き込み値を常に返す強力な整合性のある読み込みが強制されます。

UpdateItemは、PutItem とは異なり、既存のアイテム全体を置き換えずに特定の属性を変更します。属性の追加や削除、Number 属性に対する算術演算（カウンターのインクリメントなど）をアトミックに実行できます。

条件式を使用すると、条件が真の場合にのみ操作を成功させるよう指定できます。たとえば、アイテムのステータスが現在 PENDING の場合にのみ更新できます。これはトランザクションを使わずに楽観的ロックのパターンを実装するもので、DynamoDB の重要な設計手法です。

Queryは、同じパーティションキー値を共有するアイテムを取得し、必要に応じてソートキーの条件で絞り込みます。対象のパーティションだけを読み取るため、Query は効率的です。begins_with、between、=、<、> などのソートキー条件を使用して、パーティション内の結果を絞り込めます。

Scanはテーブル内のすべてのアイテムを読み取り、その後、任意のフィルター式を適用します。大規模なテーブルでは Scan にコストがかかるため、本番環境のクエリパターンでは避けるべきです。頻繁に Scan が必要になる場合は、テーブル設計を見直すか、グローバルセカンダリインデックスを追加してください。

DynamoDBは、複数のAZにデータを3つコピーして保存します。結果整合性読み取り（デフォルト）では、直近の書き込みがまだすべてのコピーに反映されていない場合、わずかに古い値が返されることがあります。ただし、消費する読み取りキャパシティユニットは、強い整合性読み取りの半分です。

強い整合性読み取りでは、常に最新のコミット済み書き込みが返されますが、RCUは2倍必要で、Global Secondary Indexでは利用できません。高スループットの読み取り中心のワークロードでは結果整合性読み取りを選択し、アプリケーションで絶対に最新のデータが必要な場合に限り、強い整合性読み取りを使用してください。

DynamoDBは、ACIDトランザクションをTransactWriteItemsとTransactGetItemsでサポートしています。1つのトランザクションには、複数のアイテム、さらには複数のテーブルにまたがる最大100個の書き込み操作をまとめることができ、すべて成功するか、すべてがアトミックにロールバックされることを保証します。

トランザクションは、口座間の送金（1つのアイテムから引き落とし、別のアイテムに入金）や座席の予約（空き状況の確認と予約をアトミックに実行）などのシナリオで使用します。トランザクションは通常のRCU/WCUの2倍のコストがかかるため、複数のアイテム間で本当にアトミック性が必要な場合にのみ使用してください。

DynamoDBの1アイテムあたり400 KBという制限は、データモデリングに影響します。大きなペイロード（画像や大きなドキュメントなど）は、バイナリデータをS3に保存し、DynamoDBにはS3オブジェクトキーだけを保存してください。深くネストされた階層データの場合は、シングルテーブル設計を使用し、各ノードタイプを独自のパーティションキーパターンでモデル化します。1つのテーブルに複数のエンティティタイプを格納し、パーティションキーのプレフィックスとソートキーパターンで区別します。

シングルテーブル設計はテーブル数を最小限に抑え、関連するアイテムを同じパーティションに配置することで、効率的なアクセスパターンを実現します。これは高度な手法であり、運用上のオーバーヘッドを削減し、複雑なアクセスパターンに対するパフォーマンスを向上させます。

このレッスンでは、DynamoDBのテーブルにはスキーマレスのアイテムが格納され、サイズは400 KBに制限されること、単純なプライマリキーはパーティションキーだけで構成され、複合キーでは範囲検索のためにソートキーが追加されること、そしてカーディナリティの高いパーティションキーによってホットパーティションを防げることを学びました。効率的にアクセスするには、ScanではなくQueryを使用してください。次は、プロビジョンドとオンデマンドのキャパシティモードについて説明します。