淘宝分布式文件系统存储引擎

本人的博客园网址
链接: link.
最近我在老师的带领下研究淘宝分布式文件系统存储引擎的源码。这也是我第一篇写在CSDN上的博客。
话不多说,直接切入正题。

淘宝为什么不适用普通的文件系统来存储海量小文件

  1. 我们知道普通文件在查询的时候是这样的,首先先在硬盘的目录项区搜寻我们要找的文件的inode number,而后根据这个inode number去inode table(存储的是关于每个文件的信息,诸如文件数量大小之类)中取得对应的inode信息,最后根据inode信息来得到小文件所在块(块也就是文件存取的最小单位,常见的由八个扇区来组成一个块,扇区是硬盘存储数据的最小单位,512kb,通常块的大小为4kb)。如此多次的查找过程,带来的是磁盘多次的寻址换道,时间浪费,效率低下。
  2. 另外,频繁的新增和删减,将会导致磁盘的碎片化,不同文件的存储所需要的磁盘空间不同,势必在删除文件的过程中导致有些空间无法及时地得到利用,降低了文件io的效率和磁盘的使用率。
  3. 如果采用普通文件的存储方式,inode信息如果需要缓存,将会占用大量的内存。缓存效果不好。

分布式文件系统架构

基于以上原因,淘宝采用分布式文件系统存储引擎。
1.使用一个个block来进行存储小文件,每个block的大小为64MB,每个块都用一个唯一的整数对其进行标识。block的存储空间进行预先分配。
2.每个block文件都对应有一个index索引文件,index索引文件将会在服务启动的时候映射如内存,以此来增加文件操作的速度。
3.索引文件可分为两个部分,其一是索引头部信息(indexheader)里面存储的是关于对应块文件的主要信息,其二是存储的MetaInfo,许多的metainfo存储的关于存储在块文件里的小文件的基本信息,以便于我们对于小文件的存取。其中metainfo采用哈希链表进行组织。

为便于理解,上图。
淘宝分布式文件系统存储引擎_第1张图片
可重用链表节点:当我们删除小文件信息时,为了避免不必要的移动,我们并不将其对应的metainfo删除,而是将其加入到可重用链表节点中,如此下一次插入小文件的时候,优先使用可重用链表节点中的节点。

BlockInfo结构
淘宝分布式文件系统存储引擎_第2张图片
有一定数据结构基础的,不难理解整个分布式存储引擎的架构。

如有错误,望不吝赐教!

你可能感兴趣的:(linux)