我们使用 tar.bz2 作为服务器日志的存档。我们还编写了有选择地解析这些存档日志的工具。很多时候，我必须对存档中的一个文件行进行正则表达式搜索，以确定同一存档中包含的其他日志是否与解析需求相关。 （我有一个文件名/路径的正则表达式匹配）从性能的角度来看，我认为我面临一些限制。但也可能是我的知识水平有差距。我主要使用 python 编写脚本，并具有一些基本的 bash 技能。档案很大并且存储在安装上。我想尽可能避免阅读和本地/临时存储，特别是当档案不符合完整解析的条件时。
方案一（浪费带宽和CPU资源，节省本地存储）
- 将整个 bz2 文件读取到本地磁盘。
- 当我扫描文件列表时解压缩 tar。
- 再次解压缩以搜索第一个日志文件。
- 然后，如果该存档符合条件，则再次解压缩以提取我必须解析的日志。
- 转到下一个存档
或者（浪费本地存储并浪费更少的带宽）
- 将整个 bz2 文件读取到本地磁盘。
- 提取满足潜在有趣标准的大部分文件（需要获取大部分内容）
- 现在每个文件都位于我的本地文件系统上。扫描第一条日志
- 然后，如果它符合条件，则继续处理我必须解析的日志。
- 删除所有本地存储并转到下一个存档。
当我研究 7zip zip rar bz2 这样的压缩工具时……大多数链接都会为我提供有关压缩速度和压缩大小的信息。我想使用像 7zip 这样的东西，因为压缩大小从长远来看很重要。这不是我问题的基础！但我也“认为”zip 能够公开完整的文件列表并提取一个文件，而无需解压缩整个存档。 （因为文件列表位于标头中……）但是 zip 在 Linux 上并不是很原生。
有没有办法使用现有的 tar.bz2 来优化流程？我应该考虑哪些工具/方法？ （放弃 tar，使用 7zip？）
答案1
zip不是 Linux 原生的，但如果你有源代码，你可能不应该关心。
另一方面，7zip具有更好的性能，并且压缩具有相似数据的多个条目的 tar 文件比基本上一次压缩一个文件的xz压缩效果更好。zip这使得zip当一个文件损坏（由于损坏）时可以进行恢复，而压缩的 tar 存档通常有更多问题需要恢复和/或更无法恢复。
如果您有机会更改压缩的 bz2 文件生成（否则您可能不会询问），请执行以下操作而不是生成tar.bz2：
- 生成一个
index.lst使用find <list_of_files_to_archive> > index.lst - 从index.lst + list_of_files_to_archive 生成一个tar.xz
这样您就可以快速提取index.lst文件，而无需解压缩整个存档，并根据 index.lst 的内容确定您是否拥有正确的存档。我不确定标准tar在解压后是否停止index.lst（存档中可能还有另一个），因此使用 python tar 模块确保解压后停止（并且您立即解析 index.lst 文件，无需存储在磁盘上，额外加速）。