本文将介绍出现在远程列表中的其他模式设计问题，特别是关于高和宽表。这些是一般准则而不是法律 - 每个应用程序都必须考虑到自己的需求。
HBase行与版本
一个常见的问题是应该更喜欢行还是 HBase 的内置版本。上下文通常是保留行的“多个”版本的地方（例如，它明显高于1个最大版本的HBase默认值）。rows-approach 需要在 rowkey 的某些部分存储一个时间戳，以便在每次连续更新时不会覆盖它们。
首选项：行（一般来说）。
HBase行与列
另一个常见问题是，是否应该更喜欢行还是列。上下文通常在宽表格的极端情况下，例如具有1行100万个属性，或每100万行1列。
首选项：行（一般来说）。需要说明的是，本指南在上下文中是非常宽泛的情况，而不是标准的用例，其中需要存储几十或者一百列。但是这两个选项之间也有一条中间路径，那就是“行作为列”。
HBase行作为列
HBase行与列之间的中间路径将打包数据，对于某些行，这些数据将成为单独的行。在这种情况下，OpenTSDB就是最好的例子，其中一行表示一个定义的时间范围，然后将离散事件视为列。这种方法通常更加复杂，并且可能需要重写数据的额外复杂性，但具有 I/O高效的优点。
HBase模式案例高_宽_中 Architecture 设计Smackdown
原文：https://blog.51cto.com/14744108/2486402