DynamoDBのアイテムサイズ上限(400 KB)
単一のDynamoDBアイテムが保持できるデータは最大400 KBです。MongoDB(16 MBのドキュメント)や実質的な上限のないリレーショナルの行から来ると、その天井は低く感じられます — そしてたいてい、何か月も動いていた書き込みが、あるアイテムがついに大きくなりすぎてValidationExceptionで突然失敗するという形で、痛い目を見て初めて気づくのです。
この上限は恣意的なものではなく、引き上げられるクォータでもありません。これはモデリング上の制約であり、それに当たるアイテムはたいてい、データのモデリングが間違っていたことを教えてくれています。
DynamoDBのアイテムサイズの上限は?
DynamoDBは単一のアイテムを400 KBに制限しており、これは引き上げられないハードリミットです。このサイズには、属性名と値が合わせて数えられ、ネストされたすべてのリスト・マップ・セットの要素も含まれます。アイテムは通常、際限なく成長する埋め込みリストのような無秩序な肥大化によってこの上限に達します。修正は圧縮ではなくモデリングであり、コレクションを別々のアイテムに分割することです。
- アイテムごとに400 KB、ハードキャップ。 調整不可、ソフトクォータでもない。
- サイズ = 属性名 + 値、合わせて。 長い属性名は、すべてのアイテムで数えられる。
- ネストとセットも数える。 リスト、マップ、そしてそれらのネストされた値はすべて積み上がる。
- よくある原因は際限のない肥大化 — 親アイテムに、限りなく成長するリストを埋め込むこと。
- 修正はモデリングであって、圧縮ではない。 成長するコレクションを、共有パーティションキーの下で独自のアイテムに分割する。
問題:永遠に成長するアイテム
車両のフリートを追跡していて、各車両のテレメトリ読み取り値を車両アイテム上のリストとして保存することにしたとします:
PK: VEHICLE#A1 readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]1日や2日は問題ありません。しかし読み取り値は数秒ごとに到着し決して止まらないため、リストは際限なく成長します。やがて単一の車両アイテムが400 KBを越え、それへのすべての書き込みが失敗します — 各更新が(今や肥大化した)アイテム全体を書き直すため、その車両のテレメトリをもはやまったく記録できなくなります。
バグはサイズ上限ではありません。際限のない一対多の関係を、埋め込みリストとしてモデリングしたことです。それがうまくいくのは「多」の側が有界で小さい場合だけです。
400 KBに実際に数えられるもの
DynamoDBはアイテムの総サイズを次の合計として計測します:
- すべての属性名(UTF-8エンコード)。何百万ものアイテムにわたって繰り返される20文字の名前は、支払うサイズでありストレージでもあります — 経験豊富なモデラーが属性名を短く保つのはこのためです。
- すべての属性値。 文字列とバイナリはバイト長で、数値はコンパクトなエンコードで、ブール値とnullはごく小さい固定コストで。
- ネストされた構造。 リストやマップは自身のオーバーヘッドに加えて、その中のすべての要素とキーのサイズを、最後まで下までずっと数えます。
計画すべき属性ごとの個別の上限はありません — アイテム全体が400 KBの線に対して測られます。AWSサービスクォータに正確なバイト計算が記されています。
なぜこの上限があるのか
大きなアイテムは移動するのに高くつきます。DynamoDBの読み取りは4 KB単位で計量されるため、400 KBのアイテムは強い整合性で読むと100 RCUかかります — そして読み取り、書き込み、レプリケーションのすべてが、アイテムが大きくなるにつれて遅く高価になります。この上限は、小さく的を絞ったアイテムへあなたを向かわせ、NoSQL初心者がリレーショナルの習慣から手を伸ばしがちな「巨大なブロブを1つ取得する」アンチパターンから遠ざけます。
それを避けてモデリングする
フリートの例では、埋め込みをやめましょう。各読み取り値に、車両と同じパーティション内で独自のアイテムを与え、ソートキー上でタイムスタンプによって順序付けます:
PK: VEHICLE#A1 SK: READING#2026-06-27T10:00:05Z lat, lng, fuel
PK: VEHICLE#A1 SK: READING#2026-06-27T10:00:10Z lat, lng, fuelこれで単一のアイテムは成長せず、書き込みが上限を越えることはなく、VEHICLE#A1に対する単一のQueryが依然として車両の読み取り値を1つのソート済みアイテムコレクションとして取り戻します。有界のサブリスト(少数のタグ、固定の設定ブロック)は埋め込んで問題ありません。際限のないものはアイテムになります。
DynoTableでアイテムサイズを確認する
形を確定する前に、代表的なアイテムを量りましょう。DynoTableでアイテムをQuick Viewで開くと、アイテムのバイトサイズがその属性とともに表示されます — 実際のデータを閲覧しながら、失敗する書き込み時ではなく設計時に重すぎる形を捉えられます。
ブラウザで作業したい場合は、DynamoDBアイテムサイズ計算ツールでも同じことができます。貼り付けたサンプルから正確なKBと各読み書きにかかるRCU/WCUを報告します。
落とし穴と次のステップ
- トラフィックとともに成長する埋め込みリストに注意。 古典的な400 KBの時限爆弾です。有界にするか、分割しましょう。
- 属性名を短くする。 高カーディナリティのアイテムでは — サイズとストレージがただで戻ってきます。
- 大きな値はS3に。 大きなブロブ(画像、ドキュメント)はS3に保存し、アイテムにはキーだけを保持しましょう。
- 関連: 非正規化と一対多の関係が、埋め込むか分割するかをいつ選ぶかを扱っています。
テーブル全体の実際のアイテムサイズを一目で見たいですか? DynoTableをダウンロードして、データを直接調べてください。