- 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的大小
- Shard 的大小 /
本作品採用《CC 協議》，轉載必須註明作者和本文連結