- nebula 版本：2.0
- 部署方式（分布式 / 单机 / Docker / DBaaS）：单机
- 硬件信息
- 磁盘（ 推荐使用 SSD）
- CPU、内存信息
- 问题的具体描述
新安装2.0RPM，data里面不到100M，新建了个tag100W数据，查看data里面1.1g
,drop tag后用SUBMIT JOB Compact，内存里面变成900M
，只小了200M，想问下这个是什么原因？
当执行完毕drop tag后，只会将meta中tag相关的元数据删除，tag相关的真实数据不会立刻被删除的。
真实的数据会通过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 个赞
谢谢