试图看出如何布置宽和瘦的行

Question

当您为宽行和瘦行设计表时，有人可以给出并告诉我数据是如何布局的。

我不确定我是否完全掌握数据如何以“宽”行展开。

获取数据的方式是否存在差异，或者它是否相同，即如果订购数据，则数据是垂直（瘦）还是水平（宽）组织无关紧要。

更新的 如果主键包含多个列，是否考虑表？ 或者，只有当分区键是复合分区键时，表才会有宽行？

Answer 1

宽...瘦...让你的头爆炸的术语......我更喜欢过度简化这样的事情：

1. 所有表格都有宽行
2. 您只需要处理如何广泛的行

这允许我将其视为以下（稍微修改一下C *术语）：

        Number of RECORDS in a partition
1 <--------------------------------------- ... 2Billion
      ^                         ^
  Skinny rows                  wide rows

分区中较小的记录，skinner是“分区”，反之亦然。

在为C *设计时，我始终牢记以下几点：

• 当我的数据可以通过一个查询获取并且它完全包含在一个分区的一个记录中时，我想使用“瘦分区”。典型示例是SELECT * FROM table WHERE username = 'xmas79';的内容，其中表格具有PRIMARY KEY (username)形式的主键，可让我获取属于特定username的所有数据。
• 当我的数据可以通过一个查询获取并且它完全包含在一个分区的多个记录中时，我想使用“宽行”。典型示例是范围查询，例如SELECT * FROM table WHERE sensor = 'pressure' AND time >= '2016-09-22';，其中表格具有PRIMARY KEY (sensor, time)形式的主键。

因此，第一种方法是一次性查询，第二种方法是范围查询。请注意，第二种方法存在（主要）缺点，即您可以继续向分区添加数据，并且将越来越宽，从而损害性能。

为了控制分区的宽度，您需要向分区键添加内容。在上面的传感器示例中，如果您当然没有违反您的要求，您可以按日期对某些测量值进行“分组”，例如，您可以按日期分组测量，制作主键与PRIMARY KEY ((sensor, day), time)类似，其中分区键已转换为(sensor, day)。通过这种方法，您可以完全控制分区的广泛性（好吧，至少说好）。

您只需要在查询功能和所需性能之间找到一个很好的折衷方案。

我建议这三个读数进一步调查细节：

1. Wide Rows in Cassandra CQL
2. Does CQL support dynamic columns / wide rows?
3. CQL3 for Cassandra experts

请注意1.在倒数第二张图片中出现错误：主键应该是

PRIMARY KEY ((user_id, tweet_id))

在列周围用双括号而不是一列。