drop tag内存清理问题

  • nebula 版本:2.0
  • 部署方式(分布式 / 单机 / Docker / DBaaS):单机
  • 硬件信息
    • 磁盘( 推荐使用 SSD)
    • CPU、内存信息
  • 问题的具体描述
    新安装2.0RPM,data里面不到100M,新建了个tag100W数据,查看data里面1.1gimage
    ,drop tag后用SUBMIT JOB Compact,内存里面变成900Mimage
    ,只小了200M,想问下这个是什么原因?

当执行完毕drop tag后,只会将meta中tag相关的元数据删除,tag相关的真实数据不会立刻被删除的。
真实的数据会通过compact任务删除。

有立即执行命令吗?

可以参考这个:Compact - Nebula Graph Database 手册
手动执行compact

编辑了下,手动执行过SUBMIT JOB Compact,执行后的数据是900M,重启了script,data数据有400M

执行过SUBMIT JOB Compact,我是单机版,没修改过配置,不知道是不是配置的问题

再深挖下呢? 继续向下, 会发现 data 下面还会有storage/nebula/
每个 space 下面还会有 data 和 wal 两个目录, 会不会是 wal 比较大

对,是wal目录大,wal目录600M,data的很小就70M,space里面基本没有数据

嗯, 删 wal的逻辑是写满了第三个会删. 否则就不会删.

storage/nebula目录下有1、11、17、2这4个数字,
每个表空间是在storage/nebula/目录下的1个数字代表?
我看每个数字里面包含data和wal目录,满3个是拥有3个wal还是什么满3吗?
因为会对tag反复操作,所以想了解下这块操作机制

storage/nebula/ 下面那个1是 space id, 你每次 create space 就多一个

wal 下面还会有一些 数字的目录, 那个是 partition id

进到某个 partition 下面就是具体的 wal 文件了, 这个是写满 3 个之后开始删.

2赞

是数据量到达多大后每个partitionId会自动满3吗?
1.还有就是每次drop tag后,是否需要手动执行Compact。再创建tag,如果tag里面包含同样的vertex,会不会有影响,也就是还没删除完又开始生成新的点

Q: 是数据量到达多大后每个partitionId会自动满3吗?
A: 是 wal 文件的数量满 3, 不是partition id.
partition 是您 create space 的时候就写好的, 然后平均的分布到 n 个节点上.
然后您每次做数据的操作都会写 wal 文件,
一个 wal 文件最多 16M. 当写出第三个 WAL 的时候, 就开始删了.
像您描述的这种可能是 space 比较多, partition 也比较多.

Q2: 还有就是每次drop tag后,是否需要手动执行Compact。再创建tag…

A2: 按说不用, 每天都会有自动的 compaction.
个人觉得占个几百兆的磁盘完全 OK 吧 .

1赞

谢谢

浙ICP备20010487号