【发布时间】：2014-09-25 23:21:10
【问题描述】：
我正在设计阅读模式以及编写关键问题陈述。 哪个会更高效地创建具有紧凑存储的表或创建具有集群顺序的表。
根据我的要求，聚类顺序可以帮助我在阅读过程中节省一些时间。但同时我担心它会影响插入。
谁能告诉我？
【问题讨论】：
【发布时间】：2014-09-25 23:21:10
【问题描述】：
紧凑型存储是为了向后兼容旧款应用程序。我建议避免使用它。来自官方文档：
使用紧凑型存储¶
紧凑存储指令用于向后兼容 使用 CQL 的旧应用程序。使用指令将数据存储在 传统（Thrift）存储引擎格式。利用 CQL 功能，请勿在新应用程序中使用此指令。
CREATE TABLE sblocks (block_id uuid, subblock_id uuid, data blob, PRIMARY KEY (block_id, subblock_id) ) 紧凑存储； 使用紧凑存储指令可以防止您定义更多 比不属于复合主键的一列。紧凑型 使用非复合主键的表可以有多个 不属于主键的列。
使用复合主键的紧凑表必须至少定义 一个聚类列。之后不能添加或删除列 创建一个紧凑的表。除非您指定 WITH COMPACT STORAGE，否则 CQL 创建一个非紧凑存储的表。¶
【讨论】：
-
那么集群订单存储呢。我猜它使集群键保持有序。这在插入过程中需要一些时间。它与有序分区有关吗？
-
Cassandra 将根据聚类指示将分区的所有行按排序顺序保留。例如如果你的主键是（a，b，c，d），那么a是分区键，在那个分区中，数据将按b排序，具有相同（a，b）的数据将按c排序。 。等等。记住 CUD 操作转到提交日志和内存表。他们不打磁盘。因此，摄取（写入速度）非常快。压缩期间是丢弃较旧的数据并保留较新的数据。因此，您不必担心性能的排序。
-
感谢您的回复。根据您的回复，我理解 Cassandra 按插入顺序将数据存储在 Memtable 中。并且当数据被刷新时，数据会按照顺序在 sstable 中对齐。因此，当我使用 Clustering Order(desc) 编写 create table () 时。我不在乎插入期间的排序开销。如果有错误请纠正我。:)
-
几乎正确...SStables 是不可变的。在压缩期间，会创建新表，而不是更改现有表。这将进入细节，但重点是插入会进入提交日志和内存表，因此，您不必担心在文件中对数据进行排序的成本。
-
您确实需要选择集群键和分区键，以便能够在使用集群的同时高效地执行查询（即避免大型集群中的热点）。这才是你应该关注的。
具有集群顺序的表确实没有没有表的惩罚。写入总是进入内存表（因为 Cassandra 使用日志结构化存储）并且或多或少像一行日志。在读取以查找分区内的正确 CQL 行时，集群键确实很有帮助。使用聚类键进行搜索非常有效，并且确实是推荐的执行方式。
【讨论】：
-
所以如果我同时使用集群顺序和紧凑存储来创建表，那会以任何方式打扰我的读/写。
-
使用紧凑存储，您将无法拥有多个不属于分区或集群键的列。这样想 - Cassandra 将内容存储为 Map
>。如果 CQL 中没有紧凑存储，则每个值都会重复 ClusteringKey 名称。所以一个 CQL 行将是 SortedMap 中的多个条目。使用紧凑存储，集群键名不会重复。因此，您只能在每个 CQL 行中获得价值。因此不推荐紧凑存储。 -
让我们假设我有一个集群键名“A”，我希望它以降序显示数据。我是否需要使用 CLUSTERING ORDER BY(A desc) 以降序创建表。或者创建一个简单的表并使用 order by A desc 会更好
-
我想我的点数据是按照我们定义的顺序存储的（默认情况下根据聚类键的位置，或者我们可以使用 CLUSTERING ORDER BY 更改默认行为）。我们可以使用 orderby 来反转默认顺序或预定义顺序
-
Order by 目前仅在 PRIMARY KEY 的聚簇列上支持，即聚簇键
我没有代表发表评论，所以我想我会把这个留给任何偶然发现这个问题并使用 C* >= 3.0.0 的人。
Cassandra 的存储引擎在版本 3 中进行了重构。默认情况下，数据现在更紧凑地存储在磁盘上。使用COMPACT STORAGE 选项没有任何好处，除了向后节俭兼容性之外，实际上应该完全避免使用它。
【讨论】：