任何可搜索的压缩库？

Posted 2023-03-06

【中文标题】任何可搜索的压缩库？

【英文标题】：Any seekable compression library?

【发布时间】：2010-01-12 03:39:17

【问题描述】：

我正在寻找一个在解压过程中支持随机访问的通用压缩库。我想将***压缩成单一的压缩格式，同时我想从中解压缩/提取单个文章。

当然，我可以单独压缩每篇文章，但这不会提供太大的压缩比。我听说 LZO 压缩文件由许多可以单独解压缩的块组成，但我还没有找到 API+文档。我也可以在zlib中使用Z_FULL_FLUSH模式，但是还有其他更好的选择吗？

【问题讨论】：

如果您想要随机访问，您可能不得不以一种或另一种方式对输入进行分块。有什么比按文章更好的分块方式？

...几乎所有压缩库都支持，文章相当于一个文件条目。

另外...我怀疑单个文章的压缩率与整个文章的压缩率之间会有很大差异，因为它们应该具有基本相同的字母出现率。您是否对该声明进行了基准测试？

单独压缩文章的问题在于您最终会得到一整批文件，这本身就会导致效率低下。比如说，一个 1G 的文件将比拥有 80,000 个平均每个大约 10K 的文件更节省空间和易于使用，即使它是更大的压缩。

【参考方案1】：

xz-format 文件支持索引，但默认情况下索引没有用。我的压缩器pixz 创建包含有用索引的文件。您可以使用liblzma库中的函数来查找哪个xz数据块对应于未压缩数据中的哪个位置。

【讨论】：

看起来是一个很有前途的项目。谢谢。

我每天都使用pixz。这很棒。谢谢！

【参考方案2】：

对于 gzip 上的可搜索压缩构建，有来自 dict 服务器的 dictzip 和来自 sleuth kit 的 sgzip

请注意，您不能写入其中任何一个，并且可以以任何方式读取

【参考方案3】：

DotNetZip 是 .NET 的 zip 存档库。

使用 DotNetZip，您可以随机引用 zip 中的特定条目，并且可以无序解压缩它们，并且可以在提取条目时返回解压缩的流。

凭借这些功能的优势，DotNetZip 已在 Virtual Path Provider for ASP.NET 的实现中使用，它完全符合您的描述 - 它从压缩的 ZIP 文件为特定网站提供所有内容。您还可以使用动态页面 (ASP.NET) 页面制作网站。

ASP.NET ZIP Virtual Path Provider, based on DotNetZip

重要的代码如下所示：

namespace Ionic.Zip.Web.VirtualPathProvider

    public class ZipFileVirtualPathProvider : System.Web.Hosting.VirtualPathProvider
    
        ZipFile _zipFile;

        public ZipFileVirtualPathProvider (string zipFilename) : base () 
            _zipFile =  ZipFile.Read(zipFilename);
        

        ~ZipFileVirtualPathProvider ()  _zipFile.Dispose (); 

        public override bool FileExists (string virtualPath)
        
            string zipPath = Util.ConvertVirtualPathToZipPath (virtualPath, true);
            ZipEntry zipEntry = _zipFile[zipPath];

            if (zipEntry == null)
                return false;

            return !zipEntry.IsDirectory;
        

        public override bool DirectoryExists (string virtualDir)
        
            string zipPath = Util.ConvertVirtualPathToZipPath (virtualDir, false);
            ZipEntry zipEntry = _zipFile[zipPath];

            if (zipEntry != null)
                return false;

            return zipEntry.IsDirectory;
        

        public override VirtualFile GetFile (string virtualPath)
        
            return new ZipVirtualFile (virtualPath, _zipFile);
        

        public override VirtualDirectory GetDirectory (string virtualDir)
        
            return new ZipVirtualDirectory (virtualDir, _zipFile);
        

        public override string GetFileHash(string virtualPath, System.Collections.IEnumerable virtualPathDependencies)
        
            return null;
        

        public override System.Web.Caching.CacheDependency GetCacheDependency(String virtualPath, System.Collections.IEnumerable virtualPathDependencies, DateTime utcStart)
        
            return null;
        
    

