12
返回列表 发新帖
楼主: jieforest

Hypertable对比HBase应用实践

[复制链接]
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
11#
 楼主| 发表于 2013-5-8 10:35 | 只看该作者
随机访问

挑战:Hypertable支持顺序读和随机读,相比顺序读,随机读的性能并不好。由于随机读(非批量)性能较低,基于Hypertable的某些应用功能也很难实现,因此优化随机性能对支持更多应用以及提升系统整体性能都非常有好处。

如图8所示,使用IOzone对一些常见机型的机器磁盘做随机读测试,可以看到,如果访问落到磁盘,性能会非常差,最好吞吐也是小于2MB/s。



图8 各种机型磁盘随机读写吞吐对比

使用道具 举报

回复
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
12#
 楼主| 发表于 2013-5-8 10:35 | 只看该作者
解决:从磁盘分级、内存模式和Cache支持三个方面进行解决。

(1)磁盘分级向Hypertable系统导入470GB的原始数据,导入后经压缩实际占用360GB×3副本≈1.1TB磁盘空间,大约分裂为2600多个Range,平均每台服务器负责近300个。以下测试进行了3轮,每轮都分别进行单进程和多进程随机查询,每个进程共完成1000次查询。相对于第一轮,第二轮进行了两项优化:对row key进行了反转,例如1234→4321,从而使之分布更均匀;调整每个range的cell store个数上限到5(默认是10),第三轮则把cell store个数进一步缩小到1(通过发命令强制做major compaction)。测试结果如图9所示。



图9 cell store文件数配置不同时导入性能对比

使用道具 举报

回复
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
13#
 楼主| 发表于 2013-5-8 10:35 | 只看该作者
此测试最大的特点是数据量远大于内存总数,因此存在较多随机磁盘访问。以第二轮16进程查询为例,平均每个Range有4.4个Cell Store文件,因此每秒需要进行4.4×216≈950次HDFS文件随机访问。每读一次HDFS中的文件实际至少需要访问两个文件:一个blk文件和一个meta文件,因此每秒至少需要950×2=1900次随机磁盘访问,这还不算dentry cache miss和超时重试。观察发现,实际测试过程中最繁忙的节点每秒的磁盘随机读取次数达500多次,磁盘I/O利用率达到100%。第三轮测试同样有类似的规律。因此我们可以得出结论,数据量较大时,Hypertable的瓶颈在于磁盘随机I/O次数。

我们使用分层的方式来提升磁盘随机访问性能。固化存储分级为SSD/SATA/SAS,随机读性能要求高的应用数据存储到SSD,依次类推。测试发现,使用SSD,随机读性能提升60%以上,不过随机写性能会有部分下降,而且SSD的更新寿命约为1万个操作。

(2)内存模式

对于那些频繁访问的数据,我们可以将其设置为in memory方式,这些数据将一直驻留内存(直接用一个C++ std::map结构存起来的,本质上相当于使用了红黑树索引),因此随机查询时不用从文件里读,效率很高。

如果只用一台Range Server,使用1个进程查询同一行数据(共约600字节数据),速度可达4650次/s,若用16个进程并行查询,每秒总查询次数达到12700次,40进程时达到峰值16000次/s,相当于约10MB/s;如果每次查询50行数据(40进程并行查询),每秒查询次数下降到1300左右,但聚合带宽达到40MB/s。此过程Range Server的CPU sys时间较高(30%~40%),但user和iowait时间都比较低,因此认为瓶颈在网络RPC上。

使用道具 举报

回复
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
14#
 楼主| 发表于 2013-5-8 10:36 | 只看该作者
但in memory这种模式非常耗费内存,原因有以下两点。

1 由于Hypertable设计时为了支持稀疏表,每个value是单独存的,而不是按行存的,因此每个value都需要存一份key (包括row key、column family、column qualifier和timestamp,最小开销16字节),再加上map数据结构的开销24字节,一个value至少有40字节额外开销,一个帖子就是40×13=520字节,比帖子的实际内容(平均300多字节)还多。

2 为了支持高并发,Hypertable采用了MVCC(Multi-version Concurrency Control)模式存储<key, value>,也就是说,删改一个value时只是追加了一个补丁,而不是在原值基础上修改,多余的版本只有当Cell Cache大小达到一定程度时才会清理。

使用道具 举报

回复
论坛徽章:
58
马上加薪
日期:2014-05-22 17:23:14兰博基尼
日期:2013-10-28 16:48:53比亚迪
日期:2013-10-24 14:53:08法拉利
日期:2013-10-23 14:22:02三菱
日期:2013-10-23 12:33:08大众
日期:2013-10-23 10:23:25本田
日期:2013-10-16 10:24:23法拉利
日期:2013-10-15 09:01:46宝马
日期:2013-10-10 12:39:51ITPUB社区12周年站庆徽章
日期:2013-10-08 17:44:42
15#
发表于 2013-5-8 11:24 | 只看该作者
mark

使用道具 举报

回复
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
16#
 楼主| 发表于 2013-5-9 10:27 | 只看该作者
(3)Cache支持

当前版本的Hypertable依据当时的负载状况,动态调整分配给每个子系统的内存。对于读密集型的负载,Hypertable分配大部分内存给Block Cache;而HBase则固定分配20%的Java Heap作为Block Cache。此外,Hypertable还提供Query Cache机制,缓存查询结果,使得其随机访问性能超过了HBase,如图10所示。当然,Bloomfilter机制对HBase和Hypertable都支持,能够避免大量的无效访问。


图10 Hypertable vs. HBase随机读吞吐量测试

使用道具 举报

回复
论坛徽章:
277
马上加薪
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11版主9段
日期:2012-11-25 02:21:03ITPUB年度最佳版主
日期:2014-02-19 10:05:27现任管理团队成员
日期:2011-05-07 01:45:08
17#
 楼主| 发表于 2013-5-9 10:27 | 只看该作者
over.

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表