在 AI/ML 工作负载中处理小对象

随着 MinIO 企业对象存储的使用成为云原生工作负载的主要存储，开发人员正在转向对象存储来满足越来越多的用例。这是现代对象存储属性的功能 - 性能、可扩展性、安全性、弹性和为 Kubernetes 量身定制的 RESTful API。特别是，MinIO Enterprise Object Store 是这些属性的体现，可以支持各种位置的各种任务 - 本地、边缘或私有云、公共云或混合云。早期的对象存储平台是为存档大型对象而设计和构建的，通常作为备份作业的目标。尽管这些系统非常适合对大文件进行高带宽访问，但这些系统在处理涉及许多小文件操作的工作负载方面遇到了困难（并将继续努力）。特别是，访问每个文件的数据需要首先访问元数据服务器（用于映射信息和其他设置），然后访问物理存储。对于大型文件，与完全加载完整大型文件所需的时间相比，每个文件一次元数据访问引入的延迟几乎可以忽略不计。然而，对于许多小文件，元数据服务器访问基本上会使数据访问的延迟增加一倍，并成为整个对象存储系统的瓶颈。

并非每个对象存储系统都能够在各种对象大小和访问模式中实现极致的性能和弹性。许多小型对象将传统对象存储系统推向极限，需要低延迟的读写操作。以严格一致、性能优化和有效使用物理存储的方式提供数千个并发对象操作是一个具有挑战性的问题。在复制文件时，为越来越多的文件副本提供元数据，使系统负担重，使问题变得更加复杂。为大型对象设计和优化的系统无法满足这些要求，并且在被迫使用时提供次优体验。依赖于大量非结构化数据（如 AL/ML/DL）的工作负载说明了对象存储面临的挑战。例如，ML 工作负载可能会查找传感器数据中的异常，检查数百万或数十亿个小型日志文件。这是大量的元数据和文件数据访问调用，这甚至不是一个复杂的工作负载，但对许多对象存储系统的需求可能会使元数据服务器和集群网络不堪重负，从而无法实时利用工作负载的结果。与其他对象存储解决方案不同，MinIO Enterprise Object Store 不依赖于外部元数据数据库。元数据数据库在面对大量对象的大量并发查询和操作时，可能会变得无响应。删除此依赖项可使 MinIO 更快地处理大量小对象。

MinIO 继续扩大其在小对象领域的领导地位，增加了多项功能，为小对象存储和检索提供更高的性能和可扩展性。MinIO Enterprise Object Store 包括优化的小型对象存储，具有内联元数据/数据，并且能够立即上传和自动提取 .tar 文件。将元数据和小对象数据组合在一起可以大大提高性能，因为元数据和数据之间不会引入来回延迟。自动提取.tar文件可以更高效地处理许多小对象，只需将小数据文件存档在一起，然后上传它们，它们就可以用于应用程序工作负载。首先，让我们看看存储和检索大量小对象所固有的一些困难，然后我们可以深入研究 MinIO 如何优化这些操作以及我们在 MinIO 客户端和服务器上处理 .tar 和 .zip 文件的新功能。

小物体中的大挑战

与使用大量大型对象相比，使用大量大型对象对对象存储系统提出了不同的要求。通常，存储管理员必须根据预期的使用情况和对象大小来设计和调整存储系统，例如调整块、块或缓存大小的属性以匹配典型的读/写模式。此外，与大型对象工作负载相比，小型对象工作负载受元数据 I/O 的影响更大。MinIO Enterprise Object Store 通过消除对外部元数据数据库的依赖，在很大程度上减轻了这种负担。MinIO 将元数据和数据直接存储在磁盘上，以提供更高的性能和可扩展性。传统上，每个对象都存储在 MinIO Enterprise Object Store 中：

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

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

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

有几个因素决定了何时完成此操作，但通常小于 128KiB 的文件可能会与元数据内联存储。这会降低读取和写入文件所需的 IOPS。并非所有文件大小都启用此功能，因为它会影响对象的更改速度。例如，当添加新标签或其他属性更改时，会发生突变。因此，为了保持合理的更新时间并且不需要复制或重写数兆字节的数据，这仅适用于小文件。从客户端、用户和应用程序的角度来看，这是透明的。一切都由 MinIO Enterprise Object Store 管理，因此开始优化小型对象存储唯一需要做的就是升级 MinIO Server。

自动提取 .tar 文件

该功能还包括在上传后自动提取 .tar 文件的能力。将许多小型非结构化数据文件放在对象存储上供应用程序和用户访问并不容易。在许多工作流和环境中，这可能是流程中最耗时的部分。想想 ML 分析需要数百万个传感器日志的情况，或者 NAS 迁移中数千个小型 Microsoft Excel 或 Word 文档的另一个常见情况。如果您单独上传每个文件，则在设置和关闭大量连接时，在进行数千个 API PutObject 调用时，会产生大量的网络开销。一种常见的解决方案是将所有文件一起压缩成一个大文件或 tarball，上传它，然后提取所有文件。借助此功能，用户不再需要开始上传，然后稍后返回进行提取。上传 .tar 文件的脚本可以简化为上传和自动提取。应用程序和用户无需单独的提取步骤即可立即使用对象，从而使开发人员及其代码对对象存储的操作更加高效和及时。重新审视传感器数据示例，.tar文件自动提取功能通过更快地将非结构化日志数据暴露给工作负载，使实时异常检测成为可能。

小物体支持的实际应用

下面是自动提取工作原理的示例。只需下载最新版本的 MinIO Enterprise Object Store 和 MinIO Enterprise Client 并安装它们。您甚至可以通过下载 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 。