分布式文件系统的设计与实现(2)
时间:2018-07-21 14:02 来源:毕业论文 作者:毕业论文 点击:次
行业中，单机存储型服务器的最大容量大多在3 TB 到 12 TB 之间。单机的垂直 扩展能力有限。而且单机容易存在单点问题，如果某台存储节点损坏，容易造 成服务的中断。 另一个问题是，对于文件数据巨大的情况下，不论是文件索引的查询能 力，还是磁盘的寻道，都十分的耗时。传统的内核级的文件系统，例如 Ext4， 文件都是遵循目录层级安排，并且每个文件都有大量的元数据，例如文件的读 写执行权限，文件的创建时间、最后修改时间、最后访问时间，文件的所有者 和隶属的用户组。在文件体积相对较大，数量不是很多的时候，这些元数据并 不会成为很大的问题。但是一旦单机存储了几百万甚至数十亿个文件的时候， 元数据也会变得十分庞大，索引查询也会十分耗时。导致整体的读写性能急剧 下滑。 但是目前处于的数据爆炸时代，文件数量都是以亿计，数据总量都是以 PB 计，给传统型存储带来了很大的挑战。与高端可靠高性能存储设备相比，云时 代更加青睐于使用廉价不可靠的设备，通过软件的方式来实现高可靠和高性 能。 本文在研究国内外的论文的基础上，针对大量小文件存储的场景，自行设 计了一种高可用、高性能、高扩展以及大容量存储的基于 Key-Value模型的分 布式文件系统。 1.2 国内外研究概况 随着 2003 年 Google File System[3] （GFS）的设计论文出现，及后来基于此 论文的开源实现 Hadoop Distributed File System（HDFS）[13][14] 的广泛应用，大 文件存储得到了较好的解决。亚马逊的云服务 S3[15] 就是很成功的商业应用。大 文件存储的特点是文件通常都是 100 MB到数 GB大小，所以在 GFS 和开源实 现 HDFS 中，都把文件切分成 64 MB大小的块。但是针对数量巨大的小文件， 典型场景是淘宝主站的百亿张商品图片，文件大小通常只有几十到几百 KB， 远小于 64 MB的块大小。正如 Google File System的论文阐述的那样，并未针 对此种小文件存储做优化，所以效率不是很高。为了解决图片文件存储的问 题，Facebook 发布了他们的 Haystack[2] 系统的设计论文。专门解决他们超过 2600 亿的图片，大约有 20 PB的数据量。用户每个星期还会上传10 亿张新照 片（60 TB），Facebook 在峰值时需ᨀ供每秒查询超过100 万张图片的能力。 但是这些方案都存在一定的问题。Haystack 在设计的时候就是为了满足 Facebook 大量图片存储的需求，所以把 CDN 作为了整个架构的一环，导致了 这个方案十分适合 Facebook 的图片存储业务。但是对于其他公司，只是需要一 个高可靠的小文件存储系统而言，就很难移植过来。Facebook 的这个设计方 案，是针对其图片存储并展示业务而优化的。但是通用而言，小文件存储不仅 仅是图片，还有一些例如百度文库中的文件，企业内部的消息记录，云存储业 务中，用户上传的个人文档，邮件业务中的附件，QQ 中的离线文件，通常都 属于小文件的范畴。这些应用场景中，不是所有的场景都需要使用CDN。就算 是企业需要使用CDN 的，大多CDN 都是使用别人的云服务，很少有自己自建 的CDN，所以要和底层的存储系统结合起来并不容易。而且从解耦的角度而 言，把底层的存储系统和上层的CDN 耦合在一起，并不是一个很好的通用设 计。所以，对于很多做云存储的公司而言，当只是需要一个高并发、高可靠、 高吞吐量、易扩容，不与上层业务耦合，较为通用的核心存储系统，目前尚无被广泛认可的方案。而且 Haystack 并未开源其实现的代码，其他公司无法直接 (责任编辑：qin) |