Cassandra主键与排序限制详解

从现在开始，努力学习吧！本文《Cassandra复合主键与排序限制解析》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

Cassandra的`ORDER BY`子句存在特定限制，它仅支持对复合主键中的第一个聚簇列进行排序，而不支持对二级索引列或非首个聚簇列进行排序。当查询尝试在二级索引或非首个聚簇列上使用`ORDER BY`时，会引发错误。要实现按特定列排序，需要重新设计表结构，将目标排序列设置为复合主键中的第一个聚簇列，以适应Cassandra的查询模型。

在Cassandra中进行数据建模时，理解主键（Primary Key）的构成及其对查询行为的影响至关重要。主键由分区键（Partition Key）和聚簇列（Clustering Columns）组成。分区键决定了数据在集群中的分布，而聚簇列则决定了数据在每个分区内部的存储顺序。

Cassandra主键结构与排序机制

以以下表结构为例：

CREATE TABLE global_product_highlights (
  deal_id text,
  product_id text,
  highlight_strength double,
  category_id text,
  creation_date timestamp,
  rank int,
  PRIMARY KEY (deal_id, product_id, highlight_strength)
);

在此表中：

• deal_id 是分区键。
• product_id 是第一个聚簇列。
• highlight_strength 是第二个聚簇列。

Cassandra的数据在磁盘上是按照分区键和聚簇列的顺序存储的。这意味着，对于同一个deal_id下的所有行，它们将首先按product_id排序，然后按highlight_strength排序。

ORDER BY子句的限制

Cassandra的SELECT查询中ORDER BY子句的使用受到严格限制。它仅允许对复合主键中的第一个聚簇列进行排序。这意味着，在上述表结构中，只有在查询中指定了deal_id的情况下，才能对product_id进行ORDER BY排序。

例如，以下查询是合法的（假设deal_id已在WHERE子句中指定）：

SELECT product_id FROM global_product_highlights WHERE deal_id = 'some_deal' ORDER BY product_id DESC;

然而，当尝试对非首个聚簇列（如highlight_strength）或二级索引列（如category_id）进行ORDER BY排序时，Cassandra会抛出错误。

考虑以下查询：

SELECT product_id FROM global_product_highlights WHERE category_id = 'some_category' ORDER BY highlight_strength DESC;

这个查询会失败，并返回错误信息：“ORDER BY with 2ndary indexes is not supported.”。即使我们没有使用二级索引，仅仅尝试对highlight_strength进行排序（当它不是第一个聚簇列时），也会失败。

原因分析：

1. 二级索引与排序： Cassandra的二级索引是为了支持对非主键列的查询而设计的，但它们并不维护数据的排序顺序。因此，在二级索引列上使用ORDER BY是不被支持的。
2. 非首个聚簇列的排序： ORDER BY子句依赖于数据在磁盘上的物理存储顺序。Cassandra只保证在同一分区内，数据会按照聚簇列的顺序进行存储。但这种排序是层级式的，即首先按第一个聚簇列排序，然后按第二个，以此类推。直接跳过第一个聚簇列而对第二个聚簇列进行全局排序，将需要Cassandra进行昂贵的全分区扫描或重新排序操作，这与Cassandra的高吞吐量设计理念相悖。

解决方案

如果您的业务需求是根据highlight_strength进行排序，那么唯一的解决方案是修改表结构，将highlight_strength提升为第一个聚簇列。

修改后的表结构示例：

CREATE TABLE global_product_highlights_by_strength (
  deal_id text,
  highlight_strength double,
  product_id text,
  category_id text,
  creation_date timestamp,
  rank int,
  PRIMARY KEY (deal_id, highlight_strength, product_id)
);

在此新的表结构中：

• deal_id 仍然是分区键。
• highlight_strength 现在是第一个聚簇列。
• product_id 是第二个聚簇列。

有了这个新的表结构，您就可以在查询中对highlight_strength进行排序了（前提是deal_id在WHERE子句中指定）：

SELECT product_id FROM global_product_highlights_by_strength WHERE deal_id = 'some_deal' ORDER BY highlight_strength DESC;

注意事项：

1. 数据建模的查询驱动原则： Cassandra的数据模型是高度查询驱动的。这意味着您应该根据应用程序的查询模式来设计表结构。如果需要多种排序方式，可能需要创建多张冗余表，每张表的主键（特别是聚簇列）都针对特定的查询模式进行优化。
2. 分区键的选择： 分区键的选择至关重要，它影响着数据的分布和查询的并行度。应选择能够均匀分布数据并避免热点（hotspot）的分区键。
3. 二级索引的局限性： 虽然二级索引可以帮助查询非主键列，但它们不适用于需要排序或范围查询的场景，并且在大量写入时可能引入额外的性能开销。
4. 避免宽行： 如果聚簇列的选择导致单个分区内的数据量过大（即“宽行”），可能会影响性能和稳定性。

总结

Cassandra的ORDER BY子句是其数据模型中一个重要的限制。理解ORDER BY只能作用于第一个聚簇列，并且不兼容二级索引是设计高效Cassandra数据模型的关键。当遇到排序需求时，应优先考虑调整表的主键结构，以确保目标排序列成为第一个聚簇列，从而符合Cassandra的查询模型和性能优化原则。这通常意味着为不同的查询需求创建多张经过优化的表，而不是试图用一张表满足所有复杂的查询和排序要求。

终于介绍完啦！小伙伴们，这篇关于《Cassandra主键与排序限制详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！