技术开发 频道

Hypertable数据库应用实践:比肩HBase

  【IT168 技术】Hypertable是一个开源、高性能、可伸缩的数据库,采用与Google的BigTable相似的模型。BigTable让用户可以通过一些主键来组织海量数据,并实现高效的查询。Hypertable和HBase分别是BigTable的两个开源实现:HBase主要使用Java语言开发,而Hypertable使用Boost C++,另外在一些细节的设计理念上也有所不同。

  Hypertable系统主要包括Hyperspace、Master和Range Server三大组件(如图1所示)。Hyperspace是一个锁服务,地位相当于Google的Chubby,主要用于同步、检测节点是否发生故障和存放顶层位置信息;Master主要用于完成任务分配,未来会有负载均衡以及灾后重建(Range Server失效后自动恢复服务)等其他作用;Range Server是Hypertable的实际工作者,主要负责对一个Range中的数据提供服务,此外它还肩负起灾后重建的责任,即重放本地日志恢复自身故障前状态;另外,还有访问Hypertable的客户端Client等组件。

Hypertable数据库应用实践:比肩HBase
▲图1 Hypertable原有架构示意图

  业务应用

  Facebook在SIGMOD 2011会议上介绍了基于Hadoop/HBase的三种应用系统:Titan(Facebook Messages)、Puma(Facebook Insights)和ODS(Facebook Internal Metrics)。Titan主要用于用户数据存储,Puma用于MapReduce分布式计算,ODS用于存储公司内部监控数据,Facebook基于HBase的应用方式与国内几大互联网公司类似。

  和ODS类似,对于一些硬件或软件的运行数据,我们会保存监控数据到数据库中,供软件工程师或者运维工程师查询。这里的查询可能是大批量的,也可能是个别条目;可能是延迟查询,也可能是即时查询。将此类业务的需求总结如下。

  ·要求存储容量非常大,往往达到10~100TB,10亿~100亿条记录。

  ·需要支持自动扩容,因为数据的增长模式不易估计,可能出现短时间的爆炸性增长。

  ·写吞吐的压力较大,每秒超过1万次的插入。

  ·近期导入数据能够快速检索。

  ·需要支持扫描早期的大量数据,例如支持周期性的检查或回滚。

  这里可选的一个方案是使用传统的DBMS(如MySQL)。但它存在如下弊端:首先MySQL单机存储有上限,一般超过1.5GB性能就会有波动;不过即使MySQL支持拆表,也并非完全分布式的,由于表的大小限制,对于不规则的数据增长模式,分布式MySQL也并不能很好地应对,如果抖动频率较大,需要引入较多的人工操作来进行数据迁移;再者MySQL也不支持表的Schema动态改变。另一个可选方式是使用Hadoop。不过MapReduce并非实时计算,并且HDFS不支持随机写,随机读性能也很差。

  综上分析,我们选择BigTable类型的系统来支持业务需求,即使用Hypertable+Hadoop的方式(如图2所示)。

Hypertable数据库应用实践:比肩HBase
▲图2 监控数据收集与查询示意图

  高可用改进

  1.元数据集中化

  挑战:在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级的数据规模完全可以满足大多数公司的需要。

Hypertable数据库应用实践:比肩HBase
▲图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。

0
相关文章