【问题标题】:Hbase: Having just the first version of each cellHbase:只有每个单元的第一个版本
【发布时间】:2015-06-06 10:11:51
【问题描述】:

我想知道如何配置 Hbase 以仅存储每个单元的第一个版本?假设如下Htable:

row_key          cf1:c1           timestamp
----------------------------------------
1                  x                 t1

("1","cf1:c2",t2)放入ColumnDescriptor.DEFAULT_VERSIONS = 2的场景后,提到的Htable变成:

row_key          cf1:c1           timestamp
----------------------------------------
1                  x                 t1
1                  x                 t2

t2>t1.

我的问题是如何改变这种情况,使第一个版本的单元格成为唯一可以存储和检索的版本。我的意思是在提供的示例中,唯一的版本是't1' 一个!因此,我想以一种忽略重复插入的方式更改 hbase。

我知道将 Htable 的 VERSIONS 设置为 1 并基于 Long.MAX_VALUE - System.currentTimeMillis() 放置可以解决我的问题,但我不知道这是不是最好的解决方案?!将 tstamp 更改为Long.MAX_VALUE - System.currentTimeMillis() 有什么问题?它有任何性能问题吗?

【问题讨论】:

  • 你能澄清你的问题吗?只有每个单元的第一个版本意味着不再有任何其他版本,这意味着所有后续写入都将被忽略,而忽略重复则完全不同。
  • @mrhobo 其实我只想拥有每个单元格的第一个版本而忽略其他的。
  • 所以你想在第一次写入单元格后阻止所有写入?
  • @mrhobo 是的,没错。

标签: hadoop hbase


【解决方案1】:

我能想到两种策略:

1。一个版本+倒置时间戳

将 Htable 的 VERSIONS 设置为 1 并基于 Long.MAX_VALUE - System.currentTimeMillis() 放置通常会起作用,并且不会出现任何重大性能问题。

写入时:

  • 当同一单元的多个版本写入 hbase 时,在任何时间点都会写入所有版本(对性能没有任何影响)。压缩后,只有时间戳最高的单元才能存活。
  • 此方案中时间戳最高的单元格是客户端写入的System.currentTimeMillis() 值最低的单元格。应该注意的是,这实际上可能不是首先尝试写入单元的机器,因为 hbase 客户端可能不同步。

阅读中:

  • 当发现同一单元的多个版本时,将进行修剪。这可能随时发生,因为您的写入可能随时发生,即使在压缩之后也是如此。这对性能的影响非常小。

2。 checkAndPut

要通过原子性获得真正的排序,即只有第一次写入到达区域服务器才会成功,您可以使用checkAndPut操作:

来自docs

public boolean checkAndPut(byte[] row, byte[] family, byte[] qualifier, byte[] value, Put put) throws IOException

自动检查行/族/限定符值是否与预期匹配 价值。如果是这样,它会添加看跌期权。如果传递的值为空,则 检查是否缺少列(即:不存在)`

因此,通过将value 设置为null,您的Put 只有在单元格不存在时才会成功。如果您的 Put 成功,则返回值为 true。这提供了真正的原子性,但以写入性能为代价。

写入时:

  • 在检查存在之前,已设置行锁并在内部发出Get。一旦确认不存在,就会发出看跌期权。正如您可以想象的那样,这对每次写入都会产生相当大的性能影响,因为现在每次写入还涉及读取和锁定。
  • 在压缩期间不需要发生任何事情,因为只有一个 Put 可以将其发送到 hbase。这始终是第一个到达区域服务器的 Put。
  • 需要注意的是,没有办法通过使用checkAndMutate 批量处理这些checkAndPut 操作,因为每个Put 都需要自己的检查。这意味着每个 put 都需要是一个单独的请求,这意味着您在批量写入时也需要支付延迟成本。

阅读中:

  • 只有一个版本可以支持 Hbase,因此这里没有影响。

在策略之间进行选择:

如果真正的顺序真的很重要,或者您可能需要在写入 hbase 之后或之前读取每一行(例如,确定您的写入是否成功),您最好使用策略 2,否则,在在所有其他情况下,我推荐策略 1,因为它的写入性能要好得多。在这种情况下,只需确保您的客户端时间正确同步。

【讨论】:

  • 由于写入吞吐量对我来说更重要,所以您的第一个解决方案会更好。但是,您的第二个解决方案非常有趣,值得一试。顺便说一句,我对第一个解决方案感到困惑。基本上当 Htable 的 VERSIONS 设置为 1 时会发生什么?我认为在这种情况下,只会存储一个版本,并且一旦新版本到来,旧版本就会被删除!但是根据您的回复,无论 VERSIONS 的值是多少,Hbase 似乎都会存储所有版本。你能帮我解释一下吗?
  • 是的,Hbase 在压缩之前永远不会真正丢弃数据,因此如果在压缩发生之前存在多个版本并且 VERSIONS 设置为一个,那么在读取时时间戳最低的版本将被忽略。甚至删除也只是压缩发生之前的墓碑标记。您可以在此处阅读有关 HBase 工作原理的更多信息:ngdata.com/visualizing-hbase-flushes-and-compactions
【解决方案2】:

您可以插入PutLong.MAX_VALUE - timestamp,并将表配置为仅存储1 个版本(最大版本=> 1)。这样,Scan 只会返回第一个(最早的)Put,因为所有后续 Put 的时间戳值都较小。

【讨论】:

  • 正如我之前提到的,您知道更好的方法吗?我在某处读到不建议更改默认的 Hbase 时间戳。
  • 我们使用内置的时间戳将 ts 存储在 0.94 版本中,我们没有发现任何问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-22
  • 1970-01-01
  • 2013-05-11
  • 1970-01-01
  • 1970-01-01
  • 2020-05-08
相关资源
最近更新 更多