为什么小物件如此重要

在过去的十年左右的时间里，对象存储用例已经取代了传统的文件和块用例而发生了长足的发展。特别地，使用小型数据对象的需求变得司空见惯。是的，仍然有很多大对象，但对于特定的工作负载和应用程序环境，小对象变得比大对象更为普遍。

传统的对象存储系统是为不经常访问的大型对象设计的。对于当今较小的对象，对象存储系统需要更加动态和活跃。对于遗留系统，这种过渡非常困难，甚至是不可能的。原因在于建筑设计。但是在开始之前，我们先定义一个小物体，然后看看是什么驱动了对它们的需求。

小对象通常可以定义为小于1MB的对象。当物体如此大时，会带来两个挑战。首先，当大规模处理（PB的10s）时，小物体的总数很快就达到了数十亿甚至数万亿。这远远超出了传统数据存储系统的能力。其次，大量的对象带来了额外的挑战-聊天的挑战（LIST，PUT，GET，PUT，LIST DELETE等）。以这种规模处理元数据管理可能会破坏大多数系统。在不丢失数据或不影响性能的情况下大规模进行此操作是一个巨大的挑战。

让我们将注意力转移到小物体革命的驱动力上：

• AI / ML / DL工作负载：新的AI驱动的应用程序已通过大量小数据文件进行了培训。它们通常创建一次并读取多次，以训练和验证用于对数据进行分类，识别图像，翻译语言等的DL模型。但这只是为您提供了一个初始的推理模型。新数据一直存在。这意味着推理模型将需要使用新数据以及选择原始数据的子集进行周期性（重新）训练。所有这些训练数据都采用小物体的形式。例如，HDFS使用128MB块作为块大小，文件大小本身为GB到TB。这与当今的流数据方法不兼容，这就是为什么组织已从HDFS转移到高性能对象存储的原因。
  
  

• 存档/备份：围绕存档和备份的传统思想是对象很大，读取次数很少。这种想法在现代数据世界中并不成立。现在，我们期望有1MB的块（这是Veeam，Actifio等的默认设置）。此大小是重复数据删除环境的函数。此外，这些工作负载正在取代SAN存储，而小块正是其优势所在。迁移的原因是数据规模增加了许多倍，并且对象存储已被证明是更合适的选择。
  
  

• 监视和日志数据： IT部门总是生成大量单个事件的日志文件，但是最近，实时处理每个单个事件的框架变得司空见惯。日志始终是事件数据的序列，这些事件数据经过分批处理，最多只能脱机处理一次，然后清除或存档。但是随后数据分析应用程序开始分析此数据，并且批处理事件数据也无法正常工作。随着分析变得越来越重要，组织希望它做得更多。使用新的框架，可以轻松地并且在某些情况下实时地对单个事件进行分析。由于此处采用的数据结构（JSON文档），它们本质上是小对象。
  

• 物联网应用：随着物联网的日益普及，传感器，成像系统，应变仪等都在生成待处理的数据。对于某些IoT应用程序（例如自动驾驶汽车），必须在尽可能靠近边缘的位置实时进行，而对于其他应用程序，则可以在其他地方发送和处理IoT数据。即使是在边缘实时进行处理，也可能需要在其他地方进行进一步的验证和分析。根据定义，文本，数字和图片很小，并且占了IoT数据的大部分。
  

• 分析数据库：传统数据库由整体数据集中的表和行组成。但是最近，出现了一些新数据库，它们可以保存和索引JSON或其他结构化文档数据。这包括诸如Elastic，Splunk和其他数据库之类的数据库，这些数据库的数据结构（表段）本来就很小且数量众多。  
  

这些只是新的小物体现象的一些示例。其他应用程序包括Web，移动和消息传递应用程序。结果，至少对于使用这些新应用程序，工作负载和系统的组织而言，小对象正在成为常态。

随着小对象的激增，这对对象存储系统意味着什么：

1. 读取：写入比率正在变化-从历史上看，对象存储几乎被认为是WORM存储或多次读取后才写入。是的，有些类型的小对象数据适合于WORM数据，例如AI-ML-DL训练数据集。但是对于运动处理中的流数据以及IoT或新文档数据库数据，肯定不是这种情况。
   

2. 访问等待时间必须缩短-使用WORM数据，可以在几秒或更长时间内测量等待时间，而无人问津。但是在运动处理中使用近乎实时的流数据时，必须在每秒对象中测量对象访问，而不是传统吞吐量（每秒GB）。物联网数据处理和AI-ML-DL培训对访问延迟也可能非常敏感。
   

3. 存储效率很重要–大型对象通常分为多个块，这对于存储这些块非常有效。但是小对象可能比用于大对象的块大小小得多。存储效率是对实际数据到原始数据容量的度量。传统的对象存储实现（和HDFS）依赖于小对象的复制（3x），而诸如MinIO之类的现代方法则采用擦除编码并且效率更高（建议比率为12：4）。
   
   

4. 严格一致性-要严格一致，必须先将所有对象提交到存储介质，然后再确认回应用程序。很难同时实现严格的一致性和低延迟，但是在为上述用例替换块存储系统时，这是非常必要的。
   

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

挑战在于某些对象存储系统要比其他对象更好地处理小对象。真实地说出的唯一方法是执行PoC，以将一堆小对象加载到对象存储系统中，并运行使用这些对象的应用程序，并查看其存储，执行和工作情况。只有这样，您才能对对象存储系统如何处理即将到来的小对象流有一个很好的了解。  

MinIO特别适合于小型对象。这是我们设计选择的副产品，不一定是我们打算要做的事情。因为我们坚持不懈地追求简单，所以活动部件更少，最显着的是缺少用于管理元数据的数据库。

这也许是MinIO在小对象领域中拥有的最大优势。

元数据数据库在功能上与大量小对象不兼容。您无法按比例列出它们，也无法按比例删除它们。小对象会腐蚀外部元数据数据库体系结构。

世界将继续生产更多的小物体-我们知道这一点。作为一名架构师，可能可以创建一系列变通办法来解决这些问题，但是最终，采用可以与您的小对象无缝扩展的对象存储是一条更好的途径-应该尽快进行，而不是稍后进行。

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

在此期间，如果您希望入门，可以在此处下载MinIO 。我们随时可以提供帮助，并为社区提供一个Slack渠道，该渠道支持我们不断扩展的社区的1万多名成员。如果您想直接获得SLA或24/7的工程师支持，可以在MinIO订阅网络中找到答案。按容量定价并按月计费，它将为MinIO提供支持的工具，人才和技术带入您的部署。

如有任何疑问，请随时通过sales@minio.org.cn向我们发送便条。