HBase多版本语义与delete语义的历史遗留问题

作者: yangzhe1991 分类: 我是搞技术的 发布时间: 2016-06-23 13:51 ė 6没有评论

本文是公司的命题作文,应该会发布在我们组的技术博客中。

HBase是一个采用LSM结构的、支持多版本的数据库。与一些数据库解决并发读写问题的mvcc不同(当然HBase也有mvcc),这里的多版本是指在语义层面支持向同一个rowkey+column family+column qualifier中写入多个timestamp不同的value,是暴露给用户的语义层面的多版本,这也是遵循了BigTable的设计。不过HBase的timestamp不仅可以由服务器根据写入时的时间戳生成,也可以由用户指定,因此会额外多一些需要考虑的问题,一些问题至今仍没有很好的解决,本文将描述这些问题,供对HBase感兴趣的人参考,并将在不久的将来在社区的新版中修复这些问题。

时间戳是目前HBase中作为判断同一列数据“版本”新旧的唯一标准,读取数据的时候可以指定读取多少个版本,会返回从新到旧的X个最新版本数据给客户端。同时在建表的配置中每个CF可以配置保留多少个版本的数据,超过这个配置后会在compaction时清理掉最旧的若干个版本。因此,如果一个用户按先后顺序分别对同一列写了时间戳为5、4、3、2、1的五个Put,同时保留最新的3个版本,那么读到的会是5、4、3,哪怕这三个其实是最先写入的。

 

同时因为HBase是一个LSM结构的数据库,在这种结构中,会把删除操作转化为一个特殊的写入,叫delete marker或tombstone,因此Delete和Put在写入时的性能是完全一样的。而在读取时,如果读到了某个type为Delete的数据,就会根据这个Delete对象设置的语义来屏蔽掉对应的Put,以保证客户端看不到被删掉的数据。也就是说刚执行完删除操作后,数据占用空间不仅不会变小,反而会变大。只有在执行Minor Compaction时,才会清掉所读取的HFile中被Delete删除掉的Put,释放空间;在执行Major Compaction时,才会确保删除掉所有被删除的Put,并删除Delete。

 

目前HBase的Delete支持的语义比较多(JavaDoc见此):不考虑多版本问题的话,可以说HBase支持删掉某行、或某个cf的所有列(cq)、或某列(cf+cq)的数据;如果考虑多版本,则只能说HBase支持删除行/cf/列下的某个特定时间戳的版本,或时间戳小于等于这个值的所有版本。即使用户没有设置时间戳,系统也会用一个隐含的当前时间戳来作为这个Delete的时间戳,并按照“时间戳小于等于这个值的所有版本”来执行。Put单纯考虑时间戳而不考虑写入顺序,可以比较方便的补一个旧版的数据。但是如果Delete也只考虑时间戳不考虑操作的顺序,就会带来一些比较违反直觉的问题:

 

1,如果写了一个比较大的时间戳的Put,大于当前时间,再想通过文档中描述的“Delete all versions of ”的功能来删,那么这个Put是删不掉的。所谓的删除所有版本,隐含着的语义是删除时间戳小于等于当前时间的所有版本,因为如果client没有指定一个update操作的时间戳的话,会用系统当前时间戳。

2,如果为了删掉第一条里的Put,手动指定了一个比较大时间戳的Delete去删,那么就意味着以后再写入数据如果用默认的系统时间作为时间戳,就读不到了,因为这些数据的时间戳都小于那个Delete的时间戳从而被屏蔽掉。但是一旦后台执行了Major Compaction,把Delete清理掉,再用当前时间作为时间戳写数据,就能读到了。而Major Compaction对用户是透明的,对用户来说意味着行为不一致。

3,如果先后写入了时间戳为1、2、3三个版本的数据,同时表的设置为保留最新的两个版本,则会读到3、2,读不到1。如果在写完3之后,通过删除指定版本的接口删掉2这个数据,那么能读到3和1,因为这两个是目前的最大版本。但是如果在删除之前执行了一次Major Compaction,时间戳为1的Put会被清理,(因为有2和3两个比他新的版本),这个时候如果再删2,那么就只能读到3了。也是Major Compaction对用户不透明。

4,如果在同一毫秒内对一个列进行操作,多版本会无效(因为多版本只跟时间戳有关,并且时间戳精度是毫秒),并且Delete会覆盖Put(可以理解为这是人为定义的顺序),哪怕实际上是前半毫秒先Delete后半毫秒再Put,也会导致读不到数据。这个问题虽然可以靠提高时间戳的精度解决,比如用纳秒,但是并不解决本质问题。

 

上述4个问题导致HBase的删除和多版本的语义比较奇怪,目前或者说HBase诞生以来之所以这样做,一个是逻辑简单、性能比较好,一个是可以保证HBase所有的操作对于相同的row+cf+cq+ts的操作是幂等的,若干个操作互换顺序、反复重复操作,最终的状态是一致的。但是由于后台的compaction的存在,这个一致性是打了折扣的;并且不依赖操作的先后顺序之后很多事情会违反用户的直觉。因此最近我们也在讨论着手去修改这个问题。

 

在语义上,我们希望HBase能实现删除语义的“顺序一致性”,即删除与写入操作的顺序也会影响读取的结果,更符合用户的直观感受。而Put的操作依然通过时间戳来定义新旧,与之前保持一致。先进行的删除操作无论其时间戳设为多少,都不会影响后续的Put操作,如果Delete删除的时间戳为MaxLong,则相当于暂时清空所有版本,后续仍旧可以写入,而非相当于永久屏蔽所有版本导致这个行或cf无法写入任何数据。实现该语义后,额外带来的好处是当用户想“删除这列的最新的版本”时,不需要先读这个列获取最新时间戳再写入这个时间戳的Delete,而是直接写入一个特殊的delete marker,根据其写入的顺序来决定他屏蔽的版本,以提高删除时的性能。

 

同时,对于多版本的写入,无论Major Compaction是否发生,一旦当前列有超过MaxVersions个版本之后,旧的数据都应该被立刻“逻辑删除”,永远不可见,而非像目前一样一旦删了某个新版本,那些之前被新版冲掉的数据如果没有被compaction清理掉就又可见了。

 

当然,修改这两个语义之后,也意味着在读取的时候不能直接按时间戳排序,也要根据mvcc来判断操作的先后顺序,通过更复杂的逻辑来保证这两个语义,因此性能可能会有所影响。所以这个语义会是可配置、默认关闭的,以实现语义和性能上的兼容。我们会在完善细节上的设计之后着手修改社区上的版本,与社区一同改善HBase的功能、让HBase更加强大。

本文出自 杨肉的演讲台,转载时请注明出处及相应链接。

本文永久链接: https://yangzhe1991.org/blog/2016/06/hbase-versions-delete-limitations/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Ɣ回顶部