MinIO优化小对象存储并增加.tar自动解压

随着对象存储使用成为云原生工作负载的主要存储类别，开发人员正在转向这项技术来满足越来越多的用例。这是现代对象存储属性的函数——性能、可扩展性、安全性、弹性和为 Kubernetes 量身定制的 RESTful API。特别是，MinIO 是这些属性的体现，可以支持各种位置的各种任务——本地、边缘，或者私有云、公共云或混合云。    

早期的对象存储平台是为归档大对象而设计和构建的，通常作为备份作业的目标。尽管对于大文件的高带宽访问非常出色，但这些系统在处理涉及对许多小文件的操作的工作负载方面遇到了困难（并将继续努力）。特别是，访问每个文件的数据需要首先访问元数据服务器（用于映射信息和其他设置），然后访问物理存储。对于大文件，与完全加载完整大文件所需的时间相比，每个文件一次元数据访问所带来的延迟几乎可以忽略不计。然而，对于许多小文件，元数据服务器访问基本上会使数据访问的延迟增加一倍，成为整个对象存储系统的瓶颈。

只要对象存储被视为二级或存档层，这就不是什么大问题。然而，随之而来的是 Amazon S3，它带有一组 API 和端点，可将对象存储弹射到应用程序数据的家中。随着时间的推移，对象存储的应用程序用例不断扩大，如今它们正在推动对不同对象大小的更高性能和灵活性的需求。小对象对于支持 AI/ML/DL 工作负载、重复数据删除存档/备份、监控和日志数据、IoT 应用程序、分析数据库等至关重要。

并非每个对象存储系统都能够在各种对象大小和访问模式下实现极高的性能和弹性。许多小对象将传统对象存储系统推向了极限，要求低延迟读写操作。以严格一致、性能优化和有效使用物理存储的方式提供数千个并发对象操作是一个具有挑战性的问题。由于在复制文件时为越来越多的文件副本提供元数据而使系统负担过重，从而使问题更加复杂。为大型物体设计和优化的系统无法满足这些要求，并且在被迫进入它们时提供次优体验。

依赖于大量非结构化数据（例如 AL/ML/DL）的工作负载说明了对象存储面临的挑战。例如，机器学习工作负载可能会寻找传感器数据中的异常，检查数百万或数十亿的小日志文件。这是大量的元数据和文件数据访问调用，这甚至不是一个复杂的工作负载，但对许多对象存储系统的需求可能会使元数据服务器和集群网络不堪重负，从而无法实时利用工作负载的结果.

与其他对象存储解决方案不同，MinIO 不依赖于外部元数据数据库。当面临跨大量对象的许多并发查询和操作时，元数据数据库可能会变得无响应。移除这种依赖使得 MinIO 可以更快地处理大量小对象。

MinIO 继续扩大其在小对象领域的领先地位，增加了多项功能，为小对象存储和检索提供更高的性能和可扩展性。MinIO 现在包括优化的小对象存储，具有内联元数据/数据以及上传和自动提取 .tar 文件的能力。结合元数据和小对象数据极大地提高了性能，因为在元数据和数据之间不会引入延迟。自动提取 .tar 文件使处理许多小对象的效率更高，只需将小数据文件归档在一起，上传它们，它们就可用于应用程序工作负载。

首先，让我们来看看存储和检索大量小对象所固有的一些困难，然后我们可以深入了解 MinIO 如何优化这些操作以及我们在 MinIO 客户端和 .tar 和 .zip 文件上使用的新功能服务器。

小物体的大挑战

处理大量小对象而不是少量大对象对对象存储系统提出了不同的要求。通常，存储管理员必须根据预期的使用情况和对象大小来设计和调整存储系统，例如调整块、块或缓存大小的属性以匹配典型的读/写模式。

此外，与大对象工作负载相比，小对象工作负载受元数据 I/O 的影响更大。MinIO 通过消除对外部元数据数据库的依赖，减轻了大部分负担。MinIO 将元数据和数据直接存储在磁盘上，以提供更高的性能和可扩展性。

传统上，每个对象在 MinIO 中存储为：

bucket/
   object_path/
      object-name/
         xl.meta  <<-- Metadata
         data-uuid/
	         Part.1  <<-- Object content
	         Part.2 (up to 10000 parts for multipart objects)

这意味着为了读取数据，至少需要打开两个文件。要写入数据，至少会写入两个文件和一个文件夹。这种开销在处理较少的大文件时可以忽略不计，但在处理许多对象的许多部分时可能会开始累积。

更高效的小对象存储和检索

从MinIO 的 2021-04-22 版本开始，服务器可以将对象内容存储为存储每个对象元数据的 xl.meta 文件的一部分。一些因素决定何时完成此操作，但通常小于 128KiB 的文件可能会与元数据内联存储。这减少了读取和写入文件所需的 IOPS。

这并非对所有文件大小都启用，因为它会影响对象的突变速度。例如，当添加新标签或其他属性发生变化时，就会发生突变。因此，为了保持合理的更新时间并且不需要复制或重写许多兆字节的数据，这仅适用于小文件。

从客户端、用户和应用程序的角度来看，这是透明的。一切都由 MinIO 管理，因此开始优化小对象存储所需的唯一事情就是升级 MinIO Server。

.tar 文件的自动提取

MinIO 还添加了上传后自动提取 .tar 文件的功能。  

将许多小的非结构化数据文件放在对象存储上供应用程序和用户访问并不容易。在许多工作流和环境中，这可能是流程中最耗时的部分。想想 ML 分析所需的数百万个传感器日志的情况，或者 NAS 迁移中数千个小型 Microsoft Excel 或 Word 文档的另一个常见情况。如果单独上传每个文件，那么在设置和拆除大量连接时会产生大量网络开销，同时进行数千次 API PutObject 调用。一种常见的解决方案是将所有文件一起压缩成一个大文件或 tarball，上传它，然后提取所有文件。

有了这个新功能，用户不再需要开始上传然后再回来进行提取。上传 .tar 文件的脚本可以简化为上传和自动提取。应用程序和用户无需单独的提取步骤即可立即使用对象，从而使开发人员及其代码对对象存储的操作更高效、更及时。重新审视传感器数据示例，.tar 文件自动提取通过更快地将非结构化日志数据暴露给工作负载，使实时异常检测成为可能。

行动中的小对象支持

这是自动提取如何工作的示例。只需下载最新版本的 MinIO 服务器和 MinIO 客户端并安装它们。您甚至可以play通过下载mc.

使用任何 .tar 文件，可选择使用 Zstandard（推荐）、lz4、gzip 或 bzip2 压缩。

mc mb play/mybucket
mc cp <path-to-archive>.tar play/mybucket --disable-multipart --attr "X-Amz-Meta-Snowball-Auto-Extract=true"
mc ls play/mybucket

而已！您正在尝试使用 MinIO 的简单、透明和强大的功能来处理小对象。等效的 API 调用是PutObjectExtract.