AWS 23：DynamoDB ― キーで引く、増え方に強いデータベース

一言でいうと：番号札で開ける、巨大なロッカー

第13章の RDS のようなRDB（リレーショナルデータベース＝表の形でデータを持ち、SQL で問い合わせるデータベース）と比べてみます。

DynamoDB は、AWS が用意するキーバリュー型（キーを渡すと値が返る）のNoSQL データベース（SQL の表の形にこだわらないデータベースの総称）です。

いちばん大きな特徴は、データが何件になっても、キーで引く速さがほとんど変わらないことです。1,000件のときも10億件のときも、同じように速く返ります。そのために、置き場所を自動で分け、読み書きを多くの機械に散らしています。

もう1つの特徴は、サーバーレス（第22章）であることです。インスタンスの大きさも台数も選びません。接続も張らず、Lambda と同じように1回ずつ呼ぶだけです。

RDB との違い：自由に聞けるか、決まった形で速いか

違いを表で並べます。

どちらが優れているということはありません。聞き方の自由さと規模が変わっても変わらない速さを交換している、と考えるとわかりやすいです。

RDB は「後から何でも聞ける」代わりに、データが増えるほど、また同時の書き込みが増えるほど、主の1台が苦しくなります。DynamoDB は「聞き方を先に決める」代わりに、どれだけ増えても同じ速さを保てます。

この交換があるので、DynamoDB では設計のしかたが RDB と逆向きになります。これが後で出てくる「アクセスパターンから設計する」の話です。

テーブル・項目・属性：行ごとに中身が違ってよい

DynamoDB の言葉を覚えましょう。

図の左は、photolog-posts テーブルに入っている投稿の項目です。青い文字が PK（USER#u1 のように「誰の投稿か」）、緑の文字が SK（投稿した日時）、黒い文字が title 属性です。

RDB と大きく違うのは、キー以外の属性を先に決めなくてよいことです。ある投稿は title と likes を持ち、別の投稿は title と place を持つ、ということができます。テーブルを作るときに決めるのは、PK と SK の名前と型だけです。

PK や SK の値に USER# のような印を付けているのは、後で同じテーブルに別の種類の項目（いいねなど）を入れたときに、何のキーかを見分けやすくするための、よく使われる工夫です。

パーティションキー：どのロッカーの棚に入れるかを決める

DynamoDB は、データをパーティションという単位に分けて、たくさんの機械に置いています。どのパーティションに置くかを決めるのがパーティションキー（PK）です。

仕組みは次のとおりです。

図では、USER#u2 の投稿がパーティション A、USER#u3 が B、USER#u1 が C に入っています。前の図で表に並んでいた同じ項目が、それぞれの棚に移りました。

大事なのは、PK の値がばらけていることです。利用者が何万人もいて、PK が USER#… のように人ごとに違えば、読み書きはたくさんのパーティションに散らばり、全体として大量の読み書きをこなせます。

逆に、全部の項目の PK が同じ値だと、全部が1つのパーティションに集まり、そこだけが混みます（ホットパーティション）。1つのパーティションが受けられる読み書きの量には上限があるので、これは避けます。

パーティションの数は、データや読み書きが増えると DynamoDB が自動で増やします。あなたが台数を決めることはありません。

ソートキー：同じ PK の中で、並んで入る

ソートキー（SK）を使うと、同じ PK の項目を、SK の順に並べて持てます。

図のパーティション C には、USER#u1 の投稿が3件、SK（日時）の順に並んでいます。新しく 2026-09-07 の「花」を投稿すると、一番後ろに並びます。

PK だけのテーブル（SK なし）もあります。その場合は PK だけで項目が1つに決まり、「キーを渡して1件取る」だけの使い方になります。

SK に日時を入れておくと、「ある人の投稿を新しい順に」「この期間のもの」という、よくある聞き方を1回の読み取りでこなせます。SK をどう作るかは、DynamoDB の設計でいちばん頭を使うところです。

Query：キーで引くから、どれだけ大きくても速い

DynamoDB の読み方には、主に3つあります。

図の上の命令は「PK が USER#u1 で、SK が 2026-09-01 以降」という Query です。DynamoDB は PK からパーティション C を計算で見つけ、そこに並んでいる u1 の投稿だけを読みます。黄色くなった3件です。

ここが DynamoDB の速さの秘密です。Query が読むのは、その PK の分だけです。テーブル全体の投稿が100件でも1億件でも、u1 の投稿が3件なら3件しか読みません。だから、規模が大きくなっても速さが変わりません。

料金も、読んだ量に対してかかります。必要なものだけを読む Query は、速いだけでなく安くもあります。1回の Query で返せるのは 1 MB までで、それを超えると続きを取るための印が返り、次のまとまりを取りに行きます。

Scan：全部の項目を読むので、大きくなると遅く高い

Scan は、テーブルの全パーティションの全項目を、端から順に読みます。

図の命令は「title に『海』を含むもの」を探す Scan です。条件に合うのは1件だけですが、DynamoDB は6件すべてを読んでから、条件に合うものだけを返します。赤くなっているのが、読まれた項目です。

Scan は、データの移行や、ときどきの点検のような場面では使います。でも、利用者のリクエストのたびに Scan する作りにしてはいけません。今は6件でも、投稿が100万件になれば、1回の表示のために100万件を読むことになり、遅く、高くなります。

「title で探したい」のように、キーではない属性で探す必要が出てきたら、それは設計を見直す合図です。キーの形を変えるか、次に出てくる GSI を作るか、全文検索は OpenSearch のような検索専用のサービスに任せます。

設計は「どう読むか」の一覧から始める

