我正在阅读关于高瘦与短宽hbase模式设计的文章，作者提出了以下我不理解的理由：
最好考虑高瘦设计，因为我们知道它将有助于更快的数据检索，使我们能够一次读取用户博客条目的单列族，而不是遍历许多行。另外，由于hbase拆分是在行上进行的，因此可以在一个区域服务器上找到与特定用户相关的数据。
他们提议的博客网站模式的短宽设计如下（每个作者有一行，每个新的博客条目都是一个新的列）：
+----------+-------------+------+-----+---------+-------+
| | BECF (Blog entry Column family)
+----------+-------------+------+-----+---------+-------+
| RowKey (UserID) | BECF:BT | BECF:BT | BECF:BT | BECF:BT |
+----------+-------------+------+-----+---------+-------+
| WriterA | Entry1 | Entry2 | Entry3
| WriterB | EntryA | EntryB | ...
+----------+-------------+------+-----+---------+-------+他们提出的高瘦设计如下（每一个新的博客条目都是一个新行）：
+----------+-------------+------+-----+---------+-------+
| | BECF (Blog entry Column family)
+----------+-------------+------+-----+---------+-------+
| RowKey (UserID+TimeStamp) | BlogEntriesCF:Entries
+----------+-------------+------+-----+---------+-------+
| WriterATimeStamp1 | Entry1
| WriterATimeStamp2 | Entry2
| WriterATimeStamp3 | Entry3
| WriterBTimeStamp1 | EntryA
| WriterBTimeStamp2 | EntryB
+----------+-------------+------+-----+---------+-------+为什么作者认为高瘦设计更好，因为“允许一次读取用户博客条目的单栏族，而不是遍历多行”？
短宽的设计不允许只读取一行来获取所有条目吗？因此，一个更好的设计？
5条答案
按热度按时间7eumitmz1#
你的话来自《学习hbase》一书。引用不准确，但这是个好消息：）
看看作者是怎么形容高瘦的
在一个高而薄的table设计中，table向下生长的速度比向右手边生长的速度快。[…]
rowkey（userid+timestamp）|博客entriescf:entries
bq9c1y662#
好吧，首先要绕过的是行锁定。
假设你有一个大行，你需要更新它。这意味着必须锁定此行。因为它被锁定了，所以没有其他作者可以在那一刻更新它。他们必须等到锁松开。
对于“高”和“薄”，数据包含在短行中的一个字段中，这样更新数据不会给其他希望更新其内容（位于单独一行）的编写者带来问题。
高瘦也有助于建立动态关系，扩展用户群，更快的索引，更好的响应时间。
人类可读性不强，但对于机器来说，更容易处理、连接、修改和改变结构。
如果您有一个对象关系Map接口（比如javahibernate、php eloquent等等），那么将其转换为一个或多个关系并更新、修改、轮询整个对象就变得非常容易了。
“高”和“薄”还允许在其他地方轻松实现相同的数据对象，而不需要视图来清理/删除垃圾数据。
例如：
我有一个产品a，产品b，产品c的价格数据库的价格有日期，他们是有效的季节（圣诞节等…）。我示例中的所有产品都受同一季节的约束
宽：
现在，如果您想添加一个额外的产品，您必须执行以下操作：
修改表。这可能是非常昂贵的一个大表上做，造成停机
更新价格会导致很多行锁定
修改查询。到处都在使用查询。他们都必须考虑额外的列，特别是如果
select *已使用。修改实现代码。有一个额外的列，松散的循环可能会中断。需要修改数组迭代器以考虑额外的产品。
如果软件基础有点老化，那么在更改后很长一段时间内东西都会损坏。
更新对表名的硬编码引用
高：
现在，如果您想添加一个额外的产品，您必须执行以下操作：
将产品添加到表产品
在perioddate>now（）的价格表中添加条目
因为它都是关系型的，所以代码已经将它视为关系型的，并将它作为关系型的来读取，只需将它添加到现有的代码流中即可。
pcrecxhr3#
窄数据或堆叠数据显示为一列包含所有值，另一列列出值的上下文。这通常更容易实现，添加新字段不需要对表的结构进行任何更改，但是人们可能更难理解。”
来自“宽窄数据”，维基百科https://en.wikipedia.org/wiki/wide_and_narrow_data [访问时间：2016年12月29日]
我假设这意味着如果你想得到一个纯粹的值列表，而不关心它们的上下文，你只需要读取一列。如果您想在短范围的数据结构中实现这一点，就必须找到行并到达所需的列，并且对每一行都是这样，而不是一次读取。
当做，
xesrikrc4#
iezvtpos5#
写入时间戳1 | hbaseentry公司
写入时间戳2 | Hadoop入口
写入时间戳3 | Hadoop入口
... | ...
请注意，行键顺序不对，这与解释混淆的示例不同。这个例子解释了writera
遍历多行。
然而hbase不是这样工作的，它实际上是在写入密钥之前对密钥进行排序（从技术上讲，突变不会被排序到wal中，但是如果一切正常，wal就不会被使用，如果被使用，突变会被重放到保存区域数据的memstore中）。
由于hbase拆分是在行上进行的，因此可以在一个区域服务器上找到与特定用户相关的数据。
这一部分似乎在逻辑上与短宽有关。。。
所以总而言之，我认为这本书的这一部分可能需要复习一下。请参阅mapr的这篇优秀的博客文章，快速了解hbase的概况。