Question

我正在阅读 Tall-Thin与Short-Wide HBase架构设计 ，作者提出了以下哪些推理我不理解：

最好考虑我们知道它将有助于的Tall-Thin设计通过使我们能够读取单列族来更快地检索数据一次用户博客条目，而不是遍历许多行。此外，由于HBase拆分发生在行上，因此数据与a相关可以在一个区域服务器上找到特定用户。

他们提出的博客网站架构的 Short-Wide design 如下（每个编写器有一行，每个新博客条目都是新列）：

+----------+-------------+------+-----+---------+-------+
|                    |     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
+----------+-------------+------+-----+---------+-------+

为什么作者认为高瘦设计更好，因为“能够一次读取用户博客条目的单列族而不是遍历多行”？
Short-Wide设计不允许只读取一行来获取所有条目吗？因此，更好的设计？

Answer 1

嗯，你绕过的第一件事是行锁定。

假设你有一个很宽的行，你需要更新它。这意味着必须锁定此行。没有其他作家可以在那一刻更新它，因为它被锁定了。他们必须等到锁被释放。

对于高大瘦弱的数据，数据包含在一个短行中的一个字段中，更新它，不会给想要更新其事物的其他作者带来问题，这些作者处于单独的行中。

高瘦也有助于建立动态关系，扩展用户群，更快的索引，更快的响应时间。

人性可读并不是真的，但对于机器来说，它更容易处理，加入，修改和改变结构。

如果你有一个对象关系映射接口（比如Java Hibernate，php Eloquent等等），那么将它变成oneToMany或ManyToMany关系并更新，修改，轮询整个对象变得非常容易。

高又瘦还允许在其他地方轻松实现相同的数据对象，而无需视图来清理/删除垃圾数据。

例如：

我有一个产品A，产品B，产品C的价格数据库价格的日期与季节（圣诞节等）相对应。我的例子中的所有产品都受同一季节的支配

宽：

  date_from | date_to    | ProductA_price | ProductB_price | ProductC_price
  22-10-2000| 22-11-2000 | 100            | 110            | 90
  23-11-2000| 26-12-2000 | 200            | 210            | 190
  27-12-2000| 22-01-2001 | 100            | 110            | 90

现在，如果您想添加额外的产品，您必须执行以下操作：

修改表格。这对于大型桌子来说非常昂贵，导致停电
更新价格导致大量行锁
修改查询。查询全部使用。他们都必须考虑额外的列，尤其是在使用select *时。
修改实施代码。有一个额外的列，松散的循环可能会破坏。需要修改数组迭代器以考虑额外的产品。
如果软件库有点老化，则更改后的东西会中断很长时间。
更新对表名的硬编码引用

高大：

table: Products
id | product_name
1  | ProductA
2  | ProductB
3  | ProductC

table: Periods
id| name    | date_from | date_to
1 | autumn  | 22-10-2000| 22-11-2000
2 | xmas    | 23-11-2000| 26-12-2000
3 | newyear | 27-12-2000| 22-01-2001

table: Prices
product_id | period_id | price
1          | 1         | 100
2          | 1         | 110
3          | 1         | 90
1          | 2         | 200
2          | 2         | 210
3          | 2         | 190
1          | 1         | 100
2          | 1         | 110
3          | 1         | 90

现在，如果您想添加额外的产品，您必须执行以下操作：

将产品添加到表格产品
在期货合约的表格价格中添加条目＆gt;现在（）

因为它是关系型的，所以代码已经将它视为关系型，并且会将其读取为它，并将它添加到现有的代码流中。

Answer 2

您的引用来自书籍"learning hbase"。报价不准确，但这是个好消息：）

了解作者如何真正描述高瘦

在 Tall-Thin 表格设计中，表格比向右侧更快地向下增长。 [...]

RowKey（UserID + TimeStamp）| BlogEntriesCF：条目---------------------------------------- + ------ -------------------------
  作家的 A TimeStamp1 | HBaseEntry
  作家的乙 TimeStamp2 | HadoopEntry
  作家的 A TimeStamp3 | HadoopEntry
  ... | ......

请注意，行键无序，这与解释混淆的示例不同。此示例说明了对WritterA的示例需要

遍历很多行。

然而hbase不能像那样工作，它实际上在写入之前对键进行排序（技术上突变未分类到WAL中但是如果一切正常，则不使用WAL，如果使用它，则将突变重放到MemStore上持有地区数据）。

由于HBase拆分发生在行上，因此可以在一个区域服务器上找到与特定用户相关的数据。

该部分似乎与 Short-Wide ...
逻辑相关
总而言之，我认为本书的这一部分可能需要进行审核。请参阅MapR中的这个优秀blog post，以便快速了解Hbase。

Answer 3

＆＃34;窄带或堆叠数据显示一列包含所有值，另一列列出值的上下文。这通常更容易实现，添加新字段不需要对表的结构进行任何更改，但是人们可能更难理解。＆＃34;

来自＆＃34;广泛和狭窄的数据＆＃34;，维基百科https://en.wikipedia.org/wiki/Wide_and_narrow_data [访问29.12.16]

我认为这意味着如果你想获得纯值列表而不关心它们的上下文，你只需读取一列。如果您想在短宽数据结构中执行此操作，则必须找到行并到达所需的列，以及每行而不是单个读取。

此致

为什么作者在内部描述了Short-Wide的HBase Tall-Thin模式？

3 个答案: