書き込みと運用
DynamoDB が SQL のユニークインデックスのように一意性を強制すると想定し、 条件式なしでデプロイし、本番で重複アカウントを発見する。属性横断の制約はない — 自分で設計するアトミックな書き込みだけだ。
書き込みはアイテム単位で、硬い上限付きでバッチされ、ホットなパーティションキー
横断で増幅しやすい。ALTER TABLE がないので移行はアプリケーションレベルだ。
このセクションはバッチ API、戻り値、カウンター、一意性パターン、オンラインの
形変え、そして 1 つのパーティションキーがトラフィックを吸いすぎるときの運用の
傷跡を扱う。
読み終えたらできること
- 25 アイテム／16 MB の上限内で
BatchWriteItemとバッチ削除を、黙った部分失敗なしに 使える。 - 条件付き書き込みでアトミックカウンターと複数属性の一意性を実装できる。
- デュアルライトまたはバックフィルパターンでゼロダウンタイム移行を計画できる。
- スロットリングの前に、書き込み分布とキー選択からホットパーティションを見つけられる。
読む順番
- バッチ操作 —
BatchWriteItemの上限、 未処理キー、バッチがトランザクションではない理由。 - 複数アイテムの削除 — ツールでの バッチ削除対ステージ済み削除。削除アイテムあたりのキャパシティ。
- ReturnValues —
ALL_OLD、UPDATED_NEW、 2 回目の読み取りなしで何が返るか。 - アトミックカウンター —
ADD更新と、 なぜ読み取り・変更・書き込みが並行下で負けるか。 - 複数属性の一意性 — 一意性 アイテムと重複を拒否する条件付き put。
- 移行 — トラフィックが生きているあいだに キーと GSI を形変える。スキーマ移行ボタンはない。
- ホットパーティション — 偏ったキー、 書き込みスパイク、設計上の修正。
TransactWriteItems は最大 10 アイテムにまたがる最大 25 アクションを受け付け、
トランザクションペイロード上限は 4 MB。キャンセル理由には
ConditionalCheckFailed、TransactionConflict、TransactionInProgress があり —
それぞれ別のリトライ戦略に対応する。BatchWriteItem も 25 アイテム上限だが、
失敗時に兄弟をロールバックしない — アプリコードで UnprocessedItems を扱う。
ReturnValues は後続の GetItem なしに compare-and-swap を実装できる。アトミック
カウンターは数値属性への ADD を使う。属性横断の一意性は通常、一意値ごとの
別「ロック」アイテムと、本行への条件付き put が要る。ホットな USER#popular
パーティション上でソートキーを書き換える移行は、そのキーの物理パーティションを
共有するすべてのユーザーの書き込みをスロットルしうる — レート制限付きで
バックフィルをスケジュールし、カットオーバー前にテーブルの概要で偏りを見る。
Workbench の手順
有料トライアル付きで DynoTable をダウンロードし、書き込みを
ステージする。アイテムを編集し、diff を見直し、コミット — put/update/delete の
デフォルト経路。⌘⇧⌫ 経由のバッチ削除は直接コミットし、⌘⌫ は先にステージする。
PartiQL INSERT/UPDATE/DELETE は警告トースト付きで即実行するので、PartiQL DML は
直接書き込みパスとして扱う。
テーブルの概要はテーブルごとのアイテム数とサイズ見積もりを示し、移行前に成長が 見える。料金計算機 は、デュアルライト中に 移行が書き込みトラフィックを倍にするときの書き込み増幅をモデル化する。
無料の読み取り専用プランはクエリとエクスポートをカバーする。ステージングと コミットには有効なライセンスまたはトライアルが必要。