HBase：行键组合

为了简单起见，我们可以说我有一个表，其中主键逻辑上应该是一个很长的表。
目前，我从一个项目中继承了（使用关系数据库），我有一个IDMaker类，它返回一个我在（在该项目中）作为主键的长整型。HBase：行键组合

我说可能，因为据我了解，因为这个ID是基于时间戳和单调递增的，它不是一个HBase的行键一个很好的候选人。

现在，读

http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/ http://hbase.apache.org/book/rowkey.design.html
和“HBase的权威指南”的第9章由拉尔斯乔治，

我看到“盐析”优势战略可能适合我的需要。这基本上为我的钥匙添加了一个前缀，因此打破了单调系列。
现在的问题是：使用策略这样的，从这个IDS开始：

假设这些关键到一个域服务器，并且改造那些ID，如此（前缀是当然的一例）

0:1
7:2
9：3
一：4

我怎么能肯定的是，四大行不会还是去同一区域的服务器？换句话说，我怎么能确定我的前缀足以避免在这里很好地描述http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/？

来源

2012-11-01 Andrea

我怎样才能确定这四行不会仍然去同一地区服务器？换句话说，我怎么能相信，我的前缀，就足以避免这里什么很好的描述

你有没有在节2.5.2.7读取。已经在Important Configurations管理拆分了吗？

来源

2012-11-03 07:45:27

感谢您的提示。我刚刚阅读了该部分，但是，虽然更清楚，但我的问题仍然存在......您是否阅读过上面的BigTable文章？我想了解A-L和M-Z的界限来自 – Andrea

是的，我知道Ikai的职位。现在，你说'边界来自哪里'是什么意思？从*你* :) –

啊，还有一件事。我想知道你是否真的仔细阅读这篇文章，因为Ikai在途中给你的最重要的提示是最后的结果：'不要过早地优化这个案例，因为有机会，你不会碰到它“。 - 说了这个，你是100％肯定你有这种情况吗？ –

我怎样才能确定这四行将不会仍然去相同的区域服务器？

你应该根据你的哈希模式预分割你的表。

例如，如果将使用0-1-2-3-4-5-6-7-8-9-A-B-C-d-E-F以进行盐析。您可以为该hbase表创建16个分割。每个分割应该有0作为开始 - 1作为结束行，1作为开始 - 2作为结束行..像这样。您可以从hbase shell或java代码中执行此操作。我更喜欢java，因为我可以使用for循环创建许多分割:)

至于过早优化，分割过多会影响性能。

来源

2015-05-27 06:32:31 halil

HBase：行键组合

回答

相关问题