聴きながらとったメモ

登壇者　アマゾンソリューションアーキテクト成田俊

アマゾンで買い物をするサイトはバックエンドにDynamoDBを使用している。
高速で一貫した性能。
99.999%のSLA。
DynamoDBはテーブルでデータを分割し、アイテムとしてデータを保存する。
各アイテムはアトリビュート（列）を持っているが、データごとにアトリビュートが違っていてもいい。
ソートキーはオプションだが、ソートキーをつけることで幅広い検索ができる（範囲検索とか）。
パーティションキーとソートキーを指定してGet/Put/Update/Deleteする
DynamnoDBでACIDトランザクションが可能になった。これによって複数の処理が全て成功するか全て失敗するか、という設計ができるようになった。
内部ではパーティションキーを元にItemの保存位置が決まり、スケールのためにパーテーションという単位で分散保存している。
パーテーションは３つのコピーを持つことで冗長性を確保している。
パーティションキーとソートキーだけで検索できない場合はセカンダリインデックスを使う。
LocalSecondaryIndexは同じパーティションキーでの検索に使う。
GlobalSecondaryIndexはパーティションキーをまたいで検索できる。
クライアントがテーブルに対して更新処理を行うと、GlobalIndex用のテーブルに対して非同期に更新を行う。
バーストキャパシティによって、過去300秒分で使わなかったキャパシティを使用してバーストできる。
オートスケーリングできる。
アクセスされるキーに偏りがあると負荷が偏るため、パーティションキーの設計時には書くパーティションに分散されるように考慮する必要がある。
あるパーティションに負荷が偏った場合に、Adaptive Capacity機能によって、他のパーティションのキャパシティを負荷がかかっているパーティションにもってこれる。
オンデマンドによってサーバー料金ではなく、リクエストに対して課金できる。
オンデマンドとインスタンスは運用中に設定変更で変更できる。
Scale fearlessly with amazon dynamo db adaptive... というセッションが参考になる。
「サーバーレスアプリケーション向けのDB 設計ベストプラクティス」
NoSQLは正規化しすぎると効率が落ちることがある。非正規化し、データは多少重複していてもアプリから操作しやすい構造にする。
N:MリレーションではtableとGSIによって双方向の関係性を保存する。
GSI OVERLOADINGにより、セカンダリインデックスの数の制約を超えた設計が可能になる。