tikv_number_files_at_each_level 的几个问题

banana_jian · 2022 年7 月 5 日 09:59

关于tikv_number_files_at_each_level的几个问题
1 监控中每个level的文件数是当前的文件数量么？
2 level 项中最后一个等级就是level6吗？
3 我个人在做测试的时候为什么没有捕捉到level1-5的文件有变化一直都是0？
4 level6的文件数量问什么会有减少呢？

小弟在这里先行谢过了

h5n1 · 2022 年7 月 5 日 11:29

1、是文件数量，每个CF的文件数量
2、默认层数是num_leveles参数控制，默认是7 按数字排列就是6，有的监控面板上直接叫bottommost level
3、你把监控的单位值调成none在看看，还得看数据量是否足够

4、果有大量的删除数据的话最底层的文件在compact时可能会减少文件数量

banana_jian · 2022 年7 月 6 日 00:39

谢谢
3、你把监控的单位值调成none在看看，还得看数据量是否足够
–这个我测的时候level0是有数据的奇怪的是感觉没有经过1，2，3，4，5 直接就是level6的文件数涨了
4、果有大量的删除数据的话最底层的文件在compact时可能会减少文件数量
–是说如果没有数据的删除level6的文件是会一直上涨的是么？另外还想问一下这个文件数和最终的磁盘上的sst文件有什么对应关系么？

banana_jian · 2022 年7 月 6 日 02:05

3 我个人在做测试的时候为什么没有捕捉到level1-5的 –这个我也查了数据库里的表也都是0
| 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 0 | 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 0 | 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 0 | 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 0 | 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:55:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:56:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 1 | 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:55:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:56:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:57:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:58:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:59:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 10:00:13.135000 | 192.168.135.149:20180 | default | 2 | 2022-07-06 09:50:13.135000 | 192.168.135.149:20180 | default | 6 | 2022-07-06 09:51:13.135000 | 192.168.135.149:20180 | default | 6 | 2022-07-06 09:52:13.135000 | 192.168.135.149:20180 | default | 6 | 2022-07-06 09:53:13.135000 | 192.168.135.149:20180 | default | 6 | 2022-07-06 09:54:13.135000 | 192.168.135.149:20180 | default | 6 文件有变化一直都是0？
| kv | 2 |
| kv | 2 |
| kv | 2 |
| kv | 3 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 0 |
| kv | 2 |
| kv | 2 |
| kv | 2 |
| kv | 2 |
| kv | 2 |

h5n1 · 2022 年7 月 6 日 02:14

好像是有个特性是在大批量插入数据时并不走flush/compact这些过程，而是直接将sst文件插入到最底层。

最底层文件数据如果没有删除的话是一直涨的，文件数就是磁盘的sst文件

banana_jian · 2022 年7 月 6 日 02:15

好像是有个特性是在大批量插入数据时并不走flush/compact这些过程，而是直接将sst文件插入到最底层。

-----麻烦问下这块官方文档中有介绍么？想了解一下

ddhe9527 · 2022 年7 月 6 日 02:20

LevelDB有这个特性，RocksDB是在LevelDB基础上构建的，应该也有这个特性。可以在下面文档中搜一下PickLevelForMemTableOutput这个函数

h5n1 · 2022 年7 月 6 日 02:21

HTAP萌新 · 2022 年10 月 12 日 08:59

那这个直接flush到最后一层的特性可以由参数控制吗？

HTAP萌新 · 2022 年10 月 12 日 09:04

我在用lightning批量导入数据时也遇到这个问题，请问楼主后来试着让他不要直接flush到第六层吗？

h5n1 · 2022 年10 月 12 日 09:09

应该是没有

banana_jian · 2022 年10 月 13 日 01:45

木有

system · 2022 年10 月 31 日 19:19

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。