DynamoDB はキーバリューストアですか？

はい — DynamoDB はキーバリューストアであり、同時にドキュメントストアでもあります。すべてのアイテムはプライマリキー（パーティションキー、および任意のソートキー）で取得され、キーに基づく高速な検索ができます。さらにドキュメント型 — ネストしたリストとマップ — もサポートするので、キーバリューデータベースとしてもドキュメントデータベースとしても機能します。

キーバリューのモデル

各アイテムは、それを一意に識別するプライマリキーを持ちます。そのキーに対する GetItem は、スキャンなしの直接的な 1 桁ミリ秒の検索です。これが古典的なキーバリューのアクセスパターンです。

ドキュメントとしての側面

キーの先では、値をリッチなドキュメントにできます。マップ（オブジェクト）とリスト（配列）を、400 KB のアイテム上限の範囲内で 32 階層までネストできます。つまり DynamoDB は、JSON ライクなドキュメントを値に持つキーバリューストアです。

ドキュメントとしての側面が止まるところ

32 階層の上限は本物です（33 階層目はきっぱり拒否されます。正確なエラーはこちら）が、痛いのは深さであることはめったにありません。痛いのはアドレス指定です。

読み取りはキー単位であって、フィールド単位ではありません。ProjectionExpression が絞るのは、DynamoDB が読む量ではなくワイヤを渡る量です。長い bio と 100 要素の tags リストを持つ約 30 KB のアイテム 1 件では、強整合の GetItem は 3 通りとも同じ請求になります。

リクエスト	返ってきたもの	`ConsumedCapacity`
`GetItem`、アイテム全体	すべて	8
`ProjectionExpression: 'status'`	6 バイトの値 1 つ	8
`ProjectionExpression: 'profile.tags[0]'`	リスト要素 1 つ	8

これが、キーバリューストアにドキュメントを格納することで受け入れるトレードオフです。アクセスの単位も課金の単位も、アイテム全体なのです。ある属性が絶えず読まれ、その隣人が大きいなら、それらは別々のアイテムに属します。

キーがこれほど重要な理由

読み取りがキー単位である以上、効率的な検索は 1 つのパーティションキーの値を特定することから始まります。良いキーの設計こそが DynamoDB のモデリングの中核です。

キーだけでなく、値のサイズも見る

キーバリューの速さは、値がアクセスパターンに収まっていることを前提にしています。400 KB のアイテムは、1 フィールドだけを射影しても文書全体を読んでも読み取りコストは同じです — 上のセクションの表でも、約 30 KB のアイテムに 8 キャパシティユニットかかっていました。文書の一部だけがホットなら、大きなブロブは S3 に置き、DynamoDB にはポインタだけを保持しましょう。

アイテムサイズ計算ツールは、DynamoDB が課金するのと同じやり方で属性名と値を合計します。

DynoTable では: USER#123 のような複合パーティションキーがグリッド上でデコードされるので、エンティティのプレフィックスがひと目で読めます。行の Quick View（Space）なら、場所を見失わずに文書全体を開けます。テーブルのクエリを参照してください。

さらに詳しく

キーについては DynamoDB の複合プライマリキーと DynamoDB のパーティションキーの仕組みで理解を深めてください。キーでクエリするには DynoTable をダウンロードしてください。

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

キャパシティの数値は 2026-07-28 に、@aws-sdk/client-dynamodb 3.1095.0 を用いて DynamoDB Local 3.3.0（amazon/dynamodb-local:latest）に対して測定したもので、推定ではありません。