为什么小型对象如此重要

Jonathan Symonds Jonathan Symonds on 性能 2020 年 12 月 22 日

在过去十年左右的时间里，对象存储的使用案例已经发生了相当大的演变，它们取代了传统的文件和块使用案例。特别是在处理小型数据对象的需求变得越来越普遍。是的，仍然有很多大型对象，但小型对象在特定工作负载和应用程序环境中正变得比大型对象更普遍。

传统的对象存储系统是为大型对象设计的，这些对象很少被访问。随着当今小型对象的出现，对象存储系统需要变得更加动态和活跃。对于传统系统来说，这种转变证明是困难的，甚至是不可能的。原因在于架构设计。但在此之前，让我们先定义什么是小型对象，并了解是什么推动了对它们的需要。

小型对象通常定义为小于 1MB 的对象。当对象的大小为这种尺寸时，会带来两个挑战。首先，当以规模化处理（数十 PB）时，小型对象的总数会迅速达到数十亿甚至万亿。这远远超出了传统数据存储系统的能力。其次，如此众多的对象带来了额外的挑战，即频繁的访问（LIST、PUT、GET、PUT、LIST DELETE 等）。以这种规模处理元数据管理是导致大多数系统崩溃的原因。以这种规模实现这一目标，且不会丢失数据或损害性能，是重大的挑战。

让我们将注意力转向小型对象革命的驱动因素。

AI/ML/DL 工作负载：新的 AI 驱动的应用程序用大量小型数据文件进行训练。这些文件通常只创建一次，并在训练和验证 DL 模型时多次读取，这些模型对数据进行分类、识别图像、翻译语言等。但这仅仅是获得了最初的推断模型。新数据会不断涌入。这意味着推断模型将需要使用新数据以及用于训练的原始数据的某些子集进行定期（重新）训练。所有这些训练数据都以小型对象的形式存在。例如，HDFS 使用 128MB 块作为块大小，文件本身的大小为 GB 到 TB。这与当今的流数据方法不兼容，这也是组织迁移离开 HDFS 并转向高性能对象存储的原因。
归档/备份：关于归档和备份的传统思维是，对象很大，读取不频繁。这种思维在现代数据世界中并不成立。现在，我们看到人们期望使用 1MB 块（这是 Veeam、Actifio 等的默认设置）。这种尺寸是去重环境的功能。此外，这些工作负载正在取代 SAN 存储，小型块是其优势。迁移的原因是数据规模已大幅增加，而对象存储已被证明更适合。
监控和日志数据：IT 一直都在生成大量包含各个事件的日志文件，但最近，实时处理每个事件的框架变得十分普遍。日志始终是一系列事件数据，这些数据会被批处理，并且最多只能离线处理一次，然后被清除或归档。但之后，数据分析应用程序开始分析这些数据，而批处理事件数据效果并不理想。随着分析变得越来越重要，组织希望更频繁地进行分析。使用新的框架，可以轻松地对各个事件进行分析，在某些情况下，还可以实时进行分析。由于这里采用的数据结构（JSON 文档）本质上是小型对象。
物联网应用程序：随着物联网变得越来越普遍，传感器、成像系统、应变仪等都在生成要处理的数据。对于某些物联网应用程序（例如自动驾驶汽车），必须在尽可能靠近边缘的区域实时完成这项工作，但对于其他应用程序来说，物联网数据可以被发送并被其他地方处理。即使是在边缘实时进行处理，也可能需要在其他地方进行进一步验证和分析。文本、数字和图片从定义上来说都是很小的，并且占物联网数据的很大一部分。
分析数据库：传统的数据库由大型数据集中表格和行组成。但最近，出现了一些新的数据库，它们存储和索引 JSON 或其他结构化文档数据。这包括 Elastic、Splunk 等数据库，它们的数据结构（表格段）本质上是小型且数量众多的。

这些只是新出现的小型对象现象的一些例子。其他的例子还包括 Web、移动和消息应用程序。因此，小型对象正变得越来越普遍，至少对于使用这些新应用程序、工作负载和系统的组织而言如此。

小型对象激增，这对对象存储系统意味着什么？

读写比例正在发生变化 - 从历史上看，对象存储几乎被认为是 WORM 存储或一次写入多次读取存储。是的，某些类型的小型对象数据适合作为 WORM 数据，例如 AI-ML-DL 训练数据集。但这肯定不适用于实时流数据处理，并且可能也不适用于物联网或新的文档数据库数据。
访问延迟必须缩短 - 使用 WORM 数据时，延迟可以以秒或更长时间为单位来衡量，没有人会关心。但是，对于近实时流数据处理而言，对象访问必须以每秒的对象数来衡量，而不是传统的吞吐量度量（每秒 GB）。物联网数据处理和 AI-ML-DL 训练也可能对访问延迟非常敏感。
存储效率很重要 - 大型对象通常被分成多个块，这对存储这些对象很有效。但小型对象可能远小于用于大型对象的块大小。存储效率是实际数据与原始数据容量的比值。传统的对象存储实现（以及 HDFS）依赖于对小型对象的复制（3 倍），而现代方法（如 MinIO）采用擦除编码，效率更高（12:4 是推荐的比率）。
严格一致性 - 为了实现严格一致性，所有对象必须在确认返回应用程序之前提交到存储介质中。同时实现严格一致性和低延迟是很难的，但当你使用上面概述的使用案例替换块存储系统时，这是非常必要的。

我们认为，这些使用小型对象的新应用程序、工作负载和系统代表着未来每个组织都应该发生的事情的最前沿。在某个时候，所有组织都将部署实时流数据处理、AI-ML-DL 应用程序和新的文档数据库系统。物联网可能不像这些其他活动那样普遍，但它也会随着时间的推移变得更加普遍。

挑战在于，一些对象存储系统比其他系统更适合处理小型对象。唯一真正能说明问题的方法是进行 PoC，用大量小型对象加载对象存储系统，运行使用这些对象的应用程序，然后查看其存储、性能和工作效果。只有这样，你才能很好地了解对象存储系统处理即将到来的小型对象流的效果如何。

MinIO 特别适合小型对象。这是我们设计选择的结果，而不是我们刻意为之。由于我们坚持追求简洁，因此我们拥有更少的活动部件，最显著的是没有数据库来管理元数据。

这可能是 MinIO 在小型对象领域的最大优势。

元数据数据库在功能上与大量小型对象不兼容。你无法大规模列出它们，也无法大规模删除它们。小型对象对外部元数据数据库架构具有破坏性。

世界将继续产生更多小型对象 - 这是我们知道的。作为架构师，你可能可以创建一系列解决这些问题的变通方案，但最终，采用一个能够与你的小型对象无缝扩展的对象存储是一个更好的途径 - 应该尽快采取的途径。

我们将在本文之后发布基准数据以及有关如何测量小型对象性能的说明。这将包括存储介质的详细信息以及带宽要求。

在此期间，如果您想开始，可以在此下载 MinIO。我们随时为您提供帮助，并拥有一个 Slack 频道，该频道为我们不断扩展的社区中的 10,000 多名成员提供支持。如果您需要 SLA 或 24/7 的直接工程师支持，可以在 MinIO 订阅网络中找到答案。它根据容量定价并按月计费，将为您的部署带来 MinIO 背后的工具、人才和技术。

如果您有任何问题，请随时通过 hello@min.io 与我们联系。