块存储主要是将裸磁盘空间整个映射给主机使用的，就是说例如磁盘阵列里面有5块硬盘(为方便说明，假设每个硬盘1G)，然后可以通过划逻辑盘、做Raid、或者LVM(逻辑卷)等种种方式逻辑划分出N个逻辑的硬盘。(假设划分完的逻辑盘也是5个，每个也是1G，但是这5个1G的逻辑盘已经与原来的5个物理硬盘意义完全不同了。例如第一个逻辑硬盘A里面，可能第一个200M是来自物理硬盘1，第二个200M是来自物理硬盘2，所以逻辑硬盘A是由多个物理硬盘逻辑虚构出来的硬盘。)
接着块存储会采用映射的方式将这几个逻辑盘映射给主机，主机上面的操作系统会识别到有5块硬盘，但是操作系统是区分不出到底是逻辑还是物理的，它一概就认为只是5块裸的物理硬盘而已，跟直接拿一块物理硬盘挂载到操作系统没有区别的，至少操作系统感知上没有区别。
此种方式下，操作系统还需要对挂载的裸硬盘进行分区、格式化后，才能使用，与平常主机内置硬盘的方式完全无异。
优点：
1、 这种方式的好处当然是因为通过了Raid与LVM等手段，对数据提供了保护。
2、 另外也可以将多块廉价的硬盘组合起来，成为一个大容量的逻辑盘对外提供服务，提高了容量。
3、 写入数据的时候，由于是多块磁盘组合出来的逻辑盘，所以几块磁盘可以并行写入的，提升了读写效率。
4、 很多时候块存储采用SAN架构组网，传输速率以及封装协议的原因，使得传输速度与读写速率得到提升。
缺点：
1、采用SAN架构组网时，需要额外为主机购买光纤通道卡，还要买光纤交换机，造价成本高。
2、主机之间的数据无法共享，在服务器不做集群的情况下，块存储裸盘映射给主机，再格式化使用后，对于主机来说相当于本地盘，那么主机A的本地盘根本不能给主机B去使用，无法共享数据。
3、不利于不同操作系统主机间的数据共享：另外一个原因是因为操作系统使用不同的文件系统，格式化完之后，不同文件系统间的数据是共享不了的。例如一台装了WIN，文件系统是FAT32/NTFS，而Linux是EXT4，EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘，插进Linux的笔记本，根本无法识别出来。所以不利于文件共享。
2、文件存储
典型设备：FTP、NFS服务器
为了克服上述文件无法共享的问题，所以有了文件存储。
文件存储也有软硬一体化的设备，但是其实普通拿一台服务器/笔记本，只要装上合适的操作系统与软件，就可以架设FTP与NFS服务了，架上该类服务之后的服务器，就是文件存储的一种了。
主机A可以直接对文件存储进行文件的上传下载，与块存储不同，主机A是不需要再对文件存储进行格式化的，因为文件管理功能已经由文件存储自己搞定了。
优点：
1、造价较低：随便一台机器就可以了，另外普通以太网就可以，根本不需要专用的SAN网络，所以造价低。
2、方便文件共享：例如主机A(WIN，NTFS文件系统)，主机B(Linux，EXT4文件系统)，想互拷一部电影，本来不行。加了个主机C(NFS服务器)，然后可以先A拷到C，再C拷到B就OK了。(例子比较肤浅，请见谅……)
缺点：
读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承担，相比起磁盘阵列动不动就几十上百块硬盘同时读写，速率慢了许多。
3、对象存储
典型设备：内置大容量硬盘的分布式服务器
对象存储最常用的方案，就是多台服务器内置大容量硬盘，再装上对象存储软件，然后再额外搞几台服务作为管理节点，安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。
之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利 于共享的出来呢。于是就有了对象存储。
首先，一个文件包含了了属性(术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等)以及内容(以下简称数据)。
以往像FAT32这种文件系统，是直接将一份文件的数据与metadata一起存储的，存储过程先将文件按照文件系统的最小块大小来打散(如4M的文件，假设文件系统要求一个块4K，那么就将文件打散成为1000个小块)，再写进硬盘里面，过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。
这种情况下读写速率很慢，因为就算你有100个机械手臂在读写，但是由于你只有读取到第一个块，才能知道下一个块在哪里，其实相当于只能有1个机械手臂在实际工作。
而对象存储则将元数据独立了出来，控制节点叫元数据服务器(服务器+对象存储管理软件)，里面主要负责存储对象的属性(主要是对象的数据被打散存放到了那几台分布式服务器中的信息)，而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。
这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。
另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。
所以对象存储的出现，很好地结合了块存储与文件存储的优点。
最后，为什么对象存储兼具块存储与文件存储的好处，还要使用块存储或文件存储呢?
1、有一类应用是需要存储直接裸盘映射的，例如数据库。因为数据库需要存储裸盘映射给自己后，再根据自己的数据库文件系统来对裸盘进行格式化的，所以是不能够采用其他已经被格式化为某种文件系统的存储的。此类应用更适合使用块存储。
2、对象存储的成本比起普通的文件存储还是较高，需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量，只是为了做文件共享的时候，直接用文件存储的形式好了，性价比高。
二、从应用角度比较块存储、文件存储、对象存储
产品和市场需求有各种相互影响的关系，但不管是哪一种，最终呈现都是产品和应用需求需要对应匹配。应用需求越多样化，市场也就划分得更加细，产品种类也就更加丰富。在存储行业，我们也可以从“应用适配”这个角度来聊聊各类存储。
传统认知上来说，IT设备分为计算/存储/网络三大类，相互之间是有明显的楚河汉界的。计算大家都清楚，服务器，小型机，大型机;网络也就是路由器交换机;存储有内置存储和外置存储，最常见的就是磁盘阵列。在HCI(超融合)这个概念没被热炒之前，计算网络存储还都是泾渭分明，各担其责的。今天我们先不讨论超融合的情况，仅基于传统理解，看看存储的情况。
从逻辑上存储通常分为块存储，文件存储，对象存储。这三类存储在实际应用中的适配环境还是有着明显的不同的。
块存储(DAS/SAN)通常应用在某些专有的系统中，这类应用要求很高的随机读写性能和高可靠性，上面搭载的通常是Oracle/DB2这种传统数据库，连接通常是以FC光纤(8Gb/16Gb)为主，走光纤协议。如果要求稍低一些，也会出现基于千兆/万兆以太网的连接方式，MySQL这种数据库就可能会使用IP SAN，走iSCSI协议。通常使用块存储的都是系统而非用户，并发访问不会很多，经常出现一套存储只服务一个应用系统，例如如交易系统，计费系统。典型行业如金融，制造，能源，电信等。
文件存储(NAS)相对来说就更能兼顾多个应用和更多用户访问，同时提供方便的数据共享手段。毕竟大部分的用户数据都是以文件的形式存放，在PC时代，数据共享也大多是用文件的形式，比如常见的的FTP服务，NFS服务，Samba共享这些都是属于典型的文件存储。几十个用户甚至上百用户的文件存储共享访问都可以用NAS存储加以解决。在中小企业市场，一两台NAS存储设备就能支撑整个IT部门了。CRM系统，SCM系统，OA系统，邮件系统都可以使用NAS存储统统搞定。甚至在公有云发展的早几年，用户规模没有上来时，云存储的底层硬件也有用几套NAS存储设备就解决的，甚至云主机的镜像也有放在NAS存储上的例子。文件存储的广泛兼容性和易用性，是这类存储的突出特点。但是从性能上来看，相对SAN就要低一些。NAS存储基本上是以太网访问模式，普通千兆网，走NFS/CIFS协议。
对象存储概念出现得晚一些，存储标准化组织SINA早在2004年就给出了定义，但早期多出现在超大规模系统，所以并不为大众所熟知，相关产品一直也不温不火。一直到云计算和大数据的概念全民强推，才慢慢进入公众视野。
前面说到的块存储和文件存储，基本上都还是在专有的局域网络内部使用，而对象存储的优势场景却是互联网或者公网，主要解决海量数据，海量并发访问的需求。基于互联网的应用才是对象存储的主要适配(当然这个条件同样适用于云计算，基于互联网的应用最容易迁移到云上，因为没出现云这个名词之前，他们已经在上面了)，基本所有成熟的公有云都提供了对象存储产品，不管是国内还是国外。
对象存储常见的适配应用如网盘、媒体娱乐，医疗PACS，气象，归档等数据量超大而又相对“冷数据”和非在线处理的应用类型。这类应用单个数据大，总量也大，适合对象存储海量和易扩展的特点。网盘类应用也差不多，数据总量很大，另外还有并发访问量也大，支持10万级用户访问这种需求就值得单列一个项目了(这方面的扫盲可以想想12306)。归档类应用只是数据量大的冷数据，并发访问的需求倒是不太突出。
另外基于移动端的一些新兴应用也是适合的，智能手机和移动互联网普及的情况下，所谓UGD(用户产生的数据，手机的照片视频)总量和用户数都是很大挑战。毕竟直接使用HTTP get/put就能直接实现数据存取，对移动应用来说还是有一定吸引力的。
对象存储的访问通常是在互联网，走HTTP协议，性能方面，单独看一个连接的是不高的(还要解决掉线断点续传之类的可靠性问题)，主要强大的地方是支持的并发数量，聚合起来的性能带宽就非常可观了。
从产品形态上来看，块存储和文件存储都是成熟产品，各种规格形态的硬件已经是琳琅满目了。但是对象存储通常你看到都是一堆服务器或者增强型服务器，毕竟这东西现在还是互联网行业用得多点，DIY风格。
关于性能容量等方面，我做了个图，对三种存储做直观对比。
块存储就像超跑，根本不在意能不能多载几个人，要的就是极限速度和高速下的稳定性和可靠性，各大厂商出新产品都要去纽北赛道刷个单圈最快纪录，千方百计就为提高一两秒，跑不进7分以内都看不到前三名。(块存储容量也不大，TB这个数量级，支持的应用和适用的环境也比较专业(FC+Oracle)，在乎的都是IOPS的性能值，厂商出新产品也都想去刷个SPC-1，测得好的得意洋洋，测得不好自动忽略。)
文件存储像集卡，普适各种场合，又能装数据(数百TB)，而且兼容性好，只要你是文件，各种货物都能往里塞，在不超过性能载荷的前提下，能拉动常见的各种系统。标准POXIS接口，后车门打开就能装卸。卡车也不挑路，不像块存储非要上赛道才能开，普通的千兆公路就能畅通无阻。速度虽然没有块存储超跑那么块，但跑个80/100码还是稳稳当当.
而对象存储就像海运货轮，应对的是"真·海量"，几十上百PB的数据，以集装箱/container(桶/bucket)为单位码得整整齐齐，里面装满各种对象数据，十万客户发的货(数据)，一条船就都处理得过来，按照键值(KeyVaule)记得清清楚楚。海运速度慢是慢点，有时候遇到点网络风暴还不稳定，但支持断点续传，最终还是能安全送达的，对大宗货物尤其是非结构化数据，整体上来看是最快捷便利的。
从访问方式来说，块存储通常都是通过光纤网络连接，服务器/小机上配置FC光纤HBA卡，通过光纤交换机连接存储(IP SAN可以通过千兆以太网，以iSCSI客户端连接存储)，主机端以逻辑卷(Volume)的方式访问。连接成功后，应用访问存储是按起始地址，偏移量Offset的方法来访问的。
而NAS文件存储通常只要是局域网内，千兆/百兆的以太网环境皆可。网线连上，服务器端通过操作系统内置的NAS客户端，如NFS/CIFS/FTP客户端挂载存储成为一个本地的文件夹后访问，只要符合POXIS标准，应用就可以用标准的open，seek, write/read,close这些方法对其访问操作。
对象存储不在乎网络，而且它的访问比较有特色，只能存取删(put/get/delete)，不能打开修改存盘。只能取下来改好后上传，去覆盖原对象。(因为中间是不可靠的互联网啊，不能保证你在修改时候不掉线啊。所谓你在这头，对象在那头，所爱对象隔山海，山海不可平。)
另外再说一点分布式存储的问题，以上三种存储都可以和分布式概念结合，成为分布式文件系统，分布式块存储，还有天生分布式的对象存储。
对象存储的定义就把元数据管理和数据存储访问分开在不同的节点上，多个节点应对多并发的访问，这自然就是一个分布式的存储产品。而分布式文件系统就很多了，各种开源闭源的产品数得出几十个，在不同的领域各有应用。至于分布式的块存储产品就比较少，也很难做好。我个人认为这个产品形态有点违和，分布式的思想和块存储的设计追求其实是冲突的。前面讲过，块存储主要是图快，一上分布式肯定严重拖后腿，既然都分布开了，节点之间的通信必然增加额外负担，再加上CAP，为了保持一致性牺牲响应速度，得到的好处就是扩展性。这就像把超跑弄个铁索连环，哪里还可能跑出高速?链条比车都重了，穿起来当火车开吗?
而文件存储原来也就是集装箱货车，大家连起来扮火车还是有可行性的。
三、块存储、文件存储、对象存储的层次关系
应用的角度聊过了，我们再看看这三种存储的一些技术细节，首先看看在系统层级的分布。
我们从底层往上看，最底层就是硬盘，多个硬盘可以做成RAID组，无论是单个硬盘还是RAID组，都可以做成PV，多个PV物理卷捏在一起构成VG卷组，这就做成一块大蛋糕了。接下来，可以从蛋糕上切下很多块LV逻辑卷，这就到了存储用户最熟悉的卷这层。到这一层为止，数据一直都是以Block块的形式存在的，这时候提供出来的服务就是块存储服务。你可以通过FC协议或者iSCSI协议对卷访问，映射到主机端本地，成为一个裸设备。在主机端可以直接在上面安装数据库，也可以格式化成文件系统后交给应用程序使用，这时候就是一个标准的SAN存储设备的访问模式，网络间传送的是块。
如果不急着访问，也可以在本地做文件系统，之后以NFS/CIFS协议挂载，映射到本地目录，直接以文件形式访问，这就成了NAS访问的模式，在网络间传送的是文件。
如果不走NAS，在本地文件系统上面部署OSD服务端，把整个设备做成一个OSD，这样的节点多来几个，再加上必要的MDS节点，互联网另一端的应用程序再通过HTTP协议直接进行访问，这就变成了对象存储的访问模式。当然对象存储通常不需要专业的存储设备，前面那些LV/VG/PV层也可以统统不要，直接在硬盘上做本地文件系统，之后再做成OSD，这种才是对象存储的标准模式，对象存储的硬件设备通常就用大盘位的服务器。
从系统层级上来说，这三种存储是按照块->文件->对象逐级向上的。文件一定是基于块上面去做，不管是远端还是本地。而对象存储的底层或者说后端存储通常是基于一个本地文件系统(XFS/Ext4..)。这样做是比较合理顺畅的架构。但是大家想法很多，还有各种特异的产品出现，我们逐个来看看：
对象存储除了基于文件，可以直接基于块，但是做这个实现的很少，毕竟你还是得把文件系统的活给干了，自己实现一套元数据管理，也挺麻烦的。另外对象存储还能基于对象存储，这就有点尴尬了，就是转一下，何必呢?但是这都不算最奇怪的，最奇怪的是把对象存储放在最底层，那就是这两年大红的Ceph。
Ceph是个开源的分布式存储，相信类似的架构图大家都见过，我把底层细节也画出来，方便分析。
底层是RADOS，这是个标准的对象存储。以RADOS为基础，Ceph 能够提供文件，块和对象三种存储服务。其中通过RBD提供出来的块存储是比较有价值的地方，毕竟因为市面上开源的分布式块存储少见嘛(以前倒是有个sheepdog，但是现在不当红了)。当然它也通过CephFS模块和相应的私有Client提供了文件服务，这也是很多人认为Ceph是个文件系统的原因。另外它自己原生的对象存储可以通过RadosGW存储网关模块向外提供对象存储服务，并且和对象存储的事实标准Amazon S3以及Swift兼容。所以能看出来这其实是个大一统解决方案，啥都齐全。
上面讲的大家或多或少都有所了解，但底层的RADOS的细节可能会忽略，RADOS也是个标准对象存储，里面也有MDS的元数据管理和OSD的数据存储，而OSD本身是可以基于一个本地文件系统的，比如XFS/EXT4/Brtfs。在早期版本，你在部署Ceph的时候，是不是要给OSD创建数据目录啊?这一步其实就已经在本地文件系统上做操作了(现在的版本Ceph可以直接使用硬盘)。
现在我们来看数据访问路径，如果看Ceph的文件接口，自底层向上，经过了硬盘(块)->文件->对象->文件的路径;如果看RBD的块存储服务，则经过了硬盘(块)->文件->对象->块，也可能是硬盘(块)->对象->块的路径;再看看对象接口(虽然用的不多)，则是经过了硬盘(块)->文件->对象或者硬盘(块)->对象的路径。
虽说现在大家都这么随便结合，但是这三种存储本质上还是有不同的，我们回到计算机的基础课程，从数据结构来看，这三种存储有着根本不同。块存储的数据结构是数组，而文件存储是二叉树(B,B-,B+,B*各种树)，对象存储基本上都是哈希表。
数组和二叉树都是老生常谈，没有太多值得说的，而对象存储使用的哈希表也就是常听说的键值(KeyVaule型)存储的核心数据结构，每个对象找一个UID(所谓的“键”KEY)，算哈希值(所谓的“值Vaule”)以后和目标对应。找了一个哈希表例子如下：
键值对应关系简单粗暴，毕竟算个hash值是很快的，这种扁平化组织形式可以做得非常大，避免了二叉树的深度，对于真·海量的数据存储和大规模访问都能给力支持。所以不仅是对象存储，很多NoSQL的分布式数据库都会使用它。
顺便说一句，这类NoSQL的出现有点打破了数据库和文件存储的天然屏障，原本关系数据库里面是不会存放太大的数据的，但是现在像MongoDB这种NoSQL都支持直接往里扔大个的“文档”数据，所以从应用角度上，有时候会把对象存储，分布式文件系统，分布式数据库放到一个台面上来比较，这才是混搭。
当然实际上几个开源对象存储比如swift和ceph都是用的一致性哈希，进阶版，最后变成了一个环，首首尾相接，避免了节点故障时大量数据迁移的尴尬。
四、分布式存储在块存储、文件存储、对象存储的应用成效
软件定义分布式块存储还在发展阶段，当前其在产品成熟度、高性能、高可靠、功能方面还是与传统块存储有较大差距，国内软件定义块存储厂商也在做这方面的完善和追赶。
文件存储也有其契合的应用场景，其使用简单快捷，易于多主机共享，在要求带宽，要IOPS和延迟不敏感，但是又需要经常进行数据改(在存储上即时更改文件数据)的应用场景比较适合使用文件存储。
对象存储因为架构设计的限制其适合应用数据场景应该是：只进行全读和全写的应用场景海量数据场景。但需要经常进行数据改(在存储上即时更改数据)的应用场景使用对象存储就非常的太合适了。
对象存储可以用来替代NAS存储的一些使用场景。现在还有一种流行的做法就是用对象存储来做数据归档和备份。像优酷、爱奇艺上的视频(电影视频发布后一次写入对象存储后续不会有数据改操作的。)或是微信上的图片(图片只有上传写入和删除功能，你见腾讯啥时间让你在线编辑照片了。)这类应用就是对象存储的最爱。
总体是我个人认为分布式对象存储时最为成熟的软件定义分布式存储类型，现在多家对象存储厂商都支持多副本和EC校验码数据保护方式，通过EC校验码可以大幅提升有效可用容量做的类型传统RAID存储的容量使用率，大幅降低成本。
用户评论
块存储？文件存储？对象存储？感觉越来越像游戏了，哪家更强还得仔细了解下需求再决定！
有8位网友表示赞同！
这篇博文写的真好，我一直在纠结这个问题，终于有点明白了。现在做项目的时候就知道怎么选择了!
有13位网友表示赞同！
对开发者来说块存储速度快一些，文件存储操作简单，对象存储适合大规模数据处理…这篇文章总结得很全面，有知识点！
有18位网友表示赞同！
说实话，我经常弄混块存储和文件存储的区别，感觉这两个词太像了。幸好这篇文章帮我理清思路了。
有17位网友表示赞同！
虽然文章提到三种存储方式各有优缺点，但我还是觉得最终选择的标准应该取决于具体的应用场景啊！
有6位网友表示赞同！
我觉得对数据存储技术这个层面讲的不错！ 尤其对象存储的大规模处理优势很吸引人! 我正在做一些大数据的项目，这篇文章给了我不少启发!
有20位网友表示赞同！
对于小企业来说，块存储和文件存储的成本或许比较低吧？
有10位网友表示赞同！
感觉对象存储对于安全性和隔离性要求很高吗？ 还有具体的管理方案吗？
有7位网友表示赞同！
这篇文章写的太简洁了，有些技术细节我需要更深入的了解才能应用到实践中！
有12位网友表示赞同！
块存储的数据访问速度确实快啊，文件存储的操作方便快捷! 对象存储大规模处理数据很酷，希望能未来自己也弄明白它们的原理。
有18位网友表示赞同！
作为一名小白，这篇文章对三种存储方式的描述比较通俗易懂. 不过我更想了解一下他们的具体应用场景是怎样的。
有13位网友表示赞同！
块存储、文件存储、对象存储 … 我感觉名字越来越抽象了，能不能用通俗的解释来介绍下？
有12位网友表示赞同！
这个博文让我对数据存储有了更深的认识，原来还有这么多的选择！我会好好研究一下，看看哪种类型最适合我的项目需求。
有15位网友表示赞同！
块存储和文件存储的数据结构有什么不同呢？ 文章里没有说明清楚啊!
有9位网友表示赞同！
个人感觉这篇博文缺少一些具体的案例分析，这样更能帮助我们理解三种存储方式的优缺点！
有19位网友表示赞同！
我觉得文章应该多比较一下这些存储方式在不同场景下成本效益的变化。
有8位网友表示赞同！
块存储、文件存储、对象存储… 看起来像电脑里的内存空间一样啊?
有20位网友表示赞同！
这篇文章让我对数据存储有了更深入的理解，之前只是知道这些概念，现在理解了它们之间的区别和适用场景。
有14位网友表示赞同！
作为一名程序员，我对文章关于块存储、文件存储、对象存储三种存储方式之间优缺点对比非常感兴趣。希望能看到更多实用的案例分析!
有17位网友表示赞同！