【问题标题】:Reading ("tailing") the end of a huge (>300GB) gzipped text file读取(“拖尾”)一个巨大的(>300GB)压缩文本文件的结尾
【发布时间】:2021-06-09 06:15:05
【问题描述】:

我有一个文本文件,原来大小>300GB,压缩后它仍然有>10GB。 (这是一个数据库导出,运行了几天,然后被中止,我想知道最后一个导出条目的时间戳,以便恢复导出。)

我对这个文本文件的最后几行感兴趣,最好不必解压缩整个 300GB(甚至到内存中)。这个文件不再增长,所以我不需要跟踪更改或附加数据,也就是 tail -f

有没有办法只压缩文件的最后一部分?

tail --bytes=10000000 /mnt/myfile.db.gz | gunzip - |less

不起作用(它返回stdin: not in gzip format)。由于 gzip 不仅可以压缩文件,还可以压缩数据流,因此应该可以在文件中的某处搜索开始解压缩的入口点,而无需读取文件头。对吧?

【问题讨论】:

标签: linux gzip tail


【解决方案1】:

不,不对。除非专门生成 gzip 流以允许随机访问,否则解码最后几行的唯一方法是解码整个内容。

【讨论】:

  • 这很不幸,但如果 gzip 是这样设计的,那就好了。你有什么建议我下次更喜欢什么其他大文件/流压缩器,最好是低 CPU 负载,因为整个东西都在 Raspberry Pi 上运行?
  • 如果您可以控制事物的压缩方面(听起来好像没有),您可以使用 pigz 和 --independent 选项在 gzip 流中创建独立的可解压缩块。或者您可以使用 bzip2,它自然会这样做,但在压缩和解压缩时会占用更多 CPU。
  • 我是,但故意使用 gzip,因为 bzip2 慢了好几倍,并且加载了太多机器。但是以后如果再出现这种情况,我会试试pigz。谢谢!
【解决方案2】:

快速跟进我自己的问题:在没有hackery 的情况下使用gzip 是不可能的(gzip 有补丁压缩成块,您可以独立解码每个块)。

但是您可以使用xz,并且使用最低压缩比 (-0) CPU 负载与gzip 和压缩相当。而xz实际上可以解压压缩文件的一部分。

我会在未来考虑这个。

【讨论】: