2020-03-24 19:11:40

1、块存储

- 典型设备： 磁盘阵列，硬盘

- 主要是将裸磁盘空间映射给主机使用的。

- 使用场景：

• - docker容器、虚拟机远程挂载磁盘存储分配。

• - 日志存储。

• - 文件存储。

• - ...

2、文件存储

- 典型设备： FTP、NFS服务器为了克服块存储文件无法共享的问题，所以有了文件存储。在服务器上架 设FTP与NFS服务，就是文件存储。

- 使用场景：

• - 日志存储。

• - 多个用户有目录结构的文件存储共享。

• - ...

文件存储通常需要一个app 的服务器将文件存储挂载到本地。

3、对象存储

- 典型设备： 内置大容量硬盘的分布式服务器(swift, s3)，多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。

- 使用场景： (适合更新变动较少的数据，没有目录结构, 不能直接打开/修改文件)

• - 图片存储。

• - 视频存储。

• - 文件

• - 软件安装包

• - ...

对象存储实际上更贴近http的应用。

区别说明：

    通常我们说存储分为块、文件和对象，从应用场景来看：

    对象存储近年来在国内市场逐渐火热起来，主要是特定行业的海量非结构化数据的应用场景。由于对象存储采用扁平的文件组织方式，所以在文件量上升至千万、亿级别，容量在PB级别的时候，这种文件组织方式下的性能优势就显现出来了，文件不在有目录树深度的问题，历史和近线数据有同样的访问效率。另外，对象存储多采用分布式架构，可以在商用x86服务器上轻松构建对象存储，磁盘介质也大多采用低速的SATA盘，所以在成本上也具优势。

    块存储主要用于结构化数据类应用，在相对小的容量空间上可以提供更高的IO性能，所以从后端存储产品形态上来看，一般是多控多活的紧耦合集中式SAN架构，存储介质大多采用高速的SAS和近年来已成主流的固态硬盘，前端多采用FC光纤协议组网。另外，存储双活、存储虚拟化、存储复制等技术也支撑着这块的生态。

    文件存储主要是集中式或分布式的NAS类应用，以灵活的共享文件系统为特色，承载百万文件量和TB级别的文件类应用。

    我的总结：说白了，块存储，是最底层的存储，它关注的是磁盘的基本存储单元——块（Block），块存储可以没有软件服务器。而文件存储（像NAS）和对象存储（S3、七牛云），是软件层面的存储，底层也是基于块存储的。而文件存储和对象存储的区别在于，他们组织文件的方式，文件存储是有目录树的、有标准属性的（权限、用户、读写），而对象存储是扁平的、没有目录的、附加属性是灵活的，他们的接口协议也不一样。对象存储接口主要以S3与Swift为代表，其接口就是简单的GET、PUT、DEL和其他扩展，文件存储的话是以POSIX接口为主，以libcephfs为代表。有些分布式存储，比如Ceph，是同时支持块存储、对象存储和文件存储的，只是对应的接口不同，强烈建议看下这篇文章：一篇文章让你理解Ceph的三种存储接口(块/文件/对象)

    这三种存储，分别对应了不同的访问协议，这也就决定了他们的本质差别。

• 先说一下文件存储，主要操作对象是文件和文件夹。以 NFS 为例，文件相关的接口包括：LOOKUP/ACCESS/READ/WRITE/CREATE/REMOVE/RENAME 等等，文件夹相关的接口包括：MKDIR/RMDIR/READDIR 等等。同时也会有 FS_STAT/FS_INFO 等接口用于提供文件系统级别的信息。POSIX，SAMBA 等也是文件存储协议。协议更注重接口的灵活，以及访问权限控制。

• 块存储，主要操作对象是磁盘。以 SCSI 为例，主要接口有 Read/Write/Read Capacity/Inquiry 等等。FC，iSCSI，也是块存储协议。和文件存储相比，没有文件和目录树的概念，一般协议也不会定义磁盘的创建和删除操作。协议更注重传输控制。

• 对象存储，主要操作对象是对象（Object）。以 S3 为例，主要接口有 PUT/GET/DELETE 等。和块存储相比，没有随机读写的接口。和文件存储相比，没有目录树的概念。协议更注重简洁。

