Amazon DynamoDBの基本とデータモデル

Amazon DynamoDBは、AWSがインフラストラクチャを管理するフルマネージドのNoSQLデータベースです。キー・値型とドキュメント型のデータを扱い、テーブル、アイテム、属性を使って情報を表現します。リクエスト量の変化に対応しやすく、低レイテンシーの読み書きを必要とするアプリケーションの保存先として利用できます。

たとえば、配送網を管理するアプリケーションでは、拠点ごとの作業状態や処理時刻をキーから読み書きする設計が考えられます。ゲームのプレイヤー状態、IoT機器の最新状態、短時間のセッション情報のように、決まった検索条件で大量のデータを扱う場面も候補です。RDSやAuroraのようにテーブル間の関係をSQLで結合する設計が中心なら、リレーショナルデータベースとの比較が必要です。

NoSQLのデータモデル

リレーショナルデータベースでは、行と列からなるテーブル、スキーマ、テーブル間の関係を定義してデータを扱います。一方、DynamoDBはキー・値型とドキュメント型をサポートするNoSQLサービスです。主キーで項目を特定するアクセスが基本になり、アイテムの属性には用途に応じて異なる値を持たせられます。

NoSQLは「スキーマやデータ設計が不要」という意味ではありません。テーブルの主キーは作成時に定義し、そのキーでどのようにデータを分散し、アプリケーションがどの条件で読み書きするかを設計します。利用したいアクセスパターンとキー設計の対応が弱いと、不要な読み取りが増えたり、特定のキーに要求が集中したりします。

また、「NoSQLはリレーショナルDBより常に速い」とは言えません。DynamoDBの利点が生きるのは、サービスのデータモデルとキー検索に合ったアクセスを設計し、必要なスケールや運用特性を得られるときです。複雑な結合、自由な集計、厳密なリレーショナル制約を中心にする場合は、別のデータベースモデルが適することがあります。

テーブル、アイテム、属性

DynamoDBでは、テーブルの中にアイテムが格納され、各アイテムは名前と値の組である属性から構成されます。アイテムはリレーショナルDBの行に、属性は列に似た役割を持ちますが、DynamoDBでは各アイテムがすべて同一の属性を持つ必要はありません。主キーの属性名とデータ型はテーブルのキー定義に合致させます。

図の例では、配送拠点を表す hubId がパーティションキー、作業記録を表す recordedAt がソートキーです。同じ拠点に属する複数の記録は、同じパーティションキーを持ち、ソートキーの順に問い合わせできます。status や packageCount のような業務データは通常の属性としてアイテムに含まれます。

プライマリキーの構成

DynamoDBのプライマリキーには次の2種類があります。

プライマリキー	構成	使い方
パーティションキーのみ	パーティションキー	キーの値によって1つのアイテムを特定する
複合プライマリキー	パーティションキーとソートキー	パーティションキーの値でグループを選び、ソートキーでグループ内のアイテムを特定・範囲検索する

パーティションキーは、DynamoDBがデータを分散して配置するために使うキーです。キー値が異なるアイテムは、分散配置の判断に使われます。アクセスの多くが少数のキー値に集中すると、テーブル全体に十分なキャパシティがあっても一部に負荷が偏ることがあります。そのため、キーの候補は一意性だけでなく、値の分布と読み書きの集中度からも評価します。

ソートキーは複合プライマリキーの一部です。同じパーティションキーを持つアイテムをソートキーの値で並べ、完全一致や範囲条件などを指定した問い合わせに利用できます。たとえば一つの拠点に記録された作業履歴を時間順に取得する場合、拠点IDをパーティションキー、記録時刻をソートキーにする設計が候補になります。

複合プライマリキーでは、パーティションキーだけでは複数のアイテムを同じ値にできますが、パーティションキーとソートキーの組み合わせは一意でなければなりません。この構造により、一つのキー値に属する関連アイテムをまとめつつ、キー条件で読み取り範囲を絞り込めます。

サーバーレス運用とスケーラビリティ

DynamoDBの利用者はデータベースサーバーを起動・管理せずにテーブルを利用できます。サーバーの調達、OSやデータベースソフトウェアのパッチ、ノードの配置や障害交換といったインフラ運用はAWSが担います。需要に応じたスケーリングの仕組みもサービスに組み込まれています。

