我知道分级压缩在 Cassandra、rocksdb 等 DBS 中是如何工作的。有些级别的最大数量为 4，有些为 7。这个数字如何影响压缩过程？为什么我不能只有 2 个级别，第 1 个级别已刷新内存表数据（文件之间可能重叠），第 2 个级别包含不重叠的 SST？
如果有任何文档或重复问题，请重定向。
Edit-1：当级别数增加时，重复数据会增加。
【问题讨论】：
标签： cassandra leveldb rocksdb scylla
LCS 来解决 STCS 的空间放大问题。它还减少了读取放大（每个读取请求所需的平均磁盘读取次数）。
Leveled compaction 将小的 sstables（“片段”）划分为多个级别：
Level 0 (L0) 是新的 sstables，最近从 memtables 中刷新。随着它们的数量增长（并且读取速度变慢），我们的目标是将 sstables 从这个级别移到下一个级别。 其他每个级别，L1、L2、L3 等，都是一个呈指数增长的单次运行：L1 是 10 个 sstable 的运行，L2 是 100 个 sstable 的运行，L3 是 1000 个 sstable 的运行，以及很快。 （因子 10 是 Scylla 和 Apache Cassandra 中的默认设置）。
在解决或至少显着改善空间放大问题的同时，LCS 带来了另一个问题，写放大，更糟。
“写入放大”是我们必须为新刷新的 sstable 数据的每个字节写入磁盘的字节量。写入放大始终高于 1.0，因为我们将每条数据写入提交日志，并且然后再次写入到sstable，然后每次compaction都会涉及到这条数据并复制到一个新的sstable中，这就是另一个写入。
在此处了解更多信息：
【讨论】：
Leveled compaction 对 Scylla 的工作方式与在 Cassandra 和 Rocksdb 中的工作方式非常相似（有一些小的差异）。如果您想简要了解一下 Scylla 中的水平压缩是如何工作的以及为什么，我建议您阅读我的博客文章 https://www.scylladb.com/2018/01/31/compaction-series-leveled-compaction/。
您关于为什么两个级别（最近刷新的 sstable 的 L0，不相交范围的 sstable 的 Ln）还不够的具体问题 - 是一个非常好的问题：
主要问题是单个刷新的内存表（L0 中的 sstable）包含随机写入集合，通常会与 Ln 中的 所有 sstable 相交。这意味着每次刷新新的memtable时都要重写整个数据库，结果是超大量的写入放大，这是完全不能接受的。
显着减少这种写入放大的一种方法（但可能还不够）是引入一个级联的中间级别 L0、L1、...、Ln。最终结果是我们有 L(n-1)，它是 Ln 大小的 1/10（比如说），我们将 L(n-1)——不是一个单一的 sstable——合并到 Ln 中。这是您提到的所有系统中使用的分级压缩策略 (LCS) 的方法。
完全不同的方法可能是不将单个 sstable 合并到 Ln 中，而是先尝试收集大量数据，然后才将其合并到 Ln 中。我们不能只在 L0 中收集 1,000 个表，因为这会使读取变得非常缓慢。相反，为了收集如此大量的数据，可以在 L0 中使用大小分层压缩 (STCS)。换句话说，这种方法是 STCS 和 LCS 的“混合”，具有两个“级别”：L0 在新的 sstables 上使用 STCS，Ln 包含一系列 sstables（具有不相交范围的 sstables）。当 L0 达到 Ln 大小的 1/10（比方说）时，L0 被压缩成 Ln。这种混合方法可能比 LCS 具有更低的写入放大，但由于大部分数据在 Ln 中运行，因此它具有与 LCS 相同的低空间和读取放大。据我所知，没有一个提到的数据库（Scylla、Cassandra 或 Rocksdb）支持这种“混合”压缩。
【讨论】：