lesson08中addSplits的粒度感觉还是table而不是key

[Badb-Lee]

addSplits函数代码如下：

// 并行的运行子压缩情况
func (lm *levelManager) addSplits(cd *compactDef) {
	cd.splits = cd.splits[:0]
	// Let's say we have 10 tables in cd.bot and min width = 3. Then, we'll pick
	// 0, 1, 2 (pick), 3, 4, 5 (pick), 6, 7, 8 (pick), 9 (pick, because last table).
	// This gives us 4 picks for 10 tables.
	// In an edge case, 142 tables in bottom led to 48 splits. That's too many splits, because it
	// then uses up a lot of memory for table builder.
	// We should keep it so we have at max 5 splits.
	width := int(math.Ceil(float64(len(cd.bot)) / 5.0))
	if width < 3 {
		width = 3
	}
	skr := cd.thisRange
	skr.extend(cd.nextRange)
	addRange := func(right []byte) {
		skr.right = utils.Copy(right)
		cd.splits = append(cd.splits, skr)
		skr.left = skr.right
	}
	for i, t := range cd.bot {
		// last entry in bottom table.
		// 最后一个range分配无穷大的空间
		if i == len(cd.bot)-1 {
			addRange([]byte{})
			return
		}
		// 这里实现的是每(cd.bot/5)个合并成一个
		if i%width == width-1 {
			// 设置最大值为右区间
			right := utils.KeyWithTs(utils.ParseKey(t.ss.MaxKey()), math.MaxUint64)
			addRange(right)
		}
	}
}

视频讲解当中有一个细节优化是在切片时，以key为粒度进行划分，目的是为了减少划分后table之间的key重叠，提高效率（我感觉除了l0层，应该也不会有key重叠），但是代码里面，for循环中还是以cd.bot中的table来进行遍历，这里感觉还是以table为粒度来进行划分，请问是这样的吗？

[kebukeYi]

func (lm *levelManager) subcompact(it utils.Iterator, kr keyRange, cd compactDef, inflightBuilders *utils.Throttle, res chan<- *table) {
for it.Valid() {
key := it.Item().Entry().Key
// 我感觉是这里做了处理, 不在这个key区间的, 直接退出; 虽然这个key区间是根据 bot[] 划分而来;
if len(kr.right) > 0 && utils.CompareKeys(key, kr.right) >= 0 {
break
}
// It was true that it.Valid() at least once in the loop above, which means we
// called Add() at least once, and builder is not Empty().
if builder.empty() {
// Cleanup builder resources:
builder.finish()
builder.Close()
continue
}
if err := inflightBuilders.Do(); err != nil {
// Can't return from here, until I decrRef all the tables that I built so far.
break
}
// 充分发挥 ssd的并行 写入特性, 有疑问;
go func(builder *tableBuilder) {
defer inflightBuilders.Done(nil)
defer builder.Close()
var tbl *table
newFID := atomic.AddUint64(&lm.maxFID, 1) // compact的时候是没有memtable的，这里自增maxFID即可。
// TODO 这里的sst文件需要根据level大小变化
sstName := utils.FileNameSSTable(lm.opt.WorkDir, newFID)
tbl = OpenTable(lm, sstName, builder)
if tbl == nil {
return
}
res <- tbl
}(builder)
}
}

其实看到这里源码, 我也有一个新的问题: 这个压缩方法会在每一个keyRange区间最低生成一个sstTable, 根本不会将多个处在 不同keyRange的entry 合并到 同一个sstTable中; 假如keyRange1区间的entry只有几个,那么只要 对应的builder不为空,那么也就会创建新的sstTable, 不会跟下一个keyRange1区间的entry进行合并; 这样会不会导致 sstTable数量增多?