← AWSサービスの内部原理 コース
6. アイテムの正体 — スキーマレスと400KBの壁
DynamoDBのアイテムの正体を、入れ物の構造から400KBの壁まで図で追っていきましょう。
①二段重ねの入れ物 — テーブル・アイテム・属性
テーブル Peopleアイテムの集まり
中身は
アイテム= 1人の人物
一意に取り出せる単位さらに中身は
PersonID属性
LastName属性
FirstName属性
- ・属性=名前と値の組。それ以上分解しない基本要素
- ・レコード(名前つきフィールド)+キー・バリューの発想そのまま
テーブル=アイテムの集合、アイテム=属性の集合という二段重ねの入れ物。
②スキーマレス — 設計図はテーブルでなく各アイテムが持つ
RDBの行(タプル)列と型を事前に全部定義
全行同じ形縛りを外すと
アイテム1FavoriteColor あり
アイテム2Year あり
アイテム3どちらもなし
- ・主キー以外は属性も型も事前定義不要(schemaless)
- ・公式の Music テーブルの例もアイテムごとに属性がバラバラ
同じテーブル内で不揃いOK。スキーマは「テーブルの設計図」から「各アイテムが自分で持つもの」に変わった。
③主キーだけ型が縛られる — ハッシュとソートの入力だから
パーティションキー
ソートキー
そのまま入力になる
ハッシュ関数格納先パーティションを決定
ソート並び順を決定
入力は単一で比較可能な値が前提 → だから
String / Number / Binaryスカラー3型のみ許可
主キー属性だけの制限- ・リストやマップだと「どう散らすか・どちらが大きいか」が定まらない
- ・主キー以外の属性にこの制限はない
主キーの値は内部アルゴリズムの入力。ハッシュもソートも単一の値を要求するから、スカラー3型に限定される。
④2つの上限 — 32階層と400KBの壁
ネスト 32階層まで属性の中に属性を畳める深さ
1アイテム 400KBまで属性名+値の合計で数える
理由は
1アイテム = 1回のI/Oの単位キー指定でまるごと出し入れ
SSD上のパーティションから1発で読める天井- ・長い属性名を大量に付けると、値が小さくてもサイズを食う
- ・上限は嫌がらせでなく設計思想の表れ
400KBは「1回のI/Oでまるごと出し入れする」という約束を守れる大きさの天井。
⑤まとめ — 全部、基礎から再導出できる
レコード+キー・バリューデータ構造の基礎
ハッシュ・ソートの入力条件単一で比較可能な値
1回のI/Oという物理SSDの読み書き単位
組み合わせると
DynamoDBのアイテムと制約スキーマレス/主キー3型/32階層/400KB
- ・数字の丸暗記より「なぜ主キーだけ型が要るのか」「なぜ上限があるのか」を自分の言葉で
マネージドサービスの制約も、学んだ基礎の組み合わせでできている。