gpt4 book ai didi

36、HBase案例:“高宽中”架构设计Smackdown

转载 作者:大佬之路 更新时间:2024-01-07 13:06:51 26 4
gpt4 key购买 nike

HBase模式案例:“高/宽/中” 架构设计 Smackdown

本节将介绍出现在远程列表中的其他模式设计问题,特别是关于高和宽表。这些是一般准则而不是法律 – 每个应用程序都必须考虑到自己的需求。

HBase行与版本

一个常见的问题是应该更喜欢行还是 HBase 的内置版本。上下文通常是保留行的“多个”版本的地方(例如,它明显高于1个最大版本的HBase默认值)。rows-approach 需要在 rowkey 的某些部分存储一个时间戳,以便在每次连续更新时不会覆盖它们。

首选项:行(一般来说)。

HBase行与列

另一个常见问题是,是否应该更喜欢行还是列。上下文通常在宽表格的极端情况下,例如具有1行100万个属性,或每100万行1列。

首选项:行(一般来说)。需要说明的是,本指南在上下文中是非常宽泛的情况,而不是标准的用例,其中需要存储几十或者一百列。但是这两个选项之间也有一条中间路径,那就是“行作为列”。

HBase行作为列

HBase行与列之间的中间路径将打包数据,对于某些行,这些数据将成为单独的行。在这种情况下,OpenTSDB就是最好的例子,其中一行表示一个定义的时间范围,然后将离散事件视为列。这种方法通常更加复杂,并且可能需要重写数据的额外复杂性,但具有 I/O高效的优点。

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com