七牛云：分布式存储的元数据设计

目前，GlusterFS在互联网行业中用的较少，在大型计算机中用的较多。它在设计上具有以下几个特点。 兼容POSIX文件系统：单机上的应用程序无需修改就可以放到GlusterFS上运行。没有中心节点：不存在单点故障和性能瓶颈。扩展能力：因为没有中心节点，所以GlusterFS的扩展能力无限，扩展多少台服务器都没有问题。

我们不讨论POSIX兼容的优劣,集中通过GlusterFS来讨论无中心节点设计中普遍遇到的一些难点。简单总结一下，以GlusterFS为代表的无中心设计带来的一些问题如下图所示。

Hadoop的设计目标是存大文件、做offline分析、可伸缩性好。Hadoop的元 数据存储节点（NameNode节点）属于主从式存储模式，尽量将数据加载到内存，能提高对数据的访问性能。另外，放弃高可用，可进一步提高元数据的响应 性能（NameNode的变更不是同步更新到从机，而是通过定期合并的方式来更新）。

Hadoop具有以下几方面优点。 为大文件服务：例如在块大小为64MB时，10PB文件只需要存储1.6亿条数 据，如果每条200Byte，那么需要32GB左右的内存。而元信息的QPS也不用太高，如果每次QPS能提供一个文件块的读写，那么1000QPS就能 达到512Gb/s的读写速度，满足绝大部分数据中心的需求。 为offline业务服务。高可用服务可以部分牺牲。 为可伸缩性服务。可以伸缩存储节点，元信息节点无需伸缩。 然而有如此设计优点的Hadoop为什么不适合在公有云领域提供服务呢？ 元信息容量太小。在公有云平台上，1.6亿是个非常小的数字，单个热门互联网应用的数据都不止这些。1.6亿条数据占用32GB内存，100亿条数据需要2000GB内存，这时Hadoop就完全扛不住了。 元信息节点无法伸缩。元信息限制在单台服务器，1000QPS甚至是优化后的15000QPS的单机容量远不能达到公有云的需求。 高可用不完美。就是前面所提到的NameNode问题，在业务量太大时，Hadoop支撑不住。 因此，做有中心的云存储时，通常的做法是完全抛弃掉原先的单中心节点设计，引入一些其他的设计。

下面，我们简单总结一下以Hadoop为代表的有中心的存储设计速存在的问题。

GridFS：GridFS基于MongoDB，相当于一个文件存储系统，是一种分块存储形式，每块大小为255KB。数据存放在两个表里，一个表是chunks，加上元信息后单条记录在256KB以内；另一个表是files，存储文件元信息。

GridFS的优点如下所述。 可以一次性满足数据库和文件都需要持久化这两个需求。绝大部分应用的数据库数据需要持久化，用户上传的图片也要做持久化，GridFS用一套设施就能满足，可以降低整个运维成本和机器采购成本。拥有MongoDB的全部优点：在线存储、高可用、可伸缩、跨机房备份。支持Range GET，删除时可以释放空间（需要用MongoDB的定期维护来释放空间）。

GridFS的缺点如下所述

HBase：前面提到Hadoop因为NameNode容量问题，所以不适合用来做小文件存储，那么HBase是否合适呢？

HBase有以下优点。 伸缩性、高可用都在底层解决了。容量很大，几乎没有上限。

但缺点才是最关键的，HBase有以下缺点。微妙的可用性问题：首先是Hadoop NameNode的高可用问题。其次，HBase的数据放在Region上，Region会有分裂的问题，分裂和合并的过程中Region不可用，不管用 户这时是想读数据还是写数据，都会失败。虽然可以用预分裂回避这个问题，但这就要求预先知道整体规模，并且key的分布是近均匀的。在多用户场景 下，key均匀分布很难做到，除非舍弃掉key必须按顺序这个需求。 大文件支持：HBase对10MB以上的大文件支持不好。改良方案是将数据拼接成大文件，然后HBase只存储文件名、offset和size。这个改良方案比较实用，但在空间回收上需要补很多开发的工作。 应对方案是HBase存元数据，Hadoop存数据。但是，Hadoop是为 offline设计的，对NameNode的高可用考虑不充分。HBase的Region分拆和合并会造成短暂的不可用，如果可以，最好做预拆，但预拆也 有问题。如果对可用性要求低，那么这种方案可用。

Hadoop的问题是NameNode压力过高，那么FastDFS的思路是给 NameNode减压。减压方法是将NameNode的信息编码到key中。对于范例URL:group1/M00/00/00 /rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt来说，NameNode只需要做一件事，将group1翻译成具体的机器 名字，不用关心key的位置，只要关心组的信息所在的位置，而这个组的信息就放在key里面，就绕过了之前的问题。

FastDFS的优点如下。 结构简单，元数据节点压力低扩容简单，扩容后无需重新平衡

FastDFS的缺点如下。 不能自定义key：这对多租户是致命的打击，自己使用也会降低灵活性。 修复速度：磁盘镜像分布，修复速度取决于磁盘写入速度，比如4TB的盘，100MB/s的写入速度，至少需要11个小时。 大文件冲击问题没有解决：首先，文件大小有限制（不能超过磁盘大小）；其次，大文件没有分片，导致大文件的读写都由单块盘承担，所以对磁盘的网络冲击很大。