时间戳

首页 > 解决方案 > 水平压实不压实到更高水平

cassandra - 水平压实不压实到更高水平

问题描述

通过更改表从 STCS 切换到 LCS - 版本 3.11.3

ALTER TABLE table WITH compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'unchecked_tombstone_compaction': 'true'};

现在我看到有默认大小为 160mb 的 sstables，现在我看到超过 100 个 160mb sstables。

  1. 当初始转换发生时，创建的文件是 L0 吗？

  2. 如果是这样，它们什么时候被压缩到 L1，它已经几个小时并且启用了自动压缩。我仍然没有看到它们被压缩到更高的水平。

  3. 默认大小为 160mb，是 L0 还是 L1？

  4. sstable 的大小会变成多少？它们会是 160mb 还是更小？

  5. 在每个级别创建多少个文件后，它会被压缩到下一个级别吗？

标签： cassandra

解决方案

在 LCS 的默认情况下（sstable_size_in_mb = 160 mb），这是完全可以预料的。

L1及以上为正常水平。L0 只是占位符，可以有重叠的数据和任何大小的 sstables。在正常级别，两个 sstable 不重叠，这意味着没有两个 sstable 可以具有相同的分区。所以为了读取一个partion，我们只需要检查一个sstable。

当初始转换发生时，创建的文件是 L0 吗？如果是这样，它们什么时候被压缩到 L1，它已经几个小时并且启用了自动压缩。我仍然没有看到它们被压缩到更高的水平。

-> L0 像 32 个 sstable 一样满了，它使用 L0 中的 SCTC 使 sstable 倒计时。您可以查看 nodetool tablestats 以获取每个级别的 sstables 数量

更改复制策略时需要运行 nodetool repair-full，检查此过程。

默认大小为 160mb，是 L0 还是 L1？sstable 的大小会变成多少？它们会是 160mb 还是更小？

-> 只有 L0 可以有任何大小的 sstables。正常级别 N 有 10^N *160 MB sstables（其中 N>=1）。所以 LCS 在正常级别有固定大小的 sstables 但总大小会随着我们进入更高级别而增加（例如：L1（1.6G），L2（16G）等）

在每个级别创建多少个文件后，它会被压缩到下一个级别吗？

-> 在普通级别，每个级别需要容纳 10 倍以上的 sstable 才能升到更高级别。

推荐阅读