以前我们提到存储，可能更多的联想到块存储和NAS存储，联想到的是集中式的存储分配方式。而在现在，随着分布式和云技术的流行，存储也搭上发展的顺风车，云存储，分布式存储，对象存储等等，各种新的名词不断涌现，令人目不暇接。
针对这些存储的区别，我觉得可以从两个方面来进行简单的归类：
1. 从数据结构分类：块存储、文件存储、对象存储；
2. 从物理架构分类：集中式存储、分布式存储。
数据结构上的不同，是由于不同的应用场景需要访问不同的数据类型，例如需要自建独立的文件系统，就需要块存储，而如果需要直接访问文件，就需要文件存储；物理架构的不同，则是根据具体的使用场景需要，比如管理方式和扩展性要求等等，两种分类可以任意重叠，比如既有集中式的块存储，也有分布式的块存储。而这些存储中，只有对象存储是在数据管理方式上发生了很大的变化，下面我们将着重介绍对象存储。
对象存储是将数据以对象的方式进行管理的数据存储体系结构，这也是其名称的来源。每个对象通常包括数据本身，可变量的元数据和全局唯一标识符。对象存储通过 API接口进行数据访问，主要通过网络方式提供存储服务。
对象存储技术发展非常迅速，云服务商中，在国际上如AWS S3, Appleicloud等案例,以及国内如阿里云的OSS等产品都是提供或者使用对象存储来解决海量非结构化数据的存放。在企业内部，例如在Facebook上的照片，Spotify上的歌曲或在线协作服务中的文件，例如Dropbox，也都在使用对象存储来存放海量非结构化数据。
对象存储经常被比作在一家高级餐厅代客停车。当一个顾客需要代客停车时，他就把钥匙交给别人，换来一张收据。这个顾客不用知道他的车被停在哪，也不用知道在他用餐时服务员会把他的车移动多少次。在这个比喻中，一个存储对象的唯一标识符就代表顾客的收据。当需要获取数据时，只需要告诉对象存储这个唯一标识符，剩下的检索工作均由对象存储本身完成。
在按照数据结构分类的三种存储中，块存储是通过将逻辑LUN映射给主机，然后主机建立文件系统使用，存储自身只提供裸设备；文件存储是自身提供文件服务，可以方便文件共享，并以目录层级式结构进行数据管理；而对象存储是将数据以对象的方式进行管理的数据存储体系结构。每个对象通常包括数据本身，可变量的元数据和全局唯一标识符，还可以通过不同用户区分管理。可见三种存储对于数据的存放及管理方式均有较大的不同。针对各自的特点，他们分别在使用场景和访问方式上也有很大的区别。
1. 在使用场景上
1)块存储主要用于传统的数据库使用，IO访问速度快，运行稳定，自身从产品技术角度只是为外界提供硬盘空间；
2)文件存储可以直接对外提供文件服务，访问的主机可以直接挂载需要的文件系统，数据可以共享访问，其IO性能不如块存储。当自身管理的文件数据非常庞大的时候，文件存储自身目录层级的结构会导致检索效率的下降，同时造成访问性能不断下降；
3)主流对象存储均采用节点式横向扩展分布式架构，以实现从小规模到大规模(10+PB级)的容量和性能扩展。为了实现海量非结构化数据管理，主流对象存储均采用分布式元数据管理方式，以使得存储系统在管理海量(亿级)文件时，能够实现访问性能的稳定性。对象存储抛弃了传统的基于树状文件系统的管理方式，通过Key-Value的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。此外在海量文件环境下，传统的数据备份方案无法有效备份，对象存储采用多副本的方式进行逻辑故障防护。与传统文件存储相比，对象存储在海量非结构化数据长久保存场景下有着独特的优势。
2. 在访问方式上
1)块存储可以通过FC或者IPSAN的方式，将LUN设备映射给需要的主机；
2)文件存储主要通过NFS或者CIFS方式为主机提供文件的服务，主机需要挂载相应的文件系统进行数据的访问；
3)对象存储通过 API接口进行数据访问，应用或者客户端可以直接调用访问数据，更加便捷，支持S3、HDFS、Swift等多种协议。
从上面对比发现，对象存储在面对海量数据的时候，无论从性能，还是在访问的便捷性上均有着很大的优势，很适合海量数据和云环境的使用。
从产品的多维度考察，对象存储有如下特点：
1. 访问方式：多种多样，支持多种接口协议，而且还在不断发展中，潜力巨大；
2. 存储架构：基于节点的横向扩展分布式架构，无集中元数据节点，计算处理能力是随着容量一起扩充的，不会随着体积庞大而导致性能下降；
3. 扩展性：可以支持百PB级以上的数据量，随着需要扩展，理论上没有上限；
4. 硬件可靠性：通过纠删码或多版本来避免磁盘/节点级故障；
5. 容灾架构：支持多站点多活架构；
6. 经济性：由于采用X86架构，以及廉价的大容量磁盘，相同容量成本对比传统存储只有其十分之一，相当廉价。
简单的总结起来就是：物美价廉分量足。
当然对象存储也不是万能的，不能盲信，比如在传统交易数据库架构中，其性能是远不如传统块存储的，高性能的IO读取，频繁的数据修改均不是对象存储的擅长领域。因此针对不同的场景需求，因地制宜，发挥每种存储产品的优势和特点，才是高效的运维策略。
在我看来，对象存储正是时代的产物，当代是信息化的时代，而信息的具体展现方式就是数据，是每天都在快速增长的海量数据。而在这样一种大背景下，传统存储在面对海量数据时，其服务方式就存在缺陷，有力无处使。这个时候对象存储出现了，其通过对象管理数据结构的方式，更便于数据的分类和快速的访问，同时廉价的成本又能降低存储海量数据的费用。
下图是IDC在2018年对市场上对象存储调研的情况
可以看到传统的存储厂商在这项技术出现后，借助自身的传统技术优势，都占据了领先的地位，其中IBM、EMC、NetAPP、日立均是耳熟能详的名字。后面则是新生的追赶者，呈现一种百家争鸣的景象。
从技术角度分类，对象存储产品主要分为以下三种：
1. 软硬一体机：传统存储厂商的主流产品倾向于软硬一体机的模式，软件与硬件封装在一起，按照硬件模块进行扩容，这类产品由于维护方式统一，在升级和兼容性方面有很大优势(从技术角度这些产品也可以只提供软件服务，但案例很少，厂商也并不推荐)；
2. 存储软件与硬件独立：用户可以自行选择硬件服务器和磁盘，厂商主要提供软件服务。这类产品自由度较高，厂商也大部分为软件起家；
3．部分厂商只提供云对象存储服务，很多是以网盘的形式。
从产品研发角度分类，分为以下两种：
1. 厂商自研：大部分传统的存储厂商均为自研的存储产品，各自技术结构略有差异，但整体技术实现方式接近，包括DELL EMC的ECS，IBM的CloudObject Storage，HDS的HCP等等，在市场中目前占据了领导的地位；
2. 开源对象存储软件：很多新兴的存储厂商采用了开源的对象存储软件，进行二次开发，形成自己的产品。其中开源产品多种多样，有Ceph、Lustre、OpenStack Swift等。这其中OpenStack Swift和Ceph的应用最广，两者相比较来说，OpenStack Swift更专注于对象存储部分，而Ceph的功能更为广泛，块存储、文件存储以及对象存储全部支持。这些产品大多处于市场象限中的主要参与者，其中像Redhat就使用Ceph作为自己的对象存储产品。
提到开源存储，就不能不提到其中最火热的Ceph，Ceph起初创立是作为一个可扩展的分布式文件系统开始的，但是发展的过程遇到了很多问题，硬件出错，扩展的问题，伸缩性的问题等等，直到2012年左右，OpenStack出现以后，Ceph开始脱颖而出。Ceph 先有文件存储，后逐渐形成文件、块、对象都有的统一存储，从成长历程上有点无心插柳柳成荫的感觉。目前国内很多新兴的国产存储厂商也都采用Ceph来搭建自己的产品，可谓目前的当红小生。
前面讲到了对象存储的几大应用特点，有容量大、价格便宜、扩展性强、适合海量数据的检索等等，把这些特性对应起来，会发现特别适合海量的非结构化数据的长久保存，例如图片、文档、影音影像、日志等非结构化数据。
在金融行业中，很多票据、文件和图片均需要电子化保存，同时在买卖理财或者保险过程中可能要求进行录音录像，这些都需要长时间的保管。针对企业的业务量的不同，每月都会新增几TB甚至几十TB的数据量，这些数据可能需要保存几十年，而且还面临监管部门的随时抽查和业务部门的偶尔调用。因此在金融企业中，均会有这么几个PB级的系统需要运维人员大费脑筋。而针对这些系统，传统的块存储和文件系统，无论从性能上，扩展性上还是经济成本上，均不能满足需求。对象存储则是为这些应用量身打造，很好的解决了这些系统的海量数据难题。
而在金融企业的应用中，保险业对象存储的使用稍早一些，很多影像单据类的应用均上了对象存储。而银行业也不甘落后，由于影像图像系统也常年受到海量数据的挑战，因此这些年国内不少银行均对这类系统进行改造，采用对象存储优化架构，节约成本。
对象存储在面对海量数据时，从技术角度讲是如何优于传统存储的呢？下面我们从多个方面来进行对比。
1.容量：传统存储一般能支持几个PB就算很庞大了，而对象存储来说，可以支持几百PB以上的容量，理论上甚至没有上限，两者数量级就不在一个层面上；
2.扩展性：作为默认分布式架构的对象存储在这方面更是毫无压力；
3.性能：当处理海量数据文件的时候，其实单个IO的访问速度已经不再是瓶颈，瓶颈更多的在于海量数据的检索和维护操作。因此块存储的性能压力更多的在于系统上，受文件系统类型，检索方式多种因素影响，当数据越大，磁盘越多的时候，压力也会越来越大；文件系统作为层级目录结构，当单目录下文件数据巨大(几百万个文件以上)，以及目录层数越来越多时，其性能会显著下降；而对象存储采用对象方式，更便于检索，同时使用扁平式架构来管理海量文件，不会随着体量的庞大而影响性能，同时面向用户数据访问更加直接，减少了中间处理的环节；
4.运维：块存储中，几百几千个LUN挂在主机上，当经历一次系统全套切换流程时，LUN的挂载，卷的激活，以及存储的切换，这些操作就意味要经历几个小时的等待，相信这些都是影像系统管理员经历过的痛；文件存储在后期的维护中也要不断的添加新的文件系统提供挂载点，不过运维压力相对块存储已经好了不少；而对象存储则可以在线直接扩容空间，应用没有任何感知，极大的减少了系统层面的运维操作，更加便利。
对象存储的出现，对运维人员也提出了新的要求，主要体现下面两个方面。
1. 对运维人员的挑战：对象存储均是采用网络访问数据的方式，需要接入相关业务网中，其访问也更直接的面向了应用，因此需要运维人员更多的了解应用的架构和接口方式，同时了解网络技术和规范，而不能只是沉浸在自己的一套FC SAN网络规划中；
2. 对成熟网络体系的挑战：对象存储和很多其他的云产品一样，产品设计更多体现了自身的便捷性，模块性。因此其网络访问的方式，对于有严格网络规范的运维体系，则需要做一些网络配置上的特殊调整和优化，这就需要多个部门之间的积极沟通和网络部门的大力支持了。
