关于tikv_number_files_at_each_level的几个问题
1 监控中每个level的文件数是当前的文件数量么？
2 level 项中最后一个等级就是level6吗？
3 我个人在做测试的时候为什么没有捕捉到level1-5的文件有变化一直都是0？
4 level6的文件数量问什么会有减少呢？
小弟在这里先行谢过了
1、是文件数量，每个CF的文件数量
2、默认层数是num_leveles参数控制，默认是7 按数字排列就是6，有的监控面板上直接叫bottommost level
3、你把监控的单位值调成none在看看，还得看数据量是否足够
4、果有大量的删除数据的话最底层的文件在compact时可能会减少文件数量
谢谢
3、你把监控的单位值调成none在看看，还得看数据量是否足够
–这个我测的时候level0是有数据的奇怪的是感觉没有经过1，2，3，4，5 直接就是level6的文件数涨了
4、果有大量的删除数据的话最底层的文件在compact时可能会减少文件数量
–是说如果没有数据的删除level6的文件是会一直上涨的是么？另外还想问一下这个文件数和最终的磁盘上的sst文件有什么对应关系么？
3 我个人在做测试的时候为什么没有捕捉到level1-5的文件有变化一直都是0？
–这个我也查了数据库里的表也都是0
| 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 0 | kv | 2 |
| 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 0 | kv | 2 |
| 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 0 | kv | 2 |
| 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 0 | kv | 3 |
| 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:55:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:56:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 1 | kv | 0 |
| 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:55:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:56:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 2 | kv | 0 |
| 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 6 | kv | 2 |
| 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 6 | kv | 2 |
| 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 6 | kv | 2 |
| 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 6 | kv | 2 |
| 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 6 | kv | 2 |
好像是有个特性是 在大批量插入数据时并不走flush/compact这些过程，而是直接将sst文件插入到最底层。
最底层文件数据如果没有删除的话是一直涨的，文件数就是磁盘的sst文件
1 个赞
好像是有个特性是 在大批量插入数据时并不走flush/compact这些过程，而是直接将sst文件插入到最底层。
-----麻烦问下这块官方文档中有介绍么？想了解一下
LevelDB有这个特性，RocksDB是在LevelDB基础上构建的，应该也有这个特性。可以在下面文档中搜一下PickLevelForMemTableOutput这个函数
1 个赞
那这个直接flush到最后一层的特性可以由参数控制吗？
我在用lightning批量导入数据时也遇到这个问题，请问楼主后来试着让他不要直接flush到第六层吗？
应该是没有
木有
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。