AWS DynamoDB パーティションキー設計
リクエストスロットリング
DynamoDB 単位で、スループットを割り当てることができる
割り当てられたスループットは、さらにパーティション単位で均等に割り当てられる
スループットがキャパシティを超えた場合、 ProvisionedThroughtputExceededException 例外が発行され、スロットリングされる
これが起こる原因は、以下。
パーティションキーが不適切で、データが不均等に分散されてしまっている
同一データへの頻繁なアクセスが行われてしまっている
割り当てられたスループットが低すぎる
つまり、パーティションキーを適切に設定し、データを分散させることが重要。
スロットリングを起こす可能性が最も小さい適切なキーを選択する。
あと、値段を下げる。
パーティションの分割戦略
1. パーティションキーをハッシュ関数に入力し、出力されたハッシュ値で、格納先のパーティションを決める
2. 10 GB を超えた場合、ソートキーでさらにパーティションを分割する
パーティションキー設計
プラクティス
高いカーディナリティを持つ attribute を利用する
つまり、分類がたくさんある要素。性別や都道府県ではなく、メールアドレスや日付等を利用するのが良い
複合プライマリキーを利用する
頻繁にアクセスされる Item をキャッシュする
パーティションから読み込ませないようにする
パーティションキーの prefix に決められた範囲の乱数/数値を利用する
大量の書き込みがある場合に有効
クエリ毎に X 回のリクエストが発生するので、読み込みに追加のレイテンシーがかかる
大小のユースケース毎にテーブルを分割する
パーティションキーあたりに多数の Item がある場合、パーティションキーは乱数がよい
パーティションキーあたりの Item 数がバラバラな場合はどうするか?
テーブルを分割する
大きいサイズの場合はサフィックスをつけ、小さいサイズの場合はつけない
アンチパターン
DB エンジンの生成するシーケンス、ユニーク ID を利用する
クエリの目的でパーティションキーを利用できず、低速になる
低いカーディナリティの attribute を利用する
独自にキーをハッシュ化する
よく考えず別 DB から DynamoDB に移行した時、よく考えずプライマリキーをそのまま移植する