primary shardはデータと処理を分割するために選び、replicaは追加コピーと検索能力を得るために選びます。普遍的なシャード数ではなく、ワークロードと復旧要件から始めます。
最初の見積もりを計算する
primaryのインデックスデータが120 GBで、テストから1 primary shardあたり約30 GBがワークロードに適すると分かったとします。
text
120 GB / 30 GB = 4 primary shards
1 replica per primary = 4 additional shard copies
Total = 8 shard copies, roughly 240 GB of shard data
これらは仮のサイジング入力です。ストレージ見積もりには増加分や、バックグラウンドでインデックスファイルをまとめるsegment mergeなどの作業領域を含めていません。
シャードを増やし続けてはいけない理由
シャードを増やすと複数ノードに処理を分散できますが、各シャードに管理負荷があり、検索先も増えることがあります。大きいシャードはその負荷を減らす一方、復旧や移動に時間がかかります。replicaは冗長性を増しますが、保存容量と書き込み処理も増え、バックアップの代わりにはなりません。
障害ケースもテストする
ピーク時の読み書きを同時に測定し、ノード喪失も試します。残りのノードには目標時間内に復旧できるディスク、メモリー、処理能力が必要です。増え続ける時系列データでは、rolloverが選んだ条件に達すると新インデックスを作り、サイズを抑えるのに役立ちます。これらの判断はシャード設定を利用者が管理する環境に適用されます。