GC in level_merge about titan HOT 6 CLOSED

Just rewrite the still valid kv in a new blob file in next merge. So level_merge would increase write amplification.

from titan.

yes,i know.but I still have 2 questions
1.But if I don’t set a gc tag to this vtable, it still involve in a merge if it Has compaction related keys.
2.only valid compaction related keys can be rewritten，if some keys never involves in a compaction，the vtable still contains valid values even though the portion is small，and we cant delete the vtable. how can we solve the problem，this may cause huge space amplification

from titan.

yes,i know.but I still have 2 questions 1.But if I don’t set a gc tag to this vtable, it still involve in a merge if it Has compaction related keys. 2.only valid compaction related keys can be rewritten，if some keys never involves in a compaction，the vtable still contains valid values even though the portion is small，and we cant delete the vtable. how can we solve the problem，this may cause huge space amplification

vtable means blobfile here

from titan.

1. Yes, check ShouldMerge
2. That's true. We have observed it in tests. It has huge space amplification for update intensive workload. That's why it's not GA.

from titan.

1. Yes, check ShouldMerge
2. That's true. We have observed it in tests. It has huge space amplification for update intensive workload. That's why it's not GA.

thanks，but i noticed that when I open db, a regular gc Thread will be initialized (it will quit and never call again if no file needs go).even we enable level Merge, I found that when I
reopen a db，this regular gc thread will be initialized and clean some blob files which meet threshold. But if open a new db（level merge enable），this thread will be initialized and quit quickly，cant do regular gc in the future unless i reopen the db

from titan.

Level merge is a alternative to regular gc, so need to call background gc if level merge enabled

from titan.