好的，这个compaction在什么情况下，需要这种执行
nebula基于rocksdb做的存储，rocksdb基于LSM-tree做的，LSM-tree又是分层级的，更新和删除都是新增的操作，如果存在大量更新、删除这种，可以考虑做做compaction，这样就会将多条重复的key合并成一条，减少检索时长，另外storage的LOG文件中貌似也有显示compact后的不同层级的存储情况，可以结合这个去决策要不要做compact；可以去看看rocksdb的介绍中文文档感觉写的还可以，github上有官方的文档更全面
2 个赞
好的，谢谢 
，compact后效果显著。
由于我们数据量非常小，才300多MB，原以为数据量小即使读的时候要做合并操作（真正用的tag就1千多行的数据），也没想到会影响这么大， 所以也一直没考虑过要做compact
有几个小小的疑问：
1.默认disable_auto_compactions=false 为什么没有自动做compact， compact的阈值是怎样的？
2.手动compact期间，io基本上没波动， 反而cpu上升明显， 这个操作是cpu密集型吗，不应该对io有很大影响吗？
3.只要重启storaged服务就立马变快， 重启后第一时间系统是会做compact操作的吗？
1.compact阈值，请参考rocksdb compaction文档
2.level compact需要做归并，有可能和这个有关系；另外你当时是不是有read操作，read操作的rocksb_block_cache如果太小，那么就会存在解压的操作，这个也很占cpu。最好能通过top -H -p {pid}的方式看下具体是什么消耗cpu
3.为啥重启就会变快—我也不清楚；重启第一时间是否会做compact—我觉得不会
我对nebula了解也不怎么深入，以上观点可能不准确哈
对我很有帮助， 感谢感谢 
客气
compaction 是一天之内不定期做的，
你是确定超过 24 小时，你的系统没有做 compaction 么？
你数据更新是怎么样的？频次如何？