【问题标题】:Does delete masks put in Bigtable?删除掩码是否放入 Bigtable?
【发布时间】:2017-08-08 09:50:37
【问题描述】:

在 Hbase 文档 (http://hbase.apache.org/0.94/book/versions.html) 中,它说:

"5.8.2.1. 删除掩码放置

删除掩码放置,甚至在输入删除后发生的放置[18]。请记住,删除会写入一个墓碑,只有在下一次主要压缩运行后才会消失。假设您对所有 "

但是,在我们使用 Bigtable Hbase 1.0 API 的实验中,delete 不会屏蔽 put。我们能否确认这是 Bigtable 中的预期行为?

我们所做的是按顺序执行以下操作:

put data into column x with timestamp 10
put data into column x with timestamp 12
delete column x with timestamp 22
put data into column x with timestamp 17
put data into column x with timestamp 67

然后,当我们得到第 x 列时,我们希望只看到时间戳为 67 的单元格,但我们看到了两个时间戳为 17 和 67 的单元格。

在我们的应用程序中,我们更喜欢放置删除掩码。

谢谢!

【问题讨论】:

    标签: google-cloud-bigtable


    【解决方案1】:

    贾斯汀,

    如果 puts 在删除后发出,Bigtable 不会在删除后屏蔽 puts。屏蔽 puts 的问题在于,puts 会在主要压缩后的一段时间后出现,这对用户来说是一个惊喜,一个意想不到的结果。 您能否稍微描述一下您的用例,以便我们更好地帮助您克服这种不适合您的行为?

    谢谢!

    【讨论】:

    • 这应该作为评论发布,因为它没有完全解决问题。
    • “如果在删除后发出 puts,Bigtable 不会在删除后屏蔽 puts”就是答案。
    • 嗨@kevin-si,感谢您的回答!我明白了,如果压实后出现蒙面放置,那肯定不好。只是好奇,为什么压缩不会删除蒙面放置?
    • 我们的用例非常简单。基本上,对于每一列,我们都有一个传入的 put 和 delete 流,每个流都有一个时间戳,它们可能会乱序到达。我们希望具有较新时间戳的操作始终覆盖具有较旧时间戳的操作。例如,如果一个带有时间戳 10 的删除首先到达,那么稍后一个带有时间戳 5 的 put 应该被简单地忽略。因此,如果 deletes 掩码 puts 和 puts 没有通过压缩恢复,那么它对我们来说是完美的。如果删除不屏蔽放置,那么我们正在考虑放置一个用于删除的虚拟数据,以便它在获取期间屏蔽放置(续)
    • (续)您认为可能有更好的方法来处理这个问题吗?非常感谢!
    猜你喜欢
    • 2021-09-28
    • 1970-01-01
    • 1970-01-01
    • 2016-10-21
    • 1970-01-01
    • 1970-01-01
    • 2019-10-23
    • 2011-12-12
    • 1970-01-01
    相关资源
    最近更新 更多