而VirtualFile是这样定义的：

namespace Ionic.Zip.Web.VirtualPathProvider

    class ZipVirtualFile : VirtualFile
    
        ZipFile _zipFile;

        public ZipVirtualFile (String virtualPath, ZipFile zipFile) : base(virtualPath) 
            _zipFile = zipFile;
        

        public override System.IO.Stream Open () 
        
            ZipEntry entry = _zipFile[Util.ConvertVirtualPathToZipPath(base.VirtualPath,true)];
            return entry.OpenReader();
        
    

【参考方案4】：

bgzf 是基因组学中使用的格式。 http://biopython.org/DIST/docs/api/Bio.bgzf-module.html

它是 samtools C 库的一部分，实际上只是一个简单的 gzip hack。如果您不想使用 samtools C 实现或 picard java 实现，您可以自己重新编写它。 Biopython 实现了一个 python 变体。

【讨论】：

它看起来像是在 zlib 之上的一个简单的包装库。数据被分成 64k 块并独立压缩。但我想一个可以获得更好的压缩比。

这只是一个简单的 hack，但它开箱即用，并且有一个有用的命令行工具。您可能可以获得更好的压缩效果，但这是目前可行的方法。

【参考方案5】：

您尚未指定您的操作系统。是否可以将您的文件存储在操作系统管理的压缩目录中？然后您将拥有“可搜索”部分以及压缩。 CPU 开销将为您处理不可预知的访问时间。

【讨论】：

我更喜欢不同操作系统之间的可移植库。压缩文件系统当然是一种解决方案，但它在随机访问下是否表现良好（在速度和内存方面）？

您正在以空间换取速度。压缩成本。

@NoRefundsNoReturns 至少今天的磁盘驱动器与 CPU 相比是如此缓慢，以至于从压缩文件系统中读取速度更快（至少在 ZFS 上），除非每个 CPU 的 CPU 负载已经大于 1。

谢谢。我迫不及待地想看看 2030 年的读者会怎么说。是否有用于拖钓十年前评论的徽章？如果没有，我可以为这个成就推荐Through the years吗？

【参考方案6】：

不幸的是，我使用的是 MS Windows Vista，我可以将文件资源管理器发送到 zip 文件中，就像它们是普通文件一样。大概它仍然适用于 7 （我想加入）。我想我也用 Ubuntu 上的相应实用程序做到了这一点，但我不确定。我想我也可以在 Mac OSX 上测试它。

【参考方案7】：

如果单个文章太短而无法获得合适的压缩率，那么下一个最简单的方法是压缩一批 Wikipedia 文章 - 例如，一次 12 篇文章，或者填满一篇文章需要多少篇文章兆字节。 然后独立压缩每个批次。

原则上，这比单独压缩每篇文章的压缩效果更好，但比所有文章的整体压缩效果更差。 从压缩批次中提取第 12 篇文章需要解压缩整个批次（然后将前 11 篇文章丢弃），但这仍然比解压缩一半 Wikipedia 快得多。

许多压缩程序将输入流分解为一系列“块”，并独立于其他块从头开始压缩每个块。 您还不如选择一个块大小的批处理大小——更大的批处理不会获得更好的压缩比，并且需要更长的时间来解压缩。

我已经尝试了几种方法来更轻松地开始解码中间的压缩数据库。 唉，到目前为止，与简单得多的“批处理”方法相比，我应用的“聪明”技术仍然具有更差的压缩率，并且需要更多的操作来生成解码部分。

对于更复杂的技术，您可以查看

MG4J：Managing Gigabytes for Java “Managing Gigabytes: Compressing and Indexing Documents and Images”，作者：Ian H. Witten， Alistair Moffat 和 Timothy C. Bell