段合併優化及注意事項

• Lucene Index 原理回顧
  • 在 Lucene 中，單個倒排索引檔案被稱為 Segment。Segment 是自包含的，不可變更的。 多個 Segments 彙總在一起，稱為 Lucene 的 Index，其對應的就是 ES 中的 Shard
  • 當有新文件寫入時，並且執行 Refresh，就會生成一個新 Segment。 Lucene 中有一個文 件，用來記錄所有 Segments 資訊，叫做 Commit Point。查詢時會同時查詢所有 Segments，並且對結果彙總。
  • 刪除的文件資訊，儲存在 “.del” 檔案中，查 詢後會進行過濾。
  • Segment 會定期 Merge，合併成一個，同時刪 除已刪除文件

• ES 和 Lucene 會自動進行 Merge 操作

• Merge 操作相對比較重，需要優化，降低對系統的影響

• 優化點一：降低分段產生的數量/頻率

  • 可以將 Refresh Interval 調整到分鐘級別 / indices.memory.index_buffer_size (預設是 10%)
  • 儘量避免文件的更新操作

• 優化點二：降低最大分段大小，避免較大的分段繼續參與 Merge，節省系統資源。（最終會有多個分段）

  • Index.merge.policy.segments_per_tier，預設為 10， 越小需要越多的合併操作
  • Index.merge.policy.max_merged_segment, 預設 5 GB， 操作此大小以後，就不再參與後續的合併操作

• 當 Index 不再有寫入操作的時候，建議對其進行 force merge
  • 提升查詢速度 / 減少記憶體開銷
    
• 最終分成幾個 segments 比較合適？
  • 越少越好，最好可以 force merge 成 1 個，但是，Force Merge 會佔用大量的網路，IO 和 CPU
  • 如果不能在業務高峰期之前做完，就需要考慮增大最終的分段數
    • Shard 的大小 / Index.merge.policy.max_merged_segment 的大小

本作品採用《CC 協議》，轉載必須註明作者和本文連結