七牛云：分布式存储的元数据设计
1、无中心的存储设计，如GlusterFS
有中心的存储设计，如Hadoop
基于数据库的存储设计，如GridFS和HBase
绕过元数据的存储设计，如FastDFS
1、目前，GlusterFS在互联网行业中用的较少，在大型计算机中用的较多。它在设计上具有以下几个特点。
兼容POSIX文件系统：单机上的应用程序无需修改就可以放到GlusterFS上运行。
没有中心节点：不存在单点故障和性能瓶颈。
扩展能力：因为没有中心节点，所以GlusterFS的扩展能力无限，扩展多少台服务器都没有问题。
2、我们不讨论POSIX兼容的优劣,集中通过GlusterFS来讨论无中心节点设计中普遍遇到的一些难点。简单总结一下，以GlusterFS为代表的无中心设计带来的一些问题如下图所示。
1、Hadoop的设计目标是存大文件、做offline分析、可伸缩性好。Hadoop的元数据存储节点（NameNode节点）属于主从式存储模式，尽量将数据加载到内存，能提高对数据的访问性能。另外，放弃高可用，可进一步提高元数据的响应性能（NameNode的变更不是同步更新到从机，而是通过定期合并的方式来更新）。
2、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支撑不住。
因此，做有中心的云存储时，通常的做法是完全抛弃掉原先的单中心节点设计，引入一些其他的设计。
3、下面，我们简单总结一下以Hadoop为代表的有中心的存储设计速存在的问题。
1、GridFS：GridFS基于MongoDB，相当于一个文件存储系统，是一种分块存储形式，每块大小为255KB。数据存放在两个表里，一个表是chunks，加上元信息后单条记录在256KB以内；另一个表是files，存储文件元信息。
2、GridFS的优点如下所述。
可以一次性满足数据库和文件都需要持久化这两个需求。绝大部分应用的数据库数据需要持久化，用户上传的图片也要做持久化，GridFS用一套设施就能满足，可以降低整个运维成本和机器采购成本。
拥有MongoDB的全部优点：在线存储、高可用、可伸缩、跨机房备份。
支持Range GET，删除时可以释放空间（需要用MongoDB的定期维护来释放空间）。
3、GridFS的缺点如下所述
4、HBase：前面提到Hadoop因为NameNode容量问题，所以不适合用来做小文件存储，那么HBase是否合适呢？
5、HBase有以下优点。
伸缩性、高可用都在底层解决了。
容量很大，几乎没有上限。
6、但缺点才是最关键的，HBase有以下缺点。
微妙的可用性问题：首先是Hadoop NameNode的高可用问题。其次，HBase的数据放在Region上，Region会有分裂的问题，分裂和合并的过程中Region不可用，不管用户这时是想读数据还是写数据，都会失败。虽然可以用预分裂回避这个问题，但这就要求预先知道整体规模，并且key的分布是近均匀的。在多用户场景下，key均匀分布很难做到，除非舍弃掉key必须按顺序这个需求。
大文件支持：HBase对10MB以上的大文件支持不好。改良方案是将数据拼接成大文件，然后HBase只存储文件名、offset和size。这个改良方案比较实用，但在空间回收上需要补很多开发的工作。
应对方案是HBase存元数据，Hadoop存数据。但是，Hadoop是为offline设计的，对NameNode的高可用考虑不充分。HBase的Region分拆和合并会造成短暂的不可用，如果可以，最好做预拆，但预拆也有问题。如果对可用性要求低，那么这种方案可用。
1、Hadoop的问题是NameNode压力过高，那么FastDFS的思路是给NameNode减压。减压方法是将NameNode的信息编码到key中。对于范例URL:group1/M00/00/00/rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt来说，NameNode只需要做一件事，将group1翻译成具体的机器名字，不用关心key的位置，只要关心组的信息所在的位置，而这个组的信息就放在key里面，就绕过了之前的问题。
2、FastDFS的优点如下。
结构简单，元数据节点压力低
扩容简单，扩容后无需重新平衡
3、FastDFS的缺点如下。
不能自定义key：这对多租户是致命的打击，自己使用也会降低灵活性。
修复速度：磁盘镜像分布，修复速度取决于磁盘写入速度，比如4TB的盘，100MB/s的写入速度，至少需要11个小时。
大文件冲击问题没有解决：首先，文件大小有限制（不能超过磁盘大小）；其次，大文件没有分片，导致大文件的读写都由单块盘承担，所以对磁盘的网络冲击很大。
1、上面着重对几种存储设计进行了比较全面的分析，总结如下。
