**まず、保存データ量、リクエスト数、単一レコードへの更新のどれが偏っているかを特定します。**サーバー追加が役立つのは、過負荷の仕事をそこへ移せる場合だけです。
注文を加盟店IDで分割しているとします。大半の加盟店は小規模ですが、1社が大きなキャンペーンを始めます。そのシャードだけが過負荷になり、他は空いています。これがホットパーティション、つまり処理能力以上の仕事が集中するパーティションです。
1. キーを変更する前に偏りを測る
シャードごとにデータ量、要求頻度、遅延、CPUやディスクの負荷を比較します。次に、過負荷のシャードを加盟店と操作別に分解します。古いデータを持つ大きなシャードが暇な一方、小さなシャードが人気商品の反復更新で圧迫されることもあります。
キャンペーンでは、商品詳細の読み取り、多数の独立した注文の作成、同じ在庫レコードの反復更新のどれが負荷源かを判断します。3つは別々の対策が必要です。
2. 現在の分散で偏りが残る理由を理解する
シャードキーはレコードの配置を決めます。加盟店IDをハッシュ化すると異なる加盟店を分散できますが、同じ加盟店キーの注文は同じ配置規則に従います。ハッシュ化だけで1社の負荷が自動分割されるわけではありません。