暂无个人介绍
GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。 过去的一年里,我们准备在Ali-HBase上突破这个被普遍认知的痛点,为此进行了深度分析及全面创新的工作,获得了一些比较好的效果。
2015年11月11日,作为媒体大屏(dataV)、消费记录、支付宝风控、物流详情、库存对账核心数据库的集团HBase,当天稳定运行,顺利完成了任务。并交出了非常漂亮的几项数据:<strong>QPS=1993W,TPS=3656W,读流量=56GBps,写流量=40.6GBps,全天吞吐读2.0PB,写1.28PB。<br /><br /></strong> 由于HBase团队的组织架构变动,
云HBase可以使用thrift进行访问 可以查看云HBase的官方帮助文档: 标准版: https://help.aliyun.com/document_detail/87068.html 增强版: https://help.aliyun.com/document_detail/119573.html
不建议有单行数据过大的宽表设计,原因是: 1. hbase split是以region为单位。单行数据过大会导致无法split 2. hbase 客户端-服务端传输协议不支持单行内的流式传输,当读取该热点row时,row size可能大于hbase的rpc传输包大小限制,导致数据读不出来。
建议修改方式: 将表设计从宽表改造成高表。将列名(qualifier)拼接到rowkey上,用多行替换单行
-------------------------
更新了一下规则