问两个问题：

    0、文件存储，底层是块存储。那么对象存储，底层也是文件存储吗？这个问题有点难解释，后面单独说明。

    1、FastDFS、HDFS属于文件存储还是对象存储？答案：对象存储。或者说“基于文件存储的对象存储”。

    2、作为容器的持久化卷，应该用那种存储？答案：要使用块存储，或支持POSIX接口的文件存储，比如NAS、GlusterFS、CephFS等。

解释：

    对象存储，底层不一定是文件存储，也可能是跳过文件，直接到块存储。我们通常眼睛看见的文件，只不过是操作系统给我们形象化的数据标志（一个图标、一个名字），对文件的操作是基于操作系统的文件系统函数。但是文件系统不止一种，有一些虚拟的文件系统，它甚至可以不直接使用操作系统的文件系统，而是直接调用更底层的命令，甚至直接操作物理存储的块数据。这个地址：http://www.dbseeker.com/blog/?post=7，是说Oracle的底层数据存储，可以看到Oracle自己做了一个逻辑卷管理，这个逻辑卷管理，它的逻辑块可以直接映射物理块数据。这里再做个答疑：Oracle能部署在NAS卷上面吗？答案是：可以，但是性能下降很大（有人说下降100倍），理论上可以，那是因为NAS磁盘，应该是兼容操作系统内核的绝大部分API，Oracle的逻辑卷管理，也是用的操作系统的底层API（非上层的文件系统API），所以没问题。但是NAS和本地磁盘还是有所区别，比如阿里云的官方文档上写着NAS 上使用 inotifywait （Linux文件系统函数）存在的问题，另外NAS的应用场景里面没有提到数据库：NAS的应用场景。

    当然，并不是所有对象存储，都跳过了文件系统，像Kafka、HDFS的数据，都是直接写文件，只是会将原文件拆分，而FastDFS更省事，直接将原文件完整保存下来，本质上这些都是基于文件存储来实现的（但是HDFS、FastDFS的归类还是对象存储）。

关于POSIX标准、文件系统类型、VFS及FUFS，参见这篇文章：《文件系统、POSIX标准及VFS》

1.HDFS系统文件引入分块存储

磁盘是由数据块组成的，一般默认大小是512字节，构建磁盘之上的文件系统一般是磁盘块的整数倍。

在HDFS系统中，为了便于文件的管理和备份，引入分块概念（block）。这里的块是HDFS存储系统当中的最小单位，HDFS默认定义一个块的大小为64MB。当有文件上传到HDFS上时，若文件大小大于设置的块大小，则该文件会被切分存储为多个块，多个块可以存放在不同的DataNode上，整个过程中 HDFS系统会保证一个块存储在一个datanode上 。但值得注意的是 如果某文件大小没有到达64MB，该文件并不会占据整个块空间 。

HDFS中的NameNode会记录在上述文件分块中文件的各个块都存放在哪个dataNode上，这些信息一般也称为元信息(MetaInfo) 。元信息的存储位置由dfs.name.dir指定。

####################################################################################

2.使用存储块的好处

假如上传的一个文件非常大，没有任何一块磁盘能够存储，这样这个文件就没法上传了，如果使用块的概念，会把文件分割成许多块，这样这个文件可以使用集群中的任意节点进行存储。

数据存储要考虑容灾备份，以块为单位非常有利于进行备份，HDFS默认每个块备份3份，这样如果这个块上或这个节点坏掉，可以直接找其他节点上的备份块。还有就是，有的时候需要将备份数量提高，

这样能够分散机群的读取负载，因为可以在多个节点中寻找到目标数据，减少单个节点读取。

################################################################################################

3.为什么64MB或者128MB或256MB是最优的选择？

原因：（普通文件系统的数据块大小一般为4KB）减少硬盘寻道时间(disk seek time) HDFS设计前提是支持大容量的流式数据操作，所以即使是一般的数据读写操作，涉及到的数据量都是比较大的。
假如数据块设置过少，那需要读取的数据块就比较多，由于数据块在硬盘上非连续存储，普通硬盘因为需要移动磁头，所以随机寻址较慢，读越多的数据块就增大了总的硬盘寻道时间。当硬盘寻道时间比io时间还要长的多时，那么硬盘寻道时间就成了系统的一个瓶颈。合适的块大小有助于减少硬盘寻道时间，提高系统吞吐量。

