HBase性能优化的四个要点

今天作者石头儿将给大家介绍HBase性能优化的四个要点。比如文件应该设置多大的默认值,autoflash的设置问题。 2013-01-10 09:47:09 HBase性能优化 两种方法解决mysql主从不同步 今天发现Mysql的主从数据库没有同步,下面说说我用的两种方法解决mysql主从不同步问题。 2013-01-09 10:36:28 mysql主从不同步 iOS开发中的SQLite知识总结 今天我们将会谈谈iOS开发中的SQLite方面的知识。包括查询优化,查看工具等等。 2013-01-06 09:52:43 SQLite 一步完成MySQL向Redis迁移 redis-cli命令行工具有一个批量插入模式,是专门为批量执行命令设计的。这第一步就是把Mysql查询的内容格式化成redis-cli可用的数据格式。here we go! 2013-01-06 09:43:35 MySQLMySQL迁移Redis Exadata X3闪存提升4倍 In-Memory进入主流 到 2015 年,65% 部署在私有云环境中的服务器将成为一体机。IDC认为一体机提供一种标准化架构,该架构可通过预配置和优化处理多重工作负,其卓越的建筑模块可减少部署时间,并增加不动产的投资回报。 2012-12-27 09:52:28 数据库云服务器Exadata X3内存计算 MySQL遭遇DELETE误操作的回滚 操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时。这里先说明下因为Delete 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了。 2012-12-26 09:36:45 MySQLDelete 大数据量下的SQL Server数据库自身优化 在大数据量之下,部分数据库由于信息量很大,查询频繁。可以采取把一些表或者一些表中的部分记录分开存储在不同的数据文件里的方式进行优化。 2012-12-26 09:23:56 数据库优化 数据科学家不用太多 应该让大数据更好用 大数据时代已经来临,因此数据科学家曾被冠以最性感职业之称。可是电子商务咨询公司Baynote创始人兼CTO Scott Brave 却说我们不需要更多的数据科学家,让大数据更方便使用就够了。 2012-12-25 09:58:50 数据科学家大数据 坐看大数据之道:51CTO专访大数据专家郑玮 原创 大数据的概念日趋火热,究竟国外的大数据技术是怎样的发展情况?对国内技术人员有什么借鉴作用?51CTO本次将专访大数据方面的专家郑玮女士。请她为我们讲述大数据之道。 2012-12-24 09:01:35 大数据 解读微软大数据 原创 “微软针对关系型数据、非关系型数据和数据流的管理,第一步是打造一个平台,在这个平台下,各种类型的数据都可以进来集中整合。第二步是提供一个工具,让所有的数据可以进行清理和分析。” 2012-12-20 13:02:20 大数据Hadoop内存计算 MariaDB成为MySQL命运转折点? 译文 MariaDB项目带来开放与创新之希望,陷入困境的MySQL社区能否借此焕发生机?Oracle的闭源阴谋能否得逞? 2012-12-19 14:21:25 MariaDBMySQL 维基逃离MySQL 力挺开源数据库 近日全球著名百科类网站维基百科宣布,将不会再用MySQL数据库,据国外媒体报道,很多年,MySQL一直是热门的开源数据库,不过在被甲骨文收购后,面临闭源的风险。因此维基百科将切换到另外一款开源数据库MariaDB。 2012-12-19 13:06:31 MySQL 微软数据仓库一体机国内首单花落国家审计总署 自云计算和大数据概念被提出后,针对该市场应运而生的解决方案层出不穷,软硬件一体化设备作为大数据解决方案中的一员,扮演着重要的角色。微软并行数据仓库一体机,将多种先进的数据存储与处理技术结合为一体,是微软大数据战略的重要组成部分。 2012-12-16 20:40:16 数据仓库一体机大数据 微软数据库一体机升级 新技术架构满足大数据挑战 原创 在技术门槛较高的大数据领域,有着传统优势的厂商是否能够依然占据主流,加速推动资源的整合、优化,提出端到端的一体化解决方案正变的尤为重要。 2012-12-16 16:50:52 数据库一体机PDW云计算 Erlang+C+Lisp的大数据方案:BugSense 译文 BugSense是一家专门报告错误、度量质量的服务商,每天跟踪成千上万个应用程序。移动应用程序崩溃时,BugSense可以帮助开发人员准确查明问题,并解决问题。这家新兴公司的客户包括VMWare、三星、Skype以及数千家独立应用软件开发商。这样规模的大数据解决方案,在Azure上运行不到20个大实例,这是如何实现的? 2012-12-07 10:15:45 ErlangLisp大数据 TechED 2012现场报道:SQL Server用户的难题 原创 2012年12月5日,微软TechED 2012技术大会在北京九华山庄举行。51CTO记者在大会现场对参会用户进行了采访。该用户为金融保险行业的王先生,他们正在使用SQL Server 2008。 2012-12-06 10:32:41 TechEd2013 BUG解析:InnoDB两次写与多实例buffer pool BUG还原:我实现了一个MYSQL多线程复制的patch,是按照表名来划分的,相同的表会分到同一个线程中做,实现的是BINLOG_FORMAT为STATEMENT的,那么这样就实现了并发。 2012-12-06 10:00:48 InnoDBMySQL PostgreSQL建立索引如何避免写数据锁定 写这篇blog源自一个帅哥在建索引发生了表锁的问题。正常情况下Postgresql建立普通btree索引时会阻塞DML(insert,update,delete)操作,直到索引完成,期间读操作不受阻塞。 2012-12-04 10:29:47 PostgreSQL索引 SQL Server高可用的常见问题 每次谈到SQL Server的高可用,很多的DBA,特别是SQL Server DBA心里一痛:因为大家都认为SQL Server无法或者很难实现SQL Server。也有很多的DBA朋友脑袋一拍,给出答案“高可用不就是微软的那几个技术吗,如Replication, Failover Clustering”… 2012-11-29 09:42:34 SQL Server高 InnoDB引擎数据库主从复制同步心得 原创 近期将公司的MySQL架构升级了,由原先的一主多从换成了DRBD+Heartbeat双主多从,正好手上有一个电子商务网站新项目也要上线了,用的是DRBD+Heartbeat双主一从,由于此过程还是有别于以前的MyISAM引擎的,所以这里也将其心得归纳总结了一下。 2012-11-26 10:17:44 InnoDB 百万数据下几种SQL性能测试 今天闲来学习了一下SQL性能优化方面的知识,有以下学习收获,欢迎大家指点。 2012-11-23 10:00:55 SQL性能测试 下一版SQL Server将支持In-Memory技术 微软计划为SQL Server增加In-Memory技术,旨在提升在线事务处理的性能。 2012-11-22 10:28:13 SQL Server 千万不要让关系数据库跟这十样事物掺合到一起 译文 关系数据库管理系统仍然稳居业界主导之地位。然而即使大家是彻头彻尾的甲骨文粉儿、为老式RAC中的PL/SQL架构所深深吸引,也请稳下心神、保持冷静。时代不同了,如今我们需要在着手执行任务之前认真考量,而绝不能仅凭个人好恶来选择解决方案。本文列出了十件事,是大家在使用关系数据库的时候一定要避免的。 2012-11-20 09:13:07 关系数据库Oracle 不是MongoDB不行,而是你不懂 MongoDB最近在Hack News上是平凡中枪,各种缺点被纷纷被抬上桌面;然而它的高性能、易部署、易使用这些优点同样是不容忽视的。于是就有了Russell Smith —— MongoDB Master,在一片嘘声中为我们带来MongoDB“诟病”的全面分析,并一一提出了解决方案。 2012-11-16 09:32:26 NoSQLMongoDB云服务 HBase看上去很美 我的项目失败之路 随着hadoop系列的兴起,基于HDFS的大规模KV存储系统HBase也进入“大规模使用阶段”。网上的Hbase资料很多,学习成本正在下降。从公开的资料看,国外Facebook、国内Taobao均宣称在线上环境大规模使用Hbase。一切都让人很兴奋。于是,在项目中引入Hbase做存储,最终却选择放弃。 2012-11-14 08:57:29 HBase 架构师眼中的MySQL开发模式 译文 2007年夏天,当我第一次以资深MySQL架构师的身份——这份工作一直伴随我走到现在——参与到企业业务当中时,议程备忘中的第一项内容就是讨论开发模式问题。2005年,也就是当时的两年之前我们推出了5.0版本,而接下来将要接棒的新一代MySQL 5.1还要一年多才会面世。但大家一致对MySQL 5.0与MySQL 5.1的开发模式感到不够理想,因此我们就如何做出改善问题展开了大量讨论。 2012-11-12 10:04:53 MySQL开发模式 Google Cloud SQL:10GB提升100GB免费半年 谷歌的云SQL是一项基于MySQL数据库的服务,应用引擎用户可以将其数据库迁移到云中,或者使用其现有的需要在应用引擎中进行数据库访问的应用程序。 2012-11-09 13:42:33 Google Clou 基于Redis构建系统的经验和教训 Redis 是一个非常快速和强大的 Key-Value 存储(持久化)系统, 相对于一般的 NoSQL 存储系统, 它最大的特点是支持丰富的数据结构. 特别是其 zset(sorted set)数据结构, 堪称表达能力最强的结构之一(其它强大的数据结构如 sorted hashmap), 可以直接地表达业务逻辑。 2012-10-30 10:09:56 Redis HBase如何合理设置客户端Write Buffer 本文将结合HBase相关源码,对其进行深入介绍,分析如何在实际项目中合理设置和使用它。 2012-10-17 09:50:47 HBase 程序员老鸟写sql语句的经验之谈 做管理系统的,无论是bs结构的还是cs结构的,都不可避免的涉及到数据库表结构的设计,sql语句的编写等。因此在开发系统的时候,表结构设计是否合理,sql语句是否标准,写出的sql性能是否优化往往会成为公司衡量程序员技术水平的标准。 2012-10-12 10:05:29 程序员SQL数据库 DB-Engines全新数据库排名Oracle居首 DB-Engines 发布最新的数据库系统排名,该排名中 Oracle 居首,而开源的 MySQL 数据库排名第三。详细的数据排行情继续看下文…… 2012-10-08 09:21:37 DB-EnginesOracle数据库 Windows下实现PostgreSQL自动备份 在我工作上一个使用PostgreSQL数据库的项目上需要一个自动化系统来每天执行备份。经过一番研究决定通过创建一个Windows批处理文件并添加到Windows计划任务中来实现。本文将详细介绍。 2012-09-28 13:39:40 Windows备份 巧用数据库连接监控组件解决关闭问题 日常开发中如果一开始没有对系统进行比较好的规划那么容易出现两类问题且在版本发布中屡见不鲜,这两类问题是配置文件和数据连接,这里为大家分享一个监视数据库连接的组件,文末有代码示例下载。 2012-09-26 10:20:06 数据库 MongoDB范围查询的索引优化 我们知道,MongoDB的索引是B-Tree结构的,和MySQL的索引非常类似。所以你应该听过这样的建议:创建索引的时候要考虑到sort操作,尽量把sort操作要用到的字段放到你的索引后面。但是有的情况下,这样做反而会使你的查询性能更低。

