传统的HDFS单Namenode架构的局限性

先来看看几个基本概念：
1.Namespace（命名空间）：
1）.有目录文件以及block组成
2）.他支持所有对于命名空间相关系统的操作，如增删改查。
2.Block Storage Service （快存储服务）有两个部分
1）.管理Block（在NameNode中完成）
a.通过控制注册以及阶段性的心跳，来保证DataNode在正确运行
b.运行block信息报告，维护block的位置信息。
c.支持所有对于block位置信息的操作，如增删改查。
d.管理block之间的更换交替，并且删除被替换的block。
2）.存储由DataNodes提供，他们将block存储在本地系统中，允许读写访问。

一，单NameNode架构的局限性

1，Namespace（命名空间）的限制

由于Namenode在内存中存储所有的元数据（metadata），因此单个Namenode所能存储的对象（文件+块）数目收到Namenode所在JVM的heap size的限制。

2，性能的瓶颈（吞吐量）

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量。

3，隔离问题

由于HDFS仅有一个Namenode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

4，集群的可用性

在只有一个Namenode的HDFS中，此Namenode的宕机无疑会导致整个集群不可用。

5，Namespace和Block Management的紧密耦合

当前在Namenode中的Namespace和Block Management组合的紧密耦合关系会导致如果想要事项另外一套Namenode方案会比较困难，而且也限制了其他想要直接使用快存储的应用。

6，为什么纵向扩展目前的NameNode不可行？

比如将Namenode的Heap空间扩大到512GB。
第一个问题就是启动问题，启动花费的时间太长。当前具有50GB的Heap Namenode的HDFS启动一次大概需要30分钟到2个小时，那512GB呢？
第二个潜在的问题就是Namenode在Full GC时，如果发生错误将会导致整个集群宕机。
第三个问题是对大JVMHeap进行调试比较困难。优化Namenode的内存使用性价比比较低。