ここまでで、DynamoDB は「キーで引く」ときに速く、それ以外は苦手だとわかりました。すると設計の順番が RDB と逆になります。

図は、フォトログの聞き方の一覧です。

「いいねの数」は、いいねの記録を毎回数えるのではなく、数そのものを属性として持っておきます。RDB なら数えればよいところですが、DynamoDB では読むときに楽になるよう、書くときに手間をかけるのが基本の考え方です。

一覧に無い聞き方が後から出てくると、GSI を足したり、データを作り直したりすることになります。だからこそ、最初に聞き方を書き出すことが大事です。

GSI：別のキーで引くための「もう1つの並び」

本体のテーブルは、PK＝USER#… で並んでいるので「ある人の投稿」は得意ですが、「全員の投稿を新しい順に」は引けません。こういうときに使うのが GSI（グローバルセカンダリインデックス）です。

GSI は、同じ項目を別のキーで並べ直した写しです。

本体に項目を書くと、DynamoDB が自動で GSI にも写します。アプリは GSI を指定して Query するだけです。

GSI の注意点です。

RDB の「インデックス」に似ていますが、DynamoDB ではあらかじめ作った GSI の並びでしか引けない点が違います。これもアクセスパターンから設計する理由の1つです。

読み取りの2つのモード：結果整合性と強い整合性

DynamoDB は、1つのリージョンの中の複数の AZ（第2章）に、データの写しを自動で持っています。1つの AZ が止まってもデータは失われず、読み書きも続けられます。

写しがあるので、書いた直後に読むと、まだ反映中の写しから古い値が返ることがあるという性質があります。図の3つ目の写しは、まだ likes = 10 のままです。

いいねの数が一瞬だけ1つ少なく見えても、困る利用者はいません。多くの場面は既定の読み取りで十分です。

もう1つ、トランザクションという機能もあります。「いいねの記録を書く」と「投稿の likes を1つ増やす」のように、複数の項目への書き込みを全部成功するか、全部しないかのどちらかにできます。途中で失敗して「記録はあるのに数が増えていない」を防げます。

料金とモード：オンデマンドから始める

DynamoDB は、インスタンスの時間ではなく、読み書きの量と保存量に対して払います。読み書きの量の数え方には2つのモードがあります。

2024年11月にオンデマンドの単価が大きく下がり、AWS は多くの場合にオンデマンドを勧めています。迷ったらオンデマンドで始め、量が安定してから比べるのがよいでしょう。

課金されるものを並べます。

プロビジョンドのモードには、期限なしで毎月使える無料枠があります（オンデマンドには適用されない）。細かい単価と無料枠の条件は、料金ページと Pricing Calculator（第4章）で確認しましょう。

便利な機能：TTL・Streams・PITR・グローバルテーブル

DynamoDB には、周りの仕事を減らす機能がそろっています。

とくに PITR と 削除保護（テーブルを誤って消せないようにする設定）は、本番のテーブルでは必ずオンにしておきましょう。DynamoDB は AZ の故障には強いですが、人の誤操作やプログラムの間違いで消したデータは、バックアップが無いと戻せません。

Streams は、第24章で学ぶ「イベントで仕事をつなぐ」考え方の入口でもあります。

作り方：テーブルを作り、SDK で読み書きする

コンソールで作る場合は、次の手順です。

列の一覧を作る手順はありません。キー以外の属性は、書き込むときに自由に入れられます。

図の左は AWS CDK で同じことを書いた例、右はアプリ（Node.js の AWS SDK）から Query する例です。

RDS と違い、接続を張りません。1回ごとに HTTPS でリクエストを送り、許可は IAM（第3章）で決めます。Lambda の実行ロール（第22章）に「このテーブルに Query と PutItem をしてよい」と書けば、パスワードも要りません。Lambda が何百に増えても、接続数の問題は起きません。

フォトログでは：いいねと投稿の一覧を DynamoDB に

フォトログでは、次のように使い分けます。

いいねの関数は、次の2つの書き込みをします。

2つをトランザクションでまとめれば、「記録はあるのに数が増えていない」も防げます。

「読んで足して書く」をしてはいけない理由は、2人が同時に「10」を読み、2人とも「11」を書くと、2回押されたのに1しか増えないからです。DynamoDB に計算を任せれば、この問題は起きません。

RDS と比べる：いつ DynamoDB を選ぶか

判断の問いにまとめます。

1つのサービスで両方を使うのはふつうです。フォトログのように、大量で形の決まったもの（いいね・投稿の一覧）は DynamoDB に、関係が複雑で聞き方が変わるもの（利用者・支払い・集計）は RDS に置きます。

迷ったときは、RDS で始めるのが無難です。聞き方が固まっていない作りたてのサービスでは、SQL の自由さが役に立ちます。そのうえで、特定の処理だけが一気に増えて苦しくなったら、その部分を DynamoDB に移す、という進め方がよく取られます。

なお、「サーバーレスで SQL を使いたい」なら、Aurora Serverless（第13章の Aurora の使い方の1つ）という選択肢もあります。

よくある落とし穴

DynamoDB の事故の多くは、RDB と同じつもりで使うことから起きます。

どれも「作る前に聞き方を書き出す」を守れば、多くを避けられます。

片付け：テーブルを消す前に、削除保護と写しを確かめる

練習で作ったテーブルは、次の順で消します。

オンデマンドのテーブルは、読み書きしなければ保存量の分しかかかりません。とはいえ、使わないテーブルは消しておきましょう。

本番では逆に、削除保護はオンのままにしておきます。テーブルを消す操作は、IaC（第18章）で差分を見て、意図したものかを確かめてから行います。コンソールで手で消すのは、事故のもとです。