Cassandra LeveledCompactionStrategy 和每次读取的高 SSTable 数量

Question

我们使用的是 cassandra 2.0.17，我们有一个 table 有 50% 的选择、40% 的更新和 10% 的插入（无删除）。

为了让这种 table 具有高读取性能，我们发现建议使用 LeveledCompactionStrategy（它应该保证 99% 的读取将从单个 SSTable 完成）。每天当我运行 nodetool cfhistograms 时，我每次阅读都会看到越来越多的 SSTtable。第一天我们有 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

描述组 returns 这个：

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 提出的额外压缩要求使其非常 io 饥饿。很可能压缩被备份并且你的级别不平衡。最简单的判断方法是使用运行 nodetool cfstats 获取有问题的 table。

您正在查找的行：

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

方括号中的数字表示每一层有多少个sstable。 [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 数量

Cassandra LeveledCompactionStrategy and high SSTable number per read

cassandra

cassandra-2.0