块存储、文件存储、对象存储三者之比较 | 资料( 六 ) _文件存储

现在我们来看数据访问路径，如果看Ceph的文件接口，自底层向上，经过了硬盘（块）->文件->对象->文件的路径；如果看RBD的块存储服务，则经过了硬盘（块）->文件->对象->块，也可能是硬盘（块）->对象->块的路径；再看看对象接口（虽然用的不多），则是经过了硬盘（块）->文件->对象或者硬盘（块）->对象的路径。
虽说现在大家都这么随便结合，但是这三种存储本质上还是有不同的，我们回到计算机的基础课程，从数据结构来看，这三种存储有着根本不同。块存储的数据结构是数组，而文件存储是二叉树（B,B-,B+,B*各种树），对象存储基本上都是哈希表。

数组和二叉树都是老生常谈，没有太多值得说的，而对象存储使用的哈希表也就是常听说的键值（KeyVaule型）存储的核心数据结构，每个对象找一个UID（所谓的“键”KEY），算哈希值（所谓的“值Vaule”）以后和目标对应。找了一个哈希表例子如下：

键值对应关系简单粗暴，毕竟算个hash值是很快的，这种扁平化组织形式可以做得非常大，避免了二叉树的深度，对于真·海量的数据存储和大规模访问都能给力支持。所以不仅是对象存储，很多NoSQL的分布式数据库都会使用它。
顺便说一句，这类NoSQL的出现有点打破了数据库和文件存储的天然屏障，原本关系数据库里面是不会存放太大的数据的，但是现在像MongoDB这种NoSQL都支持直接往里扔大个的“文档”数据，所以从应用角度上，有时候会把对象存储，分布式文件系统，分布式数据库放到一个台面上来比较，这才是混搭。
当然实际上几个开源对象存储比如swift和ceph都是用的一致性哈希，进阶版，最后变成了一个环，首首尾相接，避免了节点故障时大量数据迁移的尴尬。
四、分布式存储在块存储、文件存储、对象存储的应用成效

软件定义分布式块存储还在发展阶段，当前其在产品成熟度、高性能、高可靠、功能方面还是与传统块存储有较大差距，国内软件定义块存储厂商也在做这方面的完善和追赶。
文件存储也有其契合的应用场景，其使用简单快捷，易于多主机共享，在要求带宽，要IOPS和延迟不敏感，但是又需要经常进行数据改（在存储上即时更改文件数据）的应用场景比较适合使用文件存储。
对象存储因为架构设计的限制其适合应用数据场景应该是：只进行全读和全写的应用场景海量数据场景。但需要经常进行数据改（在存储上即时更改数据）的应用场景使用对象存储就非常的太合适了。
对象存储可以用来替代NAS存储的一些使用场景。现在还有一种流行的做法就是用对象存储来做数据归档和备份。像优酷、爱奇艺上的视频（电影视频发布后一次写入对象存储后续不会有数据改操作的。）或是微信上的图片（图片只有上传写入和删除功能，你见腾讯啥时间让你在线编辑照片了。）这类应用就是对象存储的最爱。
总体是我个人认为分布式对象存储时最为成熟的软件定义分布式存储类型，现在多家对象存储厂商都支持多副本和EC校验码数据保护方式，通过EC校验码可以大幅提升有效可用容量做的类型传统RAID存储的容量使用率，大幅降低成本。