我们与一家大型金融服务机构合作，这家机构曾被一家领先的图数据库供应商告知：“S3 Blob存储速度太慢，无法支持任何数据库，您应该改用更快的块存储和文件系统。”
且不说这个说法本身毫无道理——它是在将苹果（存储访问类型）与橘子（存储类型）进行比较，我们认为有必要直接对此进行回应。
相关的数据库供应商并非恶意，也无任何特定目的，但如果他们自己都不了解，那么其他人很可能也不了解。这篇文章旨在阐明不同的存储技术如何在架构中发挥不同的作用，讨论哪些因素会影响性能，并最终澄清对象存储是否适合数据库工作负载。
首先，让我们解决苹果和橘子的问题。将存储系统的性能与存储访问类型相关联，在多个层面上都是错误的。不幸的是，这在业界是一个常见的误解和混淆来源。
现在我们已经澄清了访问与性能的关系，接下来让我们来讨论性能。
当您考虑存储系统性能时，通常会考虑吞吐量和IOPS/延迟。传统上，业界认为对象存储是吞吐量优化的存储系统，而文件/块存储则是IOPS/延迟优化的解决方案。
我说传统上，是因为现在界限变得模糊多了。例如，MinIO在小型文件优化方面投入了大量精力，这反过来又带来了重大的IOPS提升。此外，SAN/NAS解决方案在超过PB后速度会大幅下降，因此优势会减弱。
这里要强调的是，工作负载的大小、类型和特性在存储系统性能方面至关重要，而依赖过时的“格言”来设计现代系统是一种糟糕的方法。
具体到上面关于“对象存储速度慢”的说法，这根本不正确。自早期对象存储系统使用低端设备硬件和HDD面世以来，对象存储已经取得了长足的进步。话虽如此，快速的对象存储并不是什么新鲜事。也许他们还在将AWS S3作为服务（而非S3 API）与本地SSD/NVMe驱动器的性能进行比较，但即使如此，两者速度都非常快。Snowflake从一开始就在S3上运行。如果S3不够快，他们会选择其他方案。他们没有必要选择S3。
现代对象存储将以硬件速度运行。来自多个来源的大量数据支持这一论断。英特尔、西部数据、超微和希捷都对MinIO进行了性能测试，并发现情况确实如此。给现代对象存储系统（如MinIO）配备NVMe，我们将能够充斥100GbE网络。给我们HDD，我们将先达到其极限，然后才会饱和网络。
架构正确的情况下，像MinIO这样的现代对象存储的速度与您使用的硬件一样快。这是事实。
一项最近的基准测试在仅使用32个标准NVMe SSD节点的情况下，GET操作实现了325 GiB/s（349 GB/s），PUT操作实现了165 GiB/s（177 GB/s）。MinIO提供的性能足以满足诸如Apache Spark、Starburst Presto/Trino、Clickhouse等苛刻工作负载的需求，以及您可以想到的任何其他云原生数据库、分析或AI/ML工作负载。
在这种情况下，应用程序供应商可能建议使用文件系统或基于块的存储，是因为他们依赖于这些“存储访问”方法，而不是因为“存储系统”及其性能特征。如果真是这样，那将是他们系统的一个缺陷，而不是技术论点。尽管如此，让我们把注意力转向访问问题。
存储访问
同样，存储访问（即文件、块和对象）与性能不同。主要区别在于API。对象使用RESTful API，这是云运行的方式。文件使用POSIX。块使用FC/SCSI/iSCSI。后两者早于云，在该操作模型中通常被认为是传统技术。还有其他需要考虑的因素。例如，基于文件的协议（例如POSIX）可能比基于对象的协议（例如S3）具有更多选项和冗余操作，而基于对象的协议本质上更简单（因此本质上更具可扩展性）。尽管如此，这些都是需要做出的选择，它们与性能相关，但彼此独立。
访问方法在一定程度上（并非完全）依赖于硬件。这包括CPU、驱动器类型、内存等。软件架构也起着作用。访问方面的关键领域包括层数和每一层的效率。如果必须遍历多个层，例如在S3接口前面放置一个文件存储，您将引入复杂性，从而抑制性能。同样，每一层如何组织、写入、扫描和读取数据，极大地影响着存储系统的整体性能。最佳的存储访问架构具有最少数量和最高效率的层——认识到每个人最终都会在块层写入和读取驱动器上的数据（虽然这不是这篇文章的重点——从存储的角度来看，“块”不是“一层”）。块是一个必不可少的层，因为它需要访问底层物理存储，但块在管理和呈现非结构化数据的元数据方面的能力有限。在这种情况下，需要对象存储来快速有效地执行依赖元数据的操作，例如搜索。
消除外部依赖项，例如外部数据库（用于元数据），也将解决环境扩展时可能出现的性能问题（一层但多条路径）。
结论
架构师需要理解，存储访问和存储性能不应混淆。它们在某些方面相关，但选择其中一个并不会自动决定另一个的行为。块并不总是很快。对象并不慢。有大量数据可以使这一点成为一个毫无意义的争论点。
任何告诉你相反的人要么不了解存储，要么是想向你推销东西。
擦除码计算器 
参考硬件 