宽行、分区、集群列/键和分区键的概念是否存在于 Cassandra 的查询语言级别？

Question

在 Cassandra 中，查询语言级别是否存在宽行、分区、集群列/键和分区键的概念？还是它们是查询语言的用户不知道的内部实现问题？

这是来自How to understand the concept of wide row and related concepts in Cassandra? 的示例。在查询语言的命令中，上述概念似乎不存在，但在钩子下，它们确实存在。

考虑使用a 作为分区键和b 作为集群列创建的表：

Create TABLE test (a text,b int, c text, PRIMARY KEY(a,b)) 
INSERT INTO test(a,b,c) VALUES('test',2,'test2')
INSERT INTO test(a,b,c) VALUES('test',1,'test1')
INSERT INTO test(a,b,c) VALUES('test-new',1,'test1')

如果您按此顺序运行上述查询，cassandra 会将数据存储在 以下顺序（只需检查列b的顺序）：

test -> [b:1,c=test1] [b:2,c=test2]
test-new -> [b:1,c=test1]

拿起带有b:1的单元格作为分区键test：

SELECT * from test where a='test' and b=1

谢谢。

Answer 1

当然——CQL 语法确实有分区键与集群键的概念。看看你提供的例子：

Create TABLE test (a text,b int, c text, PRIMARY KEY(a,b)) 

语法(a,b) 在CQL 中意味着a 是分区键，b 是集群键。另一个例子，如果你写((a,b,c),d,e,f)，这意味着a、b和c是分区键列，而d、e和f是集群键列。这是 CQL 语法。

这在实践中意味着什么，我想你知道。除其他外，您可以要求以某种已知的排序顺序获取属于单个分区的所有聚类行 - 但分区未排序，全表扫描以随机顺序返回它们。

“宽行”一词在 CQL 中并未用作术语，但正如我上面解释的那样，这个概念确实存在 - “宽行”（实际上，“宽分区”更准确）是当一个单个分区有很多集群行 - 即，同一个分区键有很多不同的集群键。在 Cassandra 中，宽行得到了很好的支持，达到了极限（从非常大的分区中读取可能会更慢，并且各种代码仍然以低效的方式处理它们）。像this 这样的一些文档建议Cassandra 分区的大小最好达到10MB。

Answer 2

CQL 架构

根据您的表架构如下：

Create TABLE test (a text,b int, c text, PRIMARY KEY(a,b)) 

分区键由“a”和“b”组成。我认为以下 stacoverflow 帖子将解决您关于分区键等可能是什么的所有问题：Difference between partition key, composite key and clustering key in Cassandra?

数据文件

分区和集群列等都存在于数据文件级别（因此在数据库中）。 Cassandras 存储引擎在内部理解这一点。使用您的示例，我创建了表，刷新了键空间并使用sstablemetadata检查了 sstable@

请注意，您必须以运行 Cassandra 的同一用户身份运行该工具（在我的情况下，它是 cassandra 用户：

$ sudo -u cassandra sstabledump /var/lib/cassandra/data/mc/test-bedc4ba012cf11ea93f72f6848f9d70d/md-1-big-Data.db

[
  {
    "partition" : {
      "key" : [ "test" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 37,
        "clustering" : [ 1 ],
        "liveness_info" : { "tstamp" : "2019-11-29T17:43:35.752796Z" },
        "cells" : [
          { "name" : "c", "value" : "test1" }
        ]
      },
      {
        "type" : "row",
        "position" : 37,
        "clustering" : [ 2 ],
        "liveness_info" : { "tstamp" : "2019-11-29T17:43:31.144961Z" },
        "cells" : [
          { "name" : "c", "value" : "test2" }
        ]
      }
    ]
  },
  {
    "partition" : {
      "key" : [ "test-new" ],
      "position" : 54
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 95,
        "clustering" : [ 1 ],
        "liveness_info" : { "tstamp" : "2019-11-29T17:43:41.438779Z" },
        "cells" : [
          { "name" : "c", "value" : "test1" }
        ]
      }
    ]
  }
]

我们可以清楚地看到键“test”有两个聚类行，分别是值“1”和“2”。

有关存储引擎的更多背景信息，请参阅：https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlManageOndisk.html

宽行

这与其说是您决定使用或实施的东西，不如说它是不良数据模型的副作用。一个很好的例子是想象你有一个这样的表：

CREATE TABLE mc.cars (
    owner_id int PRIMARY KEY,
    car_reg text,
    owner_name text,
    price float,
    purchased date
);

虽然这个模型可能没问题，但假设您有一个（幸运！）拥有超过 1000 辆汽车的车主。除了一个大车库，它们也可能是造成大排长队的原因。但是，如果您的表格看起来像这样：

CREATE TABLE mc.cars2 (
    owner_id int,
    car_reg text,
    owner_name text,
    price float,
    purchased date,
    PRIMARY KEY (owner_id, car_reg)
) WITH CLUSTERING ORDER BY (car_reg ASC)

您将不太可能看到宽行，因为您的分区键也是由汽车注册号组成的。