MinIO小文件优化：MinIO 优化小对象存储并添加 .tar 自动提取

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

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

只要对象存储被看作是辅助层或归档层，这就不是什么大问题。然而，随之而来的是 Amazon S3，它提供了一组 API 和终端节点，将对象存储提升到应用程序数据的主页中。随着时间的流逝，对象存储的应用用例不断扩展，如今，它们正在推动对不同对象大小的更高性能和灵活性的需求。小对象对于支持 AI/ML/DL 工作负载、重复数据删除存档/备份、监控和日志数据、IoT 应用程序、分析数据库等至关重要。

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

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

与其他对象存储解决方案不同，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 调用时，会产生大量网络开销。常见的解决方案是将所有文件一起压缩成一个大文件或压缩包，上传它，然后提取所有文件。

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

小对象支持在行动

下面是自动提取工作原理的示例。只需下载最新版本的 MinIO 服务器和 MinIO 客户端并安装它们。您甚至可以通过下载 mc 来使用我们的 play 环境进行试用。

使用任何 .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 。

如果你有任何具体问题，请拔打我们的电话：4008-566-339给我们留言。