我们在一个场景中使用 0.11.2 版的 Apache IoTDB 服务器,并观察到一个比应有的更大的数据目录/tsfile(大约 130 个传感器,每个传感器有 400 万个双精度值,但文件大约 200gb)。
是否存在已知问题或您有任何想法可能导致此问题的原因是如何追踪?
我们唯一能想到的可能是一些合并伪影,因为我们确实会乱序写入许多数据点,因此必须经常进行合并。
有没有关于如何调试/检查 tsfile 以了解这里发生了什么的想法或工具?
任何帮助或提示表示赞赏!
我们在一个场景中使用 0.11.2 版的 Apache IoTDB 服务器,并观察到一个比应有的更大的数据目录/tsfile(大约 130 个传感器,每个传感器有 400 万个双精度值,但文件大约 200gb)。
是否存在已知问题或您有任何想法可能导致此问题的原因是如何追踪?
我们唯一能想到的可能是一些合并伪影,因为我们确实会乱序写入许多数据点,因此必须经常进行合并。
有没有关于如何调试/检查 tsfile 以了解这里发生了什么的想法或工具?
任何帮助或提示表示赞赏!
这可能是由于压缩策略。
您可以通过两种方式解决此问题(同时不需要):
(1)升级到0.12.2版本
(2)打开iotdb-engine.properties中的配置:force_full_merge=true
原因是:
0.11.2 版本中的无序数据压缩有两种策略。
例如,
序列 TsFile 中的块:[1,3],[4,5]
无序列 TsFile 中的块:[2]
(我用[1,3]表示一个Chunk中2个数据点的时间戳)
(1)使用全合并时(重写所有数据):我们得到一个整齐的序列文件:[1,2,3],[4,5]
(2) 但是,为了加快压缩速度,我们默认使用追加合并,当我们得到一个序列 TsFile: [1,3],[4,5],[1,2,3]。在这个 TsFile 中,[1,3] 文件末尾没有元数据,是垃圾数据。
因此,如果您经常合并大量乱序数据,就会发生这种情况(获得一个非常大的 TsFile)。
新的压缩后大的 TsFile 将变得整洁。
您还可以使用 TsFileSketchTool 或 example/tsfile/TsFileSequenceRead 查看 TsFile 的结构。