为什么在 Cassandra 表中使用复合聚簇键？答案

【问题标题】：Why use a compound clustered key in Cassandra tables?为什么在 Cassandra 表中使用复合聚簇键？
【发布时间】：2015-07-22 01:42:52
【问题描述】：

为什么要在 cassandra 表中使用聚集索引？

例如；在这样的表格中：

CREATE TABLE blah (
  key text,
  a text,
  b timestamp,
  c double,
  PRIMARY KEY ((key), a, b, c)
)

集群部分是PRIMARY KEY的a, b, c部分。

有什么好处？有哪些注意事项？

【问题讨论】：

标签： cassandra data-modeling bigtable compound-key

【解决方案1】：

集群键主要做三件事。

1) 它们会影响您的表的可用查询模式。

2) 它们决定了表的磁盘排序顺序。

3) 它们决定了您的主键的唯一性。

假设我运行一个订购系统并希望在我的网站上存储产品数据。此外，我有几个配送中心，以及客户合同定价。因此，当某个客户在我的网站上时，他们只能访问以下产品：

可在其地理区域的配送中心 (DC) 购买。
在他们的合同中定义（因此他们可能不一定有权访问 DC 中的所有产品）。

为了跟踪这些产品，我将创建一个如下所示的表：

CREATE TABLE customerDCProducts (
  customerid text,
  dcid text,
  productid text,
  productname text,
  productPrice int,
  PRIMARY KEY (customerid, dcid, productid));

对于此示例，如果我想查看客户 B-26354 在 DC 1138 中的产品 123，我可以使用以下查询：

SELECT * FROM customerDCProducts
WHERE customerid='B-26354' AND dcid='1138' AND productid='123';

也许我想查看适用于客户 B-26354 的 DC 1138 产品：

SELECT * FROM customerDCProducts 
WHERE customerid='B-26354' AND dcid='1138';

也许我只想查看客户 B-26354 的所有 DC 中的所有产品：

SELECT * FROM customerDCProducts 
WHERE customerid='B-26354';

如您所见，dcid 和 productid 的集群键允许我对我的分区键 (customerid) 运行高性能查询，这些查询尽可能集中。

缺点？如果我想查询单个 DC 的所有产品，无论客户如何，我都不能。我需要建立一个不同的查询表来支持它。即使我只想查询一个产品，除非我还提供customerid 和dcid，否则我不能。

如果我希望我的数据以某种方式排序怎么办？对于此示例，我将从 Patrick McFadin 在Getting Started With Time Series Data Modeling 上的文章中获取灵感，并构建一个表格来跟踪气象站的最新温度。

CREATE TABLE latestTemperatures (
  weatherstationid text,
  eventtime timestamp,
  temperature text,
  PRIMARY KEY (weatherstationid,eventtime),
) WITH CLUSTERING ORDER BY (eventtime DESC);

通过在eventtime 上进行聚类，并指定DESCending ORDER BY，我可以像这样查询特定站点的记录温度：

SELECT * FROM latestTemperatures 
WHERE weatherstationid='1234ABCD';

返回这些值时，它们将按DESCending 的顺序排列eventtime。

当然，每个人（具有 RDBMS 背景...所以是的，每个人）都想知道的一个问题是，如何查询按eventtime 排序的所有结果？再说一次，你不能。当然，您可以通过省略 WHERE 子句来查询所有行，但这不会返回以任何有意义的顺序排序的数据。请务必记住，Cassandra 只能在分区键中强制执行集群顺序。如果您不指定一个，您的数据将不会被排序（至少不会按照您想要的方式排序）。

如果您有任何其他问题，请告诉我，我们很乐意为您解释。

【讨论】：