GET _cat/indices/post?vhealth status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open post_two vVGUNqf9RfyqPwIei7VD4A 5 2 10011876 2774293 12.2gb 3.9gb
/** Expert: scores one merge; subclasses can override. */protected MergeScore score(List<SegmentCommitInfo> candidate, boolean hitTooLarge, long mergingBytes, IndexWriter writer) throws IOException {long totBeforeMergeBytes = 0;long totAfterMergeBytes = 0;long totAfterMergeBytesFloored = 0;for(SegmentCommitInfo info : candidate) {final long segBytes = size(info, writer);totAfterMergeBytes += segBytes;totAfterMergeBytesFloored += floorSize(segBytes);totBeforeMergeBytes += info.sizeInBytes();}// Roughly measure "skew" of the merge, i.e. how// "balanced" the merge is (whether the segments are// about the same size), which can range from// 1.0/numSegsBeingMerged (good) to 1.0 (poor). Heavily// lopsided merges (skew near 1.0) is no good; it means// O(N^2) merge cost over time:final double skew;//這里如果大段置位了，也就是這一組曾經(jīng)超過過大段，雖然后來又替換，但是應(yīng)該是接近大段的。這樣下次就不用合并了，所以給的優(yōu)先級比較高// 這樣的話就會給更高的優(yōu)先級if (hitTooLarge) {// Pretend the merge has perfect skew; skew doesn't// matter in this case because this merge will not// "cascade" and so it cannot lead to N^2 merge cost// over time:skew = 1.0/maxMergeAtOnce;} else {//對于其他情況，就用這個組合中最大的segment的size 除以組合內(nèi)所有元素的size,理論上除非組合中所有元素一樣大，否則，skew肯定大于0.1, 段的差異越大，這個值越大skew = ((double) floorSize(size(candidate.get(0), writer)))/totAfterMergeBytesFloored;}// Strongly favor merges with less skew (smaller// mergeScore is better):// mergeScore 越小越好double mergeScore = skew;// Gently favor smaller merges over bigger ones. We// don't want to make this exponent too large else we// can end up doing poor merges of small segments in// order to avoid the large merges://對merge后的總量size取指數(shù)運算,這樣說來，合并后總量越大對應(yīng)計算的mergeScore越大，優(yōu)先級也就越低， 越小則優(yōu)先級越高，但是，因為指數(shù)很小，所以影響不是很大，也就是更偏向于先合并小段// 輕輕地偏愛較小的合并而不是較大的合并，我們不想使此指數(shù)太大，否則我們最終可能會因為為了避免大合并而對小段進行不良合并mergeScore *= Math.pow(totAfterMergeBytes, 0.05);// Strongly favor merges that reclaim deletes://這個是保留率，就是刪除以后的總量和執(zhí)行刪除前的總量final double nonDelRatio = ((double) totAfterMergeBytes)/totBeforeMergeBytes;//這里看對壓縮比還是比較重視的，保有率越低越好，reclaimDeletesWeight是一個設(shè)置值，用來控制壓縮率在打分中所占的權(quán)重，默認是2，建議的是不超過3，如果是0的話，壓縮率就不影響打分了mergeScore *= Math.pow(nonDelRatio, reclaimDeletesWeight);final double finalMergeScore = mergeScore;return new MergeScore() {@Overridepublic double getScore() {return finalMergeScore;}@Overridepublic String getExplanation() {return "skew=" + String.format(Locale.ROOT, "%.3f", skew) + " nonDelRatio=" + String.format(Locale.ROOT, "%.3f", nonDelRatio);}};}
