随着对象存储的使用成为云原生工作负载的主要存储类别,开发人员正在转向这项技术来满足越来越多的用例。 这是现代对象存储属性的一项功能,包括性能、可扩展性、安全性、弹性和为 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 文件的新功能。
使用大量小对象而不是少量大对象对对象存储系统提出了不同的要求。 通常,存储管理员必须根据预期使用情况和对象大小来设计和调整存储系统,例如调整块、块或缓存的属性以匹配典型的读取和写入模式。
此外,与大型对象工作负载相比,小型对象工作负载受元数据 IO 的影响更大。 Minio 通过消除对外部元数据数据库的依赖,大大减轻了这一负担。 Minio 将元数据和数据直接存储在磁盘上,以提供更高的性能和可扩展性。
传统上,每个对象都存储在 minio 中,如下所示:
bucket/
object_path/
object-name/
xl.meta part.1
这意味着为了读取数据,至少需要打开两个文件。 要写入数据,至少将写入两个文件和一个文件夹。 当处理较少的大文件时,这种开销可以忽略不计,但在处理许多对象的许多部分时,它可能会开始增加。
从 minio 2021-04-22 版本开始,服务器可以将对象内容存储为 XL。 存储每个对象的元数据元文件的一部分。 有几个因素决定了何时完成此操作,但通常小于 128kib 的文件可以与元数据内联存储。 这减少了读取和写入文件所需的 IOPS。
并非所有文件大小都启用了此功能,因为它会影响对象更改的速度。 例如,当添加新标记或发生其他属性更改时,会发生突变。 因此,为了保持更新时间合理,无需复制或重写大兆字节的数据,这仅适用于小文件。
从客户端、用户和应用程序的角度来看,这是透明的。 一切都由 Minio 管理,因此要开始优化您的小型对象存储,您唯一需要做的就是升级您的 Minio 服务器。
Minio 还增加了上传后自动提取的功能。 tar 文件的功能。
将许多小型非结构化数据文件放在对象存储上不容易被程序和用户访问。 在许多工作流和环境中,这可能是流程中最耗时的部分。 想想 ML 分析所需的数百万个传感器日志的情况,或者 NAS 迁移中数千个小型 Microsoft Excel 或 Word 文档的另一种常见情况。 如果单独上传每个文件,则在设置和断开大量连接以及同时进行数千次 API PutObject 调用时,将产生大量网络开销。 常见的解决方案是将所有文件压缩成一个大文件或 zip 包,上传,然后提取所有文件。
有了这个新功能,用户不再需要开始上传,然后再回来提取。 上传tar 文件的脚本可以简化为上传和自动提取。 应用程序和用户可以立即使用对象,而无需单独的提取步骤,从而使他们对对象存储的操作更加高效和及时。 重访传感器数据示例,TAR 文件自动提取功能可更快地将非结构化日志数据暴露给工作负载,从而实现实时异常检测。
下面是自动提取工作原理的示例。 只需**最新版本的minio服务器和minio客户端并安装它们。 您甚至可以通过 MC 在我们的游戏环境中试用它。
使用任何 .tar 文件,可选择使用 zstandard(推荐)、lz4、gzip 或 bzip2 进行压缩。
mc mb play/mybucket
mc cp .tar play/mybucket --disable-multipart --attr "x-amz-meta-snowball-auto-extract=true"
mc ls play/mybucket
就是这样!您正在尝试使用minio简单、透明和强大的功能来处理小对象。 等效的 API 调用是 PutObjectExtract。
如果您有任何具体问题,请通过以下方式与我们联系hi@minioorg.给我们留言或加入 Slack 上的对话。