传统上，存储的设计、采购和部署需要专业技能和管理大量复杂性的能力才能成功。现代对象存储改变了这一点。这在今天尤其令人痛心——购买 SAN 和 NAS 设备通常需要数月或更长时间才能完成。这与软件定义的对象存储形成鲜明对比，软件定义的对象存储可以在几分钟内下载并部署到现有硬件上——完成许可证。

由于这个原因和其他原因，现代对象存储更像是一个数据存储而不是“存储”。这促使我们更仔细地审视传统 SAN/NAS 方法与现代云原生对象存储之间不断扩大的差距。

数据存储、对象存储

SAN/NAS 系统通常由旨在满足数据中心共享需求的基础设施买家购买。这集中了 IT 的巨大力量，但也在响应能力方面造成了真正的压力。随着数据的增长，事实证明保持同步的挑战太大，开发人员、业务线所有者、架构师和应用程序团队开始采用软件定义的存储，以更好地匹配他们正在运行的非常多样化的数据和工作负载。这直接将他们引向了现代的云原生对象存储。

因此，对象存储下的企业数据份额激增。这是对象存储提供的简单性、规模、易操作性和云原生 API 的功能。此时，您将找不到在 SAN/NAS 设备上运行的新的数据密集型应用程序——即使是老派的 IT 团队也了解云操作模型的强大功能。

GTM动力

SAN/NAS 模型的核心也是通道模型。渠道具有价值 - 但它们会带来复杂性和成本。他们绝对会给评估和购买过程带来摩擦。在使用渠道或 VAR 时，需要进行广泛的规划以适应多方面的配置阶段，还需要对操作员进行持续的系统监控/管理培训以确保正确使用。

相比之下，现代的云原生对象存储购买非常简单。下载软件并根据需要使用信用卡获取许可证。MinIO、GCP、AWS 和 Microsoft 支持此模型，并且与 IBM 一起，您可以将合同金额用于 MinIO 许可证。就这么简单。当然，带有存储的服务器硬件必须可用或购买，但这些硬件比 SAN/NAS 系统更容易确定大小和获取。查看我们的参考硬件页面以了解一些想法。

规模调整和横向扩展

SAN/NAS 系统通常需要长期（3-5 年）的规模估计，以确保它们能够支持未来的存储需求。这是因为 SAN/NAS 设备仅支持有限范围的存储容量和性能，一旦超过，就需要更换设备并将其数据迁移到新系统。

对象存储也需要调整大小。但在这里，可以仅使用当前数据需求来指导硬件采购。这是因为对象存储作为一种纯软件定义的解决方案，具有性能和容量增量，旨在让客户进行调整。此外，通过服务器池等技术，现代对象存储可以轻松无缝地提供硬件异构性。可调元素的范围可以从单个磁盘驱动器或 SSD 的粒度到服务器及其附带存储的大小。由于容量和性能增量是如此细粒度和用户定义的，根本没有必要尝试将对象存储的大小远远超出应用程序当前的数据需求。

简单与复杂

SAN 存储需要存储结构、主机卷访问以及 SAN 存储系统卷配置更改。是的，随着时间的推移，所有这些都变得更简单了，但它仍然需要主机、结构和 SAN 存储更新才能将它们粘合在一起。NAS 系统要容易得多，但仍然需要 NAS 解决方案中的文件系统来匹配访问它们的主机上的挂载点和共享点。用于 SAN 或 NAS 系统的 iSCSI 卷比 FC 卷更容易配置，但两者都很复杂并且需要主机和存储系统链接。

配置对象存储系统要容易得多。需要通过将对象软件下载/复制到存储服务器上来配置存储服务器，然后将这些节点添加到对象存储集群中。这就是为什么有数百篇关于 MinIO 主题的Medium 帖子——这很简单。

尽管多年来 SAN/NAS 系统操作变得相当容易，但它们仍然经常需要在 GUI 中对操作员进行培训，并需要一个单独的操作组来监控和管理它们。是的，在某些情况下，SAN/NAS 系统可以利用 CLI 或 API。但它们的 API 通常是事后才想到的，可能缺少 GUI 或 CLI 中可用的某些功能。但关键的事实是，它们很少完全使用 API 和代码进行管理，并且在没有操作员监督的情况下无法正常工作。

对象存储旨在通过 API 和 CLI 进行管理。他们可能有一个 GUI，但这通常只是 API 调用的前端。管理对象存储系统的工作量要少得多，而且通常完全由代码单独完成。

作为数据的对象

有一些对象独有的功能，它们也增加了对象存储的类似数据存储的属性。例如，与代码存储库一样，对象支持数据版本控制。这是一种功能，当新数据覆盖旧对象时，对象存储系统会自动创建新版本的数据。此后，如果需要，可以检索对象的旧版本和新版本。可以删除旧版本以在需要时释放空间。当然，这可以在像 MinIO 这样的软件中自动完成。

不变性

对象本质上是不可变的。也就是说，它们可以写入一次，但可以多次读取。我们看到这用于电子发现、合规性（必须在指定时间段内保留）和其他业务要求所需的数据。不可变数据只能在过期后被允许删除。在过期之前，不可变对象数据无法更改。

安全

此外，对象提供更细粒度的数据安全性。大多数 SAN/NAS 存储系统可以提供驱动器加密（使用自加密驱动器）或卷/文件系统级加密。对象存储也在存储桶级别执行此操作，但对象也可以使用自己的密钥进行加密。对同一桶中的对象这样做，允许每个对象单独受到保护，不受桶中和整个对象存储系统中的所有其他对象的影响。

云原生

使用 RESTful、基于 Web 的协议访问对象，与网页不同，使用 URL 和对象 ID 来寻址它们。SAN 和 iSCSI 卷通过卷 ID 和块偏移量访问，而 NAS 文件通过 NFS 挂载点或 SMB 共享点和多级目录规范访问。对象确实存在于存储桶中，但存储桶名称嵌入在对象 URL 中。

元数据

对象还提供用户添加的数据属性规范或标签。标签是用户定义的，一个对象最多可以有十个标签。用户可以使用标签搜索对象数据，并且可以在对象发生更改时随时更新或添加标签。SAN 存储没有与卷关联的标签（好吧，也许在操作系统存储管理级别），iSCSI 卷也是如此。NAS NFS/SMB 文件具有非常有限的“标准定义”的元数据集，可以与文件相关联。据我们所知，无法使用此用户定义的文件元数据直接搜索文件。  

为什么您不想搜索您的数据？

概括

从上面可以看出，对象存储系统的一些属性比传统的 SAN 或 NAS 系统更像数据存储。此外，对象本身在数据堆栈中的位置也明显高于卷、块或文件。

综上所述，对象感觉更像是数据而不是块或文件。文件比卷块更接近数据，但它们仍然缺乏许多数据特征，而且设备仍然需要太多的复杂性和时间来购买、配置和操作。

这意味着企业可以在不牺牲性能的情况下采用以数据为中心的架构，同时增强云互操作性、应用程序互操作性、安全性、可扩展性和简单性。如果这看起来是一组压倒性的优势 - 它确实是，这就是为什么 SAN 和 NAS 在下降而对象存储在上升。归根结底 - 这不是关于单一趋势。如果是的话，SAN/NAS 供应商就不会陷入困境。有多种趋势在起作用——横向扩展、软件定义、云原生、开源和成本。总的来说，这些代表了太多要为 SAN/NAS 供应商而战的战线。

为自己学习。您可以在此处下载 MinIO ，请在此处查看文档，在这里观看一些精彩的视频，或者在 Slack上提问。