今天作者石头儿将给大家介绍HBase性能优化的四个要点。比如文件应该设置多大的默认值,autoflash的设置问题。

1 hbase.hregion.max.filesize应该设置多少合适

默认值:256M

说明:Maximum HStoreFile size. If any one of a column families' HStoreFiles has grown to exceed this value, the hosting HRegion is split in two.

HStoreFile的***值。如果任何一个Column Family(或者说HStore)的HStoreFiles的大小超过这个值,那么,其所属的HRegion就会Split成两个。

调优:

hbase中hfile的默认***值(hbase.hregion.max.filesize)是256MB,而google的bigtable论文中对tablet的***值也推荐为100-200MB,这个大小有什么秘密呢?

  众所周知hbase中数据一开始会写入memstore,当memstore满64MB以后,会flush到disk上而成为storefile。当storefile数量超过3时,会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据,比如update的数据。而当合并后的storefile大小大于hfile默认***值时,会触发split动作,将它切分成两个region。

  lz进行了持续insert压力测试,并设置了不同的hbase.hregion.max.filesize,根据结果得到如下结论:值越小,平均吞吐量越大,但吞吐量越不稳定;值越大,平均吞吐量越小,吞吐量不稳定的时间相对更小。

  为什么会这样呢?推论如下:

a 当hbase.hregion.max.filesize比较小时,触发split的机率更大,而split的时候会将region offline,因此在split结束的时间前,访问该region的请求将被block住,客户端自我block的时间默认为1s。当大量的region同时发生split时,系统的整体访问服务将大受影响。因此容易出现吞吐量及响应时间的不稳定现象

