解答：索引數據的規划，應在前期做好規划，正所謂“設計先行，編碼在后”，
這樣才能有效的避免突如其來的數據激增導致集群處理能力不足引發的線上客戶
檢索或者其他業務受到影響。
如何調優，正如問題 1 所說，這里細化一下：
3.1 動態索引層面
基於模板+時間+rollover api 滾動創建索引，舉例：設計階段定義：blog 索
引的模板格式為：blog_index_時間戳的形式，每天遞增數據。
這樣做的好處：不至於數據量激增導致單個索引數據量非常大，接近於上線 2 的
32 次冪-1，索引存儲達到了 TB+甚至更大。
一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。
3.2 存儲層面
冷熱數據分離存儲，熱數據（比如最近 3 天或者一周的數據），其余為冷數據。
對於冷數據不會再寫入新數據，可以考慮定期 force_merge 加 shrink 壓縮操作，
節省存儲空間和檢索效率。
3.3 部署層面
一旦之前沒有規划，這里就屬於應急策略。
結合 ES 自身的支持動態擴展的特點，動態新增機器的方式可以緩解集群壓力，注
意：如果之前主節點等規划合理，不需要重啟集群也能完成動態新增的。