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

Question

我正在阅读关于Tall-Thin与Short-Wide HBase架构设计的内容,作者提出了以下哪些推理我不理解:

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

他们提出的博客网站架构的Short-Wide设计如下(每个作者有一行,每个新博客条目都是一个新列):

+----------+-------------+------+-----+---------+-------+
|                    |     BECF (Blog entry Column family)
+----------+-------------+------+-----+---------+-------+
| RowKey (UserID)    | BECF:BT | BECF:BT | BECF:BT | BECF:BT | 
+----------+-------------+------+-----+---------+-------+
| WriterA            | Entry1  | Entry2  | Entry3 
| WriterB            | EntryA  | EntryB  | ...
+----------+-------------+------+-----+---------+-------+

他们提出的Tall-Thin设计如下(每个新博客条目都是新行):

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

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

• 将产品添加到表产品中
• 在perioddate> now()的表格价格中添加条目

因为它是所有关系的,所以代码已经将它视为关系,并将其读取,并将其添加到现有的代码流中.

Answer 2

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

来自“宽数据和窄数据”，维基百科https://en.wikipedia.org/wiki/Wide_and_narrow_data [访问日期：2016 年 12 月 29 日]

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

问候，