b 当hbase.hregion.max.filesize比较大时,单个region中触发split的机率较小,大量region同时触发split的机率也较小,因此吞吐量较之小hfile尺寸更加稳定些。但是由于长期得不到split,因此同一个region内发生多次compaction的机会增加了。compaction的原理是将原有数据读一遍并重写一遍到hdfs上,然后再删除原有数据。无疑这种行为会降低以io为瓶颈的系统的速度,因此平均吞吐量会受到一些影响而下降。

综合以上两种情况,hbase.hregion.max.filesize不宜过大或过小,256MB或许是一个更理想的经验参数。对于离线型的应用,调整为128MB会更加合适一些,而在线应用除非对split机制进行改造,否则不应该低于256MB

2 autoflush=false的影响

  无论是官方还是很多blog都提倡为了提高hbase的写入速度而在应用代码中设置autoflush=false,然后lz认为在在线应用中应该谨慎进行该设置。原因如下:

  a autoflush=false的原理是当客户端提交delete或put请求时,将该请求在客户端缓存,直到数据超过2M(hbase.client.write.buffer决定)或用户执行了hbase.flushcommits()时才向regionserver提交请求。因此即使htable.put()执行返回成功,也并非说明请求真的成功了。假如还没有达到该缓存而client崩溃,该部分数据将由于未发送到regionserver而丢失。这对于零容忍的在线服务是不可接受的。

  b autoflush=true虽然会让写入速度下降2-3倍,但是对于很多在线应用来说这都是必须打开的,也正是hbase为什么让它默认值为true的原因。当该值为true时,每次请求都会发往regionserver,而regionserver接收到请求后***件事就是写hlog,因此对io的要求是非常高的,为了提高hbase的写入速度,应该尽可能高地提高io吞吐量,比如增加磁盘、使用raid卡、减少replication因子数等

3 从性能的角度谈table中family和qualifier的设置

  对于传统关系型数据库中的一张table,在业务转换到hbase上建模时,从性能的角度应该如何设置family和qualifier呢?

  最极端的,①每一列都设置成一个family,②一个表仅有一个family,所有列都是其中的一个qualifier,那么有什么区别呢?

  从读的方面考虑:

  family越多,那么获取每一个cell数据的优势越明显,因为io和网络都减少了。

  如果只有一个family,那么每一次读都会读取当前rowkey的所有数据,网络和io上会有一些损失。

  当然如果要获取的是固定的几列数据,那么把这几列写到一个family中比分别设置family要更好,因为只需一次请求就能拿回所有数据。

  从写的角度考虑:

  首先,内存方面来说,对于一个Region,会为每一个表的每一个Family分配一个Store,而每一个Store,都会分配一个MemStore,所以更多的family会消耗更多的内存。

  其次,从flush和compaction方面说,目前版本的hbase,在flush和compaction都是以region为单位的,也就是说当一个family达到flush条件时,该region的所有family所属的memstore都会flush一次,即使memstore中只有很少的数据也会触发flush而生成小文件。这样就增加了compaction发生的机率,而compaction也是以region为单位的,这样就很容易发生compaction风暴从而降低系统的整体吞吐量。

  第三,从split方面考虑,由于hfile是以family为单位的,因此对于多个family来说,数据被分散到了更多的hfile中,减小了split发生的机率。这是把双刃剑。更少的split会导致该region的体积比较大,由于balance是以region的数目而不是大小为单位来进行的,因此可能会导致balance失效。而从好的方面来说,更少的split会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工的split和balance来避免掉。

因此对于写比较多的系统,如果是离线应该,我们尽量只用一个family好了,但如果是在线应用,那还是应该根据应用的情况合理地分配family。

4 hbase.regionserver.handler.count

RegionServer端开启的RPC监听器实例个数,也即RegionServer能够处理的IO请求线程数。默认是10.

此参数与内存息息相关。该值设置的时候,以监控内存为主要参考。

对于 单次请求内存消耗较高的Big PUT场景(大容量单次PUT或设置了较大cache的scan,均属于Big PUT)或ReigonServer的内存比较紧张的场景,可以设置的相对较小。

对于 单次请求内存消耗低,TPS(TransactionPerSecond,每秒事务处理量)要求非常高的场景,可以设置的相对大些。

原文链接:http://www.cnblogs.com/zhenjing/archive/2012/11/13/hbase_is_OK.html

【编辑推荐】

  1. HBase设计:看上去很美
  2. HBase在Linux下安装和配置详解
  3. eBay利用大数据促进在线交易
  4. 大数据提速:Impala能否取代Hive
  5. IDC分析师关于中国大数据市场的十大预测

©本文为清一色官方代发,观点仅代表作者本人,与清一色无关。清一色对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议,请读者仅作参考,并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络,如侵犯到著作权人的权利,请与我们联系(微信/QQ:1074760229)。转载请注明出处:清一色财经

(0)
打赏 微信扫码打赏 微信扫码打赏 支付宝扫码打赏 支付宝扫码打赏
清一色的头像清一色管理团队
上一篇 2023年5月7日 01:27
下一篇 2023年5月7日 01:27

相关推荐

发表评论

登录后才能评论

联系我们

在线咨询:1643011589-QQbutton

手机:13798586780

QQ/微信:1074760229

QQ群:551893940

工作时间:工作日9:00-18:00,节假日休息

关注微信