ただし、サーバーレスは設計や運用作業がすべて不要という意味ではありません。アプリケーションの検索条件に合うキーを定め、要求量と変動の仕方に応じたキャパシティモードを選択し、アクセス権、バックアップ、監視、コストを管理します。キャパシティモードの基本は次のとおりです。

モード	概要	主に確認すること
オンデマンド	読み書き要求に応じてキャパシティを自動的に適用する	需要が予測しにくい場合の扱いやすさ、リクエスト数を基にした料金
プロビジョンド	読み込み・書き込みキャパシティを指定する。必要に応じてオートスケーリングを構成できる	想定需要に合わせた設定、スケーリング条件、容量不足によるスロットリング

したがって、テーブルやインデックスを作るときに常にスループット値を固定して設定するわけではありません。オンデマンドを選ぶ方法もあり、プロビジョンドを選ぶ場合は必要量を設定して、需要の増減に追従する方法を考えます。各モードの料金や変更条件、インデックスごとの容量設定などは別途確認します。

スケーラビリティはキー設計と無関係ではありません。均等に分散しないキーや、非常に人気のある単一キーに大量の要求が集まる設計は、ホットパーティションの原因になり得ます。キャパシティを単に引き上げるだけでなく、アクセスがどのキーに集中するかを調べてデータモデルを見直すことが重要です。

PartiQLとDynamoDBの操作

DynamoDBはNoSQLサービスですが、PartiQLというSQL互換のクエリ言語を利用できます。PartiQLの構文では SELECT、INSERT、UPDATE、DELETE などSQLに似た書き方でアイテムを操作でき、既存のSQLの知識を活用しやすくなります。

PartiQLがあることは、DynamoDBがリレーショナルDBになることを意味しません。DynamoDB固有のテーブル、キー、API、データモデルが引き続き操作の前提です。リレーショナルDBのように任意のテーブルを結合する汎用SQLを前提にしたり、キー設計を省略して自由な条件で効率よく検索できると解釈したりしてはいけません。アプリケーション開発ではAWS SDKのDynamoDB APIや各種データアクセス機能も利用できます。

可用性とデータ配置

DynamoDBはリージョン内の複数のアベイラビリティーゾーン（AZ）にデータを自動的に複製し、AZ障害に対する可用性と耐久性を支えます。利用者がサーバーやストレージを複数AZへ手動で配置する必要はありません。データの冗長化はサービスが管理します。

このリージョン内の複製と、リージョンをまたぐ複製は別の話です。リージョン障害への備えや複数地域からのアクセスが必要なら、グローバルテーブルなどのリージョン間機能を検討します。また、自動複製だけで過去のデータへ戻せるわけではありません。誤更新や削除からの復旧には、オンデマンドバックアップやポイントインタイムリカバリなど、別のデータ保護機能が必要になる場合があります。

どのような場面で選ぶか

DynamoDBは、キーを使った大量の読み書き、短い応答時間、データベースサーバーの運用を避けたい要件に向いています。たとえば、ゲーム内のプレイヤー状態や、機器ごとに継続して届く最新測定値など、アクセス時に使うキーを事前に見通せるデータを検討できます。

要件	確認する設計
キーから特定アイテムを低遅延で取得する	プライマリキーがアプリケーションの検索条件を表現できるか
一つの主体に属する複数レコードを読む	パーティションキーとソートキーでグループ化・範囲検索できるか
データ量や要求量が増える	キャパシティモードとキー値の分布がワークロードに合うか
AZ障害への備えが必要	リージョン内のサービス管理型の複製で要件を満たすか
リレーショナルな結合・集計が中心	RDSやAuroraなど、SQLと関係性を中心に扱うデータベースが適さないか

DynamoDB、RDS、AuroraはいずれもAWSのマネージドデータベースですが、データモデルと得意なアクセス方法は異なります。アプリケーションのデータをどう検索・更新するかを先に整理し、そのパターンを自然に表現できるサービスを選びます。

AWS公式ドキュメント

• Amazon DynamoDBとは
• DynamoDBの主要コンポーネント（テーブル、アイテム、属性）
• DynamoDBのパーティションキー設計
• 読み書きのキャパシティモード
• DynamoDBでのPartiQL
• Amazon DynamoDBの料金

関連トピック

• AWSデータベースサービスの特徴と選び方
• DynamoDBのキー設計・インデックス・キャパシティ（SAA）
• DynamoDBの整合性・ストリーム・グローバルテーブル・バックアップ（SAA）