Question

我有Cassandra表

CREATE TABLE schema1 (
  key bigint,
  lowerbound bigint,
 upperbound bigint,
 data blob,
  PRIMARY KEY (key, lowerbound,upperbound)
) WITH COMPACT STORAGE ;

我想使用CQL

执行范围查询

Select lowerbound, upperbound from schema1 where key=(some key) and  lowerbound<=123 order by lowerbound desc limit 1 allow filtering;

有关压实策略的任何意见
注意MY读取：写入比例是1：1

Answer 1

大小分层压缩是默认的，应该适用于大多数用例。 2012年，DataStax发布了一篇名为When To Use Leveled Compaction的文章，其中指出了三个（主要）条件，其中级别压缩是一个好主意：

对读取延迟的高灵敏度（您的查询需要满足第99个百分位的延迟SLA）。
高读/写比率
行经常更新

当水平压缩不是一个好主意时，它还确定了三种情况：

您的磁盘无法处理压缩I / O
大量工作量
行是一次写入

请注意我上面提到的六种方案中没有一种是特定于范围查询的。

我的问题是＆＃34;你想解决什么问题？＆＃34;你提到了＃34;表现更好，＆＃34;但我发现查询性能问题往往与数据模型设计有关。如果您使用低效的主键策略运行，切换压缩策略将不会有太大帮助。由于您的查询需要ALLOW FILTERING这一事实，我会说改变压缩策略并不会有太大帮助。

DataStax文档包含Slicing over partition rows部分，与您的查询有些类似。看看它是否有帮助。

Answer 2

水平压缩意味着您对密钥的查询涉及的SSTable更少，但需要额外的IO。此外，在压缩过程中，它使用的磁盘数比数据多10％，而对于大小分层压缩，则需要加倍。哪个更好取决于您的设置，查询等。您是否遇到性能问题？如果没有，如果我可以处理额外的IO，我可能会选择水平，因为这意味着我不需要在磁盘空间方面保持50 +％的净空以进行压缩。但同样，没有“正确的方法”。

或许读到这个： http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra

Answer 3

当行经常更新时来自datasatx文章无论您是处理频繁覆盖列的瘦行（如“用户”列系列中的“上次访问”时间戳），还是处理不断添加新列的宽行，当您使用大小紧凑的压缩更新行时，它将分布在多个SSTable上。另一方面，级别压缩可以保持行分布的SSTable数量非常低，即使频繁的行更新也是如此。

什么是压缩策略，以便在群集列上的Range查询中表现更好

3 个答案: