在Hypertable或其他类似BigTable的系统中，元数据一般采用一种两级的类B+树结构，这主要是出于规模的考虑：采用这种结构理论上可以支持存放并索引2EB的用户数据。若要索引这么多用户数据，所需的元数据就高达16TB,一台机器是存不下的，因此在类BigTable系统中，元数据也是分布在不同节点上进行管理的，集群中任意一个节点既可能包含用户Range也可能包含元数据Range.

    虽然这种做法可以解决规模问题，但在管理上带来了一些困难，特别是进行故障恢复时，由于用户表的Range恢复过程中需要读取元数据，所以必须先恢复METADATA表中的Range,再恢复用户表中的Range.如果有多台Range Server同时故障，这种跨节点的依赖性处理起来非常困难，其他一些维护性操作同样具有类似问题。此外，由于一条METADATA实际上覆盖了一个200MB的Range,所以任何一台包含METADATA的Range Server发生故障，都可能导致这部分METADATA所涵盖的一大批数据不可访问。将METADATA分布到多个不同的Range Server上，无异于给系统增加了很多单点，降低了系统可靠性。

    解决：本着简单原则，我们认为将元数据与用户数据分离，放在专用的Meta Range Server上更具有可操作性。元数据集中化的唯一缺点是，由于受Meta Range Server内存限制，32GB物理内存所能存放的元数据理论上只能支持上PB的用户数据。但考虑一般机房所能容纳的机器规模，PB级的数据规模完全可以满足大多数公司的需要。
 

    图3 Hypertable高可用改进架构示意图

    图3给出了Hypertable元数据集中管理的整体结构。目前的实现将Hypertable中的数据服务器（Range Server）分为两种：Meta Range Server和User Range Server.Meta Range Server只管理Root表和METADATA表的Range,User Range Server只管理用户表的Range.由于Master的负载较轻，因此一般将Meta Range Server与Master放在同一个节点上。

    系统启动时，每个Range Server从配置文件得知自己的类型，并在注册时汇报自己的类型。Master记录每台Range Server的信息。当Master需要将Range分配给Range Server时（例如表格创建和Range分裂），会根据Range所在表格的类型来选择合适的Range Server,元数据Range分配到Meta Range Server,用户Range则分配到User Range Server.



优化Hypertable系统随机性能 图

Hypertable内存优化 图

Hypertable的安全停机策略

Hypertable的分裂日志策略

Hypertable集群故障处理

Hypertable与HBase业务应用比对 图

 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。