Question

我们正在使用cassandra 2.0.17，我们有一个包含50％选择，40％更新和10％插入（无删除）的表。

为了获得这种表的高读取性能，我们发现建议使用LeveledCompactionStrategy（它应该保证从单个SSTable中实现99％的读取）。每天当我运行nodetool cfhistograms时，每次阅读都会看到越来越多的SSTtables。第一天我们有1，比我们有1,2,3 ... 今天早上我看到了这个：

ubuntu@ip:~$ nodetool cfhistograms prodb groups | head -n 20                                                                                                                                
prodb/groups histograms

SSTables per Read
1 sstables: 27007
2 sstables: 97694
3 sstables: 95239
4 sstables: 3928
5 sstables: 14
6 sstables: 0
7 sstables: 19

describe组返回：

CREATE TABLE groups (
  ...
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.100000 AND
  gc_grace_seconds=172800 AND
  index_interval=128 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'LeveledCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};

这是正常的吗？在这种情况下，我们失去了使用LeveledCompaction的优势，如文档中所述，应该保证99％的读取来自单个sstable。

Answer 1

这取决于用例 - 但根据经验，我通常会将LCS的90％读取率与10％写入率进行比较。根据您的描述，您最多只能看50/50。

LCS提出的额外压缩要求让它非常饥饿。压缩得到备份很可能并且您的水平不平衡。最简单的方法是为相关表运行nodetool cfstats。

您正在寻找这条线：

每个级别的SSTable：[2042 / 4,10,119 / 100,232,0,0,0,0,0]

方括号中的数字表示每个级别中有多少个sstables。 [L0，L1，L2 ......]。斜线后的数字是理想的水平。根据经验，L1应为10，L2 100，L3 1000等。

新的sstables进入L0，然后逐渐向上移动。您可以看到上面的示例处于非常糟糕的状态。我们仍然有2000个sstables来处理超过所有其他级别的存在。这里的表现将比我刚刚使用过STCS的情况要糟糕得多。

Nodetool cfstats可让您轻松衡量LCS是否与您的用例保持同步。全天每15分钟就抛出一次。只要您的电平不平衡，读取性能就会受到影响。如果它一直落后，你可能想切换到STCS。如果在数据加载时出现10分钟的峰值，但当天剩下的时间都很好 - 那么你可能决定忍受它。如果它永远不会失衡 - 坚持使用LCS - 它完全适合你。

作为旁注 - 2.1允许L0执行STCS样式合并，这将有助于您有临时峰值的情况。如果你在上面的十分钟场景中 - 它几乎肯定值得升级。

Cassandra LeveledCompactionStrategy和每次读取的高SSTable数

1 个答案: