传统上，存储的设计、获取和部署需要专业技能和管理相当复杂的能力才能成功完成。现代对象存储改变了这一点。这一点在今天尤为突出，因为 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 的粒度到服务器及其配套存储的粒度。由于容量和性能增量是如此细粒度和用户定义的，因此根本没有必要尝试将对象存储的大小远远超过应用程序的当前数据需求。

简单 vs. 复杂

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 上 这里提问。