博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
HBase中数据的多版本特性潜在的意外
阅读量:7211 次
发布时间:2019-06-29

本文共 1221 字,大约阅读时间需要 4 分钟。

2011
-
11
-
08

 

博客分类: 
HBase做为KeyValue结构存储,在存储上是依照RowKey的字典序进行排序,对于很多应用而言这可能远远不够,好在HBase的数据可以存储多个版本,并且版本可以排序,其理论上最大的版本数目Integer.MAX_VALUE,这在一定程度上简化应用端的设计 
举个例子,假设现在有一个应用,对用户的每次登录信息(如:时间+IP)进行,并要求可以快速获取指定用户的最近登录信息,如果选用HBase存储则可以设计为:RowKey为用户ID,value为IP地址,并指定timestamp为登录时间,依照版本的保留特性,可以很容易地保存用户近一月、近一年的登录信息。 
看起来上面的设计很不错,毕竟用户啥都不需要操作,HBASE可以很容易为你保留近一段时间内的数据 
但是,如果一知半解,很可能会发生一些你意料之外的现象 
1.先后插入两条数据,他们拥有相同的RowKey,列,以及timestamp,不同的value 
实际结果:只能获取到第2次插入的数据,而不是两个版本 
2.先插入一条数据,版本为t1,然后删除版本t1,再插入一条数据,版本仍为t1 
实际结果:读取版本为t1的数据时为空 
3.先删除版本小于t1的数据,再插入一条数据,版本为t2,并且t2<t1 
实际结果:读取版本为t2的数据时为空 
出现这样现象的原因可由KeyValue的大小计较 和 HBase的插入删除逻辑解释 
a.KeyValue的大小比较规则,优先级从大到小依次为RowKey cf+cq timestamp type, 
具体点比如说,在比较2个KeyValue时,先比较RowKey的大小('a' < 'b'),相同的情况下比较cf+cq的大小('cf1:q1'<'cf2:q1'<'cf2:q2'),如果还是相同的话就比较时间戳(3042211081<3042211080,注意 我没写错,你没看错,时间戳的long值越大,表示数据越新,在从小到大的队列中越靠前),如果上述仍然还相同则比较TYPE('DeleteFamily' < 'DeleteColumn' < 'Delete' < Put) 
b.HBase的插入和删除都是是向HBase提交一条KeyValue,而真正的物理删除发生在compact时,所以,在客户端,虽然相同的版本插入和删除有先后顺序,但是在服务端上,这是不可见的,相同的版本号,delete类型的KV永远都排在put前,而读到delete的kv后,就直接返回了 
如果要避免23现象出现,则需要在插入前做compact操作,这样才能得到想要的结果 
4.HBase设计为版本数最多为Integer.MAX_VALUE,但是如果你真插入了接近该数的版本后,那可能有很大的风险在等着你 
首先,compact时很有可能就out of memory 
其次,单个rowkey的region再大也是不会split的

转载地址:http://ghrum.baihongyu.com/

你可能感兴趣的文章
蓝云公布2019云生态战略,如何解决企业上云关键问题?
查看>>
FaaS、PaaS和无服务器体系结构的优势
查看>>
Ceylon语言加入Eclipse基金会
查看>>
一文盘点MWC 2019所有5G设备和研发进展
查看>>
【leetcode】85. Maximal Rectangle 0/1矩阵的最大全1子矩阵
查看>>
网站真分页js代码该怎么写?
查看>>
教你五分钟入门使用html5 svg绘制图形
查看>>
vue-concise-slider vue滑动组件
查看>>
ElectronOCR:基于Electron+React+Tesseract的MACOS下的OCR工具
查看>>
Mysql 架构及优化之-定时计划任务
查看>>
不插即用!配备微信网页授权模块的CodeIgniter应用脚手架
查看>>
HBase存储剖析与数据迁移
查看>>
人工智能高考511分,未来有望考上东京大学!
查看>>
O2O业务都跳不出这五大领域
查看>>
呼之欲出的量子计算机和漫长的最后一公里
查看>>
“九”答不可 | 量子保密,完美无缺?
查看>>
VMware备份研究
查看>>
dotnet调用node.js写的socket服务(websocket/socket/socket.io)
查看>>
Nibiru Open Day,OZO 遇见 DigiArtist 国际数字艺术展
查看>>
MySQL · 引擎分析 · InnoDB行锁分析
查看>>