减少NameNode内存消耗。

对于HDFS，他只有一个Namenode节点，他的内存相对于Datanode来说，是极其有限的。

然而，namenode需要在其内存FSImage文件中中记录在Datanode中的数据块信息，假如数据块大小设置过少，而需要维护的数据块信息就会过多，那Namenode的内存可能就会伤不起了。

##################################################################################################

4.为什么不能远大于64MB或者128MB或256MB？

这里主要从上层的MapReduce框架来讨论

（1）Map崩溃问题：

系统需要重新启动，启动过程需要重新加载数据，数据块越大，数据加载时间越长，系统恢复过程越长。

（2）监管时间问题：

主节点监管其他节点的情况，每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔，主节点记录下这个节点状态为死亡，

并把分配给这个节点的数据发到别的节点。对于这个“预设的时间间隔”，这是从数据块的角度大概估算的。假如是对于64MB的数据块，我可以假设你10分钟之内无论如何也能解决了吧，

超过10分钟也没反应，那就是死了。可对于640MB或是1G以上的数据，我应该要估算个多长的时间呢？估算的时间短了，那就误判死亡了，更坏的情况是所有节点都会被判死亡。

估算的时间长了，那等待的时间就过长了。所以对于过大的数据块，这个“预设的时间间隔”不好估算。

（3）Map任务上：

因为MapReducer中一般一个map处理一个块上的数据，如果块很大，任务数会很少(少于集群中的节点个数)这样执行效率会明显降低。

###################################################################################

5.为什么分片大小需要与HDFS数据块（分块）大小一致

hadoop将mapReduce的输入数据划分为等长的小数据块，称为输入分片或者分片，hadoop为每个分片构建一个map任务。

hadoop在存储有输入数据（HDFS中的数据）的节点上运行map任务，可以获得高性能，这就是所谓的数据本地化。所以最佳分片的大小应该与HDFS上的块大小一样，因为如果分片跨越2个数据块，对于任何一个HDFS节点（基本不肯能同时存储这2个数据块），分片中的另外一块数据就需要通过网络传输到map任务节点，与使用本地数据运行map任务相比，效率则更低！

大家好，学习时间又到啦。今日我们来聊一聊块存储、文件存储和对象存储的区别。这个问题老生常谈了，在网上会出现许多的解释，可是大多数相对比较抽象一些，此次我选择用抽象和简易两种方式给各位分享一下体会心得。

首先咱用靠谱的方式进行解释：

1、块存储

可以看作为是裸盘，最明显的特点是不可以被操作系统直接浏览。可以凭借划分逻辑卷、做RAID、LVM等方式将它格式化，可以格式化为你所指定的文件系统（Ext3，Ext4，NTFS，FAT32等），随后才可以被操作系统浏览。比较常见的DAS、FC-SAN、IP-SAN基本都是块存储。它的优势是：读写速度快（带宽和IOPS）；可是缺点也一样明显：太过于底层，不利扩展，不可以被共享。

2、文件存储

文件存储可以分成本地文件存储和网络文件存储。文件存储最明显的特点是支持POSIX的文件浏览接口：open、read、write、seek、close等；优势是：有利于扩展&共享；缺点是：读写速度比较慢。

3、对象存储

有种表述是对象存储一定是分布式存储，其实不是。这是因为分布式文件存储可能是分布式存储，而不一定是对象存储。比较常见的对象存储有摩杜云的MOS，而实际对象存储是什么，可以去看摩杜云的帮助文档。

接下来便是简言易赅的解释了，从三者的数据“使用者”来进行区别：

1.块存储的“使用者”是可以读写块设备的软件系统，比如EXT3、EXT4等传统文件系统，或是数据库。

2.文件存储的“使用者”是我们操作人员，真真正正的自然人。

3.对象存储的“使用者”则是其它的计算机软件，比如OpenStack里调用镜像文件的glance模块。

本篇文章就分享到这里，相信大家看完之后有一定的收获，如果想了解更多相关内容，可以关注摩杜云行业资讯频道，更多精彩内容等着你来看！感谢各位的阅读！