Amazon DynamoDBとは ― NoSQLデータベースの仕組みとRDSとの違い
DynamoDBは、
Amazon DynamoDBとは、サーバーレスでフルマネージドなNoSQLデータベース
Amazon DynamoDBは、キーを指定してデータを読み書きするNoSQLのデータベースです。表の結合(JOIN)は使いません。リレーショナルデータベースのRDSと並ぶ、AWSのデータベースの選択肢です。サーバの用意や管理をせずに使えます。設定・保守・可用性・バックアップまで、AWSが管理します。そのため、利用者はテーブルの設計とアプリケーションの開発に集中できます。
NoSQLという種類の意味はデータベースとはの記事で説明しています。キーバリュー型やドキュメント型といった型ごとの違いは、NoSQLの記事で比べています。DynamoDBは、NoSQLデータベースをAWS上で使えるサービスの1つです。Amazon RDSとはデータの持ち方が大きく違います。詳しくはRDSとの違いの節にまとめています。
テーブル・アイテム・属性とは、DynamoDBがデータを持つ3つの単位
DynamoDBは、テーブル・アイテム・属性という3つの単位でデータを持ちます。テーブルはアイテムの集まりで、アイテムは属性の集まりです。RDBの表に例えると、テーブルは表全体です。アイテムは1行、属性は1つの列の値にあたります。
DynamoDBのテーブルは、主キー以外の部分がスキーマレスです。スキーマレスとは、属性の種類や数を事前に決めなくてよいという意味です。同じテーブルの中でも、アイテムごとに持つ属性が違ってもかまいません。この点が、どの行も同じ列を持つRDBの表との違いです。
パーティションキーとソートキーが、アイテムの位置とクエリの絞り込みを決める
DynamoDBの主キーには、2つの種類があります。パーティションキーだけを使う単純な主キーと、パーティションキーとソートキーを組み合わせた複合主キーです。
パーティションキーだけのテーブルでは、同じパーティションキーの値を持つアイテムを2つ作れません。パーティションキーの値は、テーブル内で重ならない一意な値です。
複合主キーのテーブルでは、同じパーティションキーの値を持つアイテムを複数作れます。それらのアイテムは、同じパーティション(DynamoDB内部の保存場所)にまとめて保存されます。並び順は、ソートキーの値の順です。パーティションキーの値だけを指定すると、同じ値を持つアイテムがまとめて返ります。さらにソートキーの値の範囲を指定すると、その一部だけに絞り込めます。
| 顧客ID | 氏名 |
|---|---|
| C001 | 山田返る |
| C002 | 佐藤 |
クエリ:顧客ID = C001 で取り出す
顧客ID が C001 のアイテムが1件だけ返ります。顧客IDが重なるアイテムはこのテーブルに作れません。
| 顧客ID | 注文日 | 商品 |
|---|---|---|
| C001 | 2026-01-05 | ノート |
| C001 | 2026-02-10 | ペン返る |
| C002 | 2026-01-20 | ノート |
クエリ:顧客ID = C001 かつ 注文日が2026-02-01以降 で取り出す
顧客ID が C001 のアイテムは同じパーティションに集まり、注文日の順に並んでいます。顧客IDだけを指定すると、C001の2件が注文日の順に返ります。さらに注文日の範囲を指定すると、2026-02-10のアイテムだけに絞り込めます。
図のタブで、パーティションキーだけの顧客テーブルと、複合主キーの注文テーブルを切り替えられます。アイテムのまとまり方とクエリの絞り込み方の違いを比較できます。
RDSとの違いは、複数テーブルに分けて結合するか、1つにまとめるか
RDBの記事と正規化の記事で説明したとおり、RDBは重複を減らすために、顧客・注文・商品のようにテーブルを分けます。分けたテーブルは、主キーと外部キーで結合(JOIN)して、1件の注文のデータにします。
DynamoDBはJOINに対応していません。そのため、取得したいパターンに合わせて、関連する情報を1つのアイテムにまとめて持たせます。顧客名や商品名を、アイテムの中に重複して持たせる形です。これを非正規化と呼びます。
次の表は、RDSとDynamoDBの違いをまとめたものです。
| 観点 | Amazon RDS | Amazon DynamoDB |
|---|---|---|
| データの持ち方 | 表(行と列)。複数のテーブルに分けて主キー・外部キーで結合する | テーブル・アイテム・属性。1つのテーブルにまとめて持つことが多い |
| テーブルの形 | 列(スキーマ)を事前に決める。すべての行が同じ列を持つ | 主キー以外はスキーマレス。アイテムごとに持つ属性が違ってもよい |
| 複数テーブルの結合 | JOINで結合できる | JOINに対応していない |
| 主キー | 1つ以上の列を主キーに指定する | パーティションキーのみ、またはパーティションキー+ソートキー |
RDSのエンジンの1つであるAmazon Auroraも、表を結合して使うリレーショナルデータベースです。MySQLやPostgreSQLと互換があります。
結果整合性のある読み取りが既定で、強い整合性のある読み取りも選べる
DynamoDBの読み取りには、結果整合性のある読み取りと、強い整合性のある読み取りの2種類があります。既定(デフォルト)は結果整合性のある読み取りです。
結果整合性のある読み取りでは、書き込み直後に読み取ると、最新の値が返らないことがあります。少し時間をおいて再度読み取ると、最新の値が返ります。
強い整合性のある読み取りは、ConsistentReadというパラメータをtrueに指定すると使えます。それまでに成功した書き込みをすべて反映した、最新の値が返ります。結果整合性のある読み取りは、強い整合性のある読み取りの半分のコストです。
ただし、強い整合性のある読み取りを選べるのは、テーブルから読むときなどに限られます。グローバルセカンダリインデックスからの読み取りは、常に結果整合性です。グローバルセカンダリインデックスとは、主キーとは別の属性で検索するための索引です。
DAXは、DynamoDBの読み取りを速くする専用のキャッシュです。Amazon ElastiCacheとの違いは、ElastiCacheの記事で説明しています。
キャパシティモードは、オンデマンドとプロビジョンドの2種類
DynamoDBの課金は、キャパシティモードによって2つの方式に分かれます。オンデマンドモードと、プロビジョンドモードです。
オンデマンドモードは、処理した読み取り・書き込みのリクエストの分だけ課金されます。容量を事前に決める必要がなく、トラフィックの増減に合わせて自動で調整されます。既定で推奨されているのは、このオンデマンドモードです。
プロビジョンドモードは、利用者が指定した読み取り・書き込みの容量に対して課金されます。実際に使った量ではなく、指定した容量そのものに課金される点が、オンデマンドモードと違います。オートスケーリングを設定すると、トラフィックの変化に応じて容量を自動で調整できます。
料金は変動するため、具体額は記載していません。最新の料金はAWS公式の料金ページで確認できます。
参考にした資料
- AWS「What is Amazon DynamoDB?」(DynamoDBの定義、サーバーレス・フルマネージドの説明、JOIN非対応、キャパシティモードの存在)
- AWS「Core components of Amazon DynamoDB」(テーブル・アイテム・属性、パーティションキー、複合主キー)
- AWS「DynamoDB read consistency」(結果整合性と強い整合性の違い、既定の設定)
- AWS「DynamoDB on-demand capacity mode」(オンデマンドモードの仕組み)
- AWS「DynamoDB provisioned capacity mode」(プロビジョンドモードの仕組み、オートスケーリング)
練習問題(全6問)
正解:サーバーレスで
DynamoDB Developer Guideは、
正解:テーブルは
Developer Guideは
正解:同じ
Developer Guideは
正解:同じ
Developer Guideは
正解:結果
DynamoDB read consistencyの
正解:オンデマンドは、
On-demand capacity modeの
選んでから「採点する」を押すと、解説つきで答え合わせができます。