lighting 两种数据导入模式,导入后数据差异很大,什么原因导致的啊

【 TiDB 使用环境】测试
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】

逻辑导入
Image
物理导入


记录统计是一样的

数据大小和region数据量都有明显差异,请问这是什么原因导致的

逻辑导入只有数据,物理导入把一些对象啊什么的,都导入进去了,所以物理的更大

没看清楚,你这是逻辑导入后的数据更大吗

所以啊,我在找原因啊

是的,逻辑导入比物理导入大,所以想问一下愿意是啥啊

那可能就是丢数据了

有可能,我更想知道物理导入会不会是压缩了

压缩有专门的参数,你自己在测试环境导出再导入的话,看看命令里有没有添加压缩的参数

没有添加压缩命令

先检查下数据量如何了

目前正在跑批统计,有一大表数据记录是相同的

数据统计出来了,结果文件md5sum 一致,这就更奇怪了

tikv 本身对数据就会进行压缩,lightning 物理模式会对数据进行排序后再导入 tikv,所以压缩效果会比逻辑模式好一些。

checksum 成功了不用担心数据损失,本来不同的插入方式插入 tikv 之后最终的存储大小都是会有误差的,这很正常。

1 个赞

具体说明文档可以给一下吗,谢谢

物理模式是直接操作tikv,逻辑模式是走tidb-server,然后再转到tikv,相对来说物理模式更快,占用空间更小,但是限制条件也更高

限制问题我看到了,正因如此我才做了逻辑和物理模式之间对吧,物理模式占用空间少,具体文档说明有吗?谢谢

物理导入直接把排序好的sst文件插入 ,之间没有重复,数据比较紧密,region内包含的数据量多 region也就少。逻辑导入是lsm从上到下合并,按理说导入都是插入数据的话应该差异不会太大, 导入过程region 分裂 并不是每个region数据都那么多所以region数量会多。猜测可能情况是region分裂后会导致有sst文件冗余(虽然没数据),可以对逻辑导入的库做下compact 看看收缩量(可能需要多次执行)
tikv-ctl --host xxxx:20160 compact -c write -d kv --bottommost force --threads 8
tikv-ctl --host xxxx:20160 compact -c default -d kv --bottommost force --threads 8

同一套集群,逻辑集群已经清理了

其实不用纠结这个,只要总数据数量和数据内容一致就行,两种不同的导入模式,难免会有原理或者压缩方式有所不同,有所出入也正常。就算同一种导入方式,操作几次可能数据都有不同。你使用 sync-diff-inspector工具比较下数据就行了

lighting local 模式导入是 compact 之后的,逻辑模式会等集群 compact 压缩。