大数据的挑战是小文件

小文件可能会给存储平台及其驱动的应用程序带来大问题。在谷歌上搜索“small files performance”会得到超过 200 万条结果。这篇博文将更深入地研究小文件问题，挖掘其根源并给出解决方案。

出于本次讨论的目的，小文件通常被认为是任何小于 64 KB 的文件。当我们与客户合作调整他们的集群时，我们看到越来越多（数十亿和万亿）的文件在 16 KB 到 1 MB 之间。像这样的小文件通常是保存机器生成的基于事件的流的结果。将小文件写入对象存储很简单，但是对它们的查询会运行得更慢，甚至无法完成。查询许多小文件会产生读取元数据、进行非连续磁盘查找、打开文件、关闭文件并重复的开销。每个文件的开销只有几毫秒，但是当您查询数千、数百万甚至数十亿个文件时，这些毫秒加起来。

分析引擎很难对大量小文件运行查询。许多企业在处理物联网设备、服务器、网络设备和应用程序日志等流源时都面临着这一挑战——所有这些都可以每秒生成数千个事件日志，每个日志都存储在一个单独的 JSON、XML 或 CSV 文件中。查询一天的日志可能需要几个小时。

为解决昨天的大数据问题而构建的技术无法应对大量小文件带来的挑战。设计用于处理少量大文件的硬件和应用程序不具备摄取、编目和查询大量小文件的能力。衡量一个系统在存储大量小文件时是否能够蓬勃发展的关键指标是 IOPS，即每秒的输入和输出（读取和写入）量。IOP 由寻道时间、读取时间和数据传输时间组成。对于硬盘驱动器等机械介质，顺序读取和写入明显快于随机读取和写入。随机读写单个文件的效率低于连续读写多个文件。  

元数据管理、跨节点和磁盘的数据分布、I/O 管理、缓存管理和网络开销可能导致性能低下和存储效率降低。在针对大量小文件进行优化时，这些是需要重点关注的领域。优化需要全面了解系统工程，包括硬件和软件的结合和交互。大量小文件问题是必须在多个级别和瓶颈上进行攻击才能实现显着优化的问题。  

元数据管理尤其会削弱存储系统有效存储大量小文件的能力。在对大型连续文件进行操作时，元数据操作开销会被更大的数据操作开销所抵消。当小文件的数量急剧增加时，元数据操作开始严重影响系统性能。

Hadoop 尤其受到向小文件的转变的沉重打击。Hadoop 对于存储和处理少量大文件比处理大量小文件效率更高。HDFS 的默认块大小现在是 128MB（以前是 64MB）。存储一个 128MB 的文件与存储一个 16KB 的文件一样需要一个 128MB 的块。此外，HDFS 中的每个文件、目录和块都在元数据中进行跟踪，元数据在 NameNode 的内存中每条记录占用 150 到 300 字节。一亿个小文件将消耗数百 GB 的名称节点内存，并且通过存储大部分为空的块而浪费超过 10 TB。随着必须写入、映射和查询的文件数量增加，节点之间的通信量增加，效率进一步降低。      

当涉及大量小文件时，SAN 和 NAS 解决方案也达不到要求。这两种技术都旨在提供高 IOPS，但都不是为应用程序的大量并发读取和数据源的写入而设计的。两者都依赖 RAID 和复制来实现持久性和高可用性，这两者都会增加写入延迟并降低存储效率。SAN，提供非常低的延迟和高吞吐量，但仅限于直接连接到它的服务器。NAS作为网络挂载卷，在存储海量小文件时，面临着块存储的低效和文件系统的局限性。但 NAS 的主要弱点是它无法在规模上提供足够的性能，并且在面对大量并发请求时性能会下降。

对小文件问题的典型响应是将这些微小的数据写入数据库而不是作为单独的文件。不幸的是，这也不能解决性能问题。它会持续一段时间，但没有数据库可以提供超过 PB 小文件的持久性和性能。是的，历史上使用数据库来存储和查询小文件是一个不错的想法——数据库提供了将记录存储为 ACID 事务、构建索引并对这些记录执行详细查询的能力，但是当面对解决当今组织面临的大量小文件问题所需的大量记录。

架构正在远离用于存储和查询大量小文件的数据库和文件系统。数据库是写入模式、分区/分片、提前构建索引以加速查询的优秀工具，但这些都不适用于大量小文件。

一种强大的新兴范例是这样一种范例，其中系统围绕读取模式构建，使用 parquet、AVRO 和 ORC 等格式自描述小文件，并结合可以在将它们写入对象存储后对其进行查询的应用程序。分布式对象存储可以存储大量的小文件并在多个应用程序之间并发共享。读取模式的趋势将写入直接发送到对象存储。这允许数据库变得无状态、弹性和云原生——消除了它们管理存储的需要。

数据库不应该负责数据存储。他们不能很好地快速摄取大量小文件，但这正是流数据用例所需要的。小对象——记录、日志条目、文件——正以巨大的规模和速度从无数的应用程序和设备中传入。这不能通过数据库写入，没有数据库能够以支持实时分析所需的速度和规模运行。

目前，优化海量小文件存储最成功的策略是写入对象存储，去除对数据库和文件系统的依赖。  

MinIO 擅长存储、查询和检索小对象。在最近的性能基准测试中，我们测得 PUT 吞吐量为 1.32 Tbps，GET 吞吐量为 2.6 Tbps。MinIO在线存储元数据和对象，无需查询外部元数据数据库。MinIO 可以在从 ZIP 存档上传和下载单个文件后自动提取 .tar 文件。

MinIO 的纠删码实现是小对象领先性能、存储效率和功能的关键组成部分。快速擦除编码允许大规模捕获小对象并在多个驱动器和节点之间以奇偶校验方式分布，以立即受到保护以实现持久性和高可用性。例如，使用最大纠删码奇偶校验，您可以在 MinIO 集群中丢失一半的驱动器，但仍然保持持久性。  

相比之下，数据库复制是为了持久性和高可用性，这使它们在大规模运行时处于严重劣势。三副本多阶段提交无法以组织摄取小文件的巨大规模所需的速度运行。复制至少涉及创建和分发三个数据副本。这是资源和性能密集型的，另外，如果你丢失了两个副本，你将不再有耐久性保证。拥有用于流数据的热层或缓存是改进摄取的良好开端，但您仍然可能在写入和复制数据之前丢失数据。

小文件解决方案

当今的许多工作负载——尤其是流媒体和日志分析——对应用程序和存储系统提出了很高的要求，迫使它们处理大量的小文件。大数据很少意味着分析大文件。更常见的情况是，大数据意味着数百万或数十亿个小于 1 MB 的文件。数据库和文件系统无法扩展以提供实时分析所需的性能。

MinIO 是小文件问题的答案。行业领先的性能可加快摄取、查询和检索速度，同时纠删码可提供持久性。永远不会丢失数据或导致查询再次超时。  

使用对象存储解决小文件问题还有一个额外的优势——您正在创建可用于所有云原生应用程序的融合存储，而不仅仅是特定数据库。您可以针对对象存储运行所有分析和 AI/ML 应用程序。您的数据现在可以由任何云原生数据库免费访问，而不是锁定在特定格式或产品中。

如果您的系统正在努力（甚至无法）满足必须摄取、存储、查询和检索大量小文件的需求，那么立即下载MinIO。