HBase模式案例研究列表数据

感谢平台分享-http://bjbsair.com/2020-04-10/tech-info/53341.html

以下是用户 dist-list 中关于一个相当常见问题的的交流:如何处理 Apache HBase 中的每个用户列表数据。

问题:

我们正在研究如何在 HBase 中存储大量(每用户)列表数据,并且我们试图弄清楚哪种访问模式最有意义。一种选择是将大部分数据存储在一个密钥中,所以我们可以有如下的内容:

HBase模式案例研究列表数据

我们的另一个选择是完全使用如下内容:

HBase模式案例研究列表数据

每行将包含多个值。所以在一种情况下,读取前三十个值将是:

HBase模式案例研究列表数据

而在第二种情况下会是这样:

HBase模式案例研究列表数据

一般的使用模式是只读取这些列表的前30个值,并且很少的访问会深入到列表中。一些用户在这些列表中总共有30个值,并且一些用户将拥有数百万(即幂律分布)。

单值格式似乎会占用 HBase 上的更多空间,但会提供一些改进的检索/分页灵活性。是否有任何显着的性能优势能够通过获取和扫描的页面进行分页?

我最初的理解是,如果我们的分页大小未知(并且缓存设置恰当),那么执行扫描应该会更快,但如果我们始终需要相同的页面大小,则扫描速度应该更快。我听到不同的人告诉了我关于表现的相反事情。我假设页面大小会相对一致,所以对于大多数使用情况,我们可以保证我们只需要固定页面长度的情况下的一页数据。我还会假设我们将不经常更新,但可能会插入这些列表的中间(这意味着我们需要更新所有后续行)。

答案:

如果我理解正确,你最终试图以“user,valueid,value”的形式存储三元组,对吗?例如:

HBase模式案例研究列表数据

(但用户名是固定宽度,而 valueids 是固定宽度)。

而且,您的访问模式符合以下要求:“对于用户 X,列出接下来的30个值,以valueid Y开头”。是对的吗?这些值应该按 valueid 排序返回?

tl、dr 版本是,你可能应该为每个用户+值添加一行,除非你确定需要,否则不要自行构建复杂的行内分页方案。

您的两个选项反映了人们在设计 HBase 模式时常见的问题:我应该选择“高”还是“宽”?您的第一个模式是“高(tall)”:每行代表一个用户的一个值,因此每个用户的表中有很多行;行键是 user + valueid,并且会有(可能)单个列限定符,表示“值(value)”。如果您希望按行键来扫描排序顺序中的行, 这是很好的。你可以在任何用户 + valueid 开始扫描,阅读下一个30,并完成。你放弃的是能够在一个用户的所有行周围提供事务保证,但它听起来并不像你需要的那样。

第二个选项是“宽”:使用不同的限定符(其中限定符是valueid)将一堆值存储在一行中。简单的做法是将一个用户的所有值存储在一行中。我猜你跳到了“分页”版本,因为你认为在单行中存储数百万列会对性能造成影响,这可能是也可能不是真的; 只要你不想在单个请求中做太多事情,或者做一些事情,比如扫描并返回行中的所有单元格,它不应该从根本上变坏。客户端具有允许您获取特定的列的片段的方法。

请注意,这两种情况都不会从根本上占用更多的磁盘空间; 您只是将部分识别信息“移动”到左侧(在行键中,在选项一中)或向右(在选项2中的列限定符中)。在封面下,每个键/值仍然存储整个行键和列名称。

正如你注意到的那样,手动分页版本有很多复杂性,例如必须跟踪每个页面中有多少内容,如果插入新值,则重新洗牌等。这看起来要复杂得多。在极高的吞吐量下它可能有一些轻微的速度优势(或缺点!),而要真正知道这一点的唯一方法就是试用它。如果您没有时间来构建它并进行比较,我的建议是从最简单的选项开始(每个用户 + valueid)。开始简单并重复!

相关推荐