有时候，人难免怀念过去的美好时光，那时的网络存储世界可以清晰地分为两种方法，一种基于文件，另一种基于数据块。

　　在云计算出现以前，如果你要处理结构化的数据(如数据库)，就需要使用基于数据块的SAN方法。如果你要处理非结构化数据(大型文件，文件夹，视频，医学影像等)，就需要使用基于文件的NAS方法。

图一：NAS、SAN和对象存储的比较

　　后来，事情发生了变化。人们开始感受到将所有非结构化数据保持在云中的好处。他们就开始思考新的，大量运算工作(如大型数据分析)。将运算和存储分布到大量设备中可以完成这样的操作。而且，人们醉心于找到将数据存储到任何地方联网的任何设备中。

　　当然，一旦所谓的网络是指“互联网”，那么显然原来在较快的本地网络中有效快捷的方法会不适应较慢的互联网。

　　对象存储，基于对象的方法之所以不同于基于数据块的方法，是因为前者将数据放置到容量灵活变化的数据容器中，也就是所谓的对象。每个对象都包含数据(为解析的字节序列)和元数据(描述对象的可扩展属性集)。而它不同于基于文件的方法，是因为对象存储系统利用了一个单独的平铺的地址空间，而不是依赖于一个层级型的树形文件架构。对象是通过简单的GET-PUT命令访问，创建，删除和移动，而不是依赖于NFS，CIFS或其他在互联网上具有较好递增适应性的描述性协议。

　　基于对象的方法存储兼具简洁性，有效性，经济性和扩展性于一体，所以无疑它会成为云存储中的主导力量。

　　不过，仍然有一些问题存在。

　　或许最重要的问题是所有在企业中虚拟创建的应用都假设有服从POSIX的文件系统。所以，将应用从企业迁移到云架构中意味着所有已有的应用都必须重写才能用于新的存储范例。云计算还不能适应POSIX，所以它使用的是对象存储，因为与对象相关联的简单协议使得创建，移动和删除等操作更迅速。所以将云用来灵活扩展现有架构的目的难以实现。

　　即便你用基于对象的方法写应用也会带来些许麻烦。一方面，许多都采用最小和最大两种对象容量。如果你的应用是处理小文件，那么要么是极其低效，要么是将负担放在应用上将小文件打包到更大的对象中。此外，基于对象的系统通常依赖于集中式元数据存储，这样就造成了性能瓶颈和单点故障。最后，基于对象的系统限制了可保存到单一系统缓存中的对象数量。

　　Map-Reduce，是一个为电脑群组上大型数据集提供分布式运算支持的软件架构，它是创新式运算获得成功的又一典范。不过，依赖于过期元数据服务器模式的文件系统部署仍然挑战着它的性能。

图二：理想状态的统一文件和对象系统

　　显然，能集二者于一身的方法才是最佳方案。我们需要一个统一的文件和对象存储方法，进行快速而简便的存储，同时又不影响传统文件系统的灵活性与兼容性。这样的方法可以将文件视作对象，将对象视作文件，将文件夹视作容器，又将容器视作文件夹。换言之，存储应该是未知存取的。

　　将文件与对象统一起来同样需要从传统的软件观出发。虽然此处的统一方法以硬件为基础，但似乎与云的概念有着根本差异。

　　“链式”方案(将存储与组件装配联系起来，然后创造出特定的磁盘驱动和功能以便将存储用于每个组件)或许在技术上可支持NAS, SAN和对象功能，但是却带来了额外风险和成本。与单一的文件或对象存储相比，用户需购买更多的存储空间。除了能耗，冷却和电缆故障等内部风险外，用户还可能无法访问所有数据。而且，你无法获得扩展性和灵活性，这是与云最本质的区别。

　　相形之下，在软件级别的统一方案中，你完全无需了解存储或硬件相关的问题。

　　因此，企业可以：

    在自己的私有云或数据中心中创建自己的云服务。

    在私有或共有云之间传输对象，甚至可以在云中的非对象存储中创建一个对象存储环境。再将过去的文件应用迁移到云中。

    创建新的云应用，使之既可以利用对象存储，又可以利用文件存储。