Cassandra LeveledCompactionStrategy 和每次读取的高 SSTable 数

Question

我们使用的是 cassandra 2.0.17，我们有一个包含 50% 选择、40% 更新和 10% 插入(无删除)的表。

为了对此类表具有较高的读取性能，我们发现建议使用 LeveledCompactionStrategy(它应该保证 99% 的读取将从单个 SSTable 中完成)。每天运行的时候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

描述组返回:

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。

您正在寻找以下行:

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

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

新的 sstable 进入 L0，然后逐渐上升。您可以看到上面的示例处于非常糟糕的状态。我们仍然有 2000 个 sstables 来处理比所有其他级别中存在的更多。这里的性能会比我刚刚使用 STCS 时差很多。

Nodetool cfstats 可以很容易地衡量 LCS 是否跟上您的用例。全天每 15 分钟倾倒一次。任何时候您的级别不平衡，读取性能都会受到影响。如果它一直落后，您可能想切换到 STCS。如果它在您加载数据时出现 10 分钟的峰值，但当天其余时间都很好 - 那么您可能会决定忍受它。如果它永远不会失去平衡——坚持使用 LCS——它完全适合你。

附带说明 - 2.1 允许 L0 执行 STCS 样式合并，这将有助于您遇到临时峰值的情况。如果您处于上述十分钟的场景中 - 几乎肯定值得升级。