Cassandra 分层压缩策略如何确保90%的读取来自一个sstable

我试图理解Cassandra中的分层压缩策略是如何工作的，它可以保证90%的读取都能从单个sstable中得到满足

从税务单据：

将新的SSTABLE添加到第一层L0，并立即与L1中的SSTABLE一起压缩。当L1填满时，额外的sstables将升级到L2。L1中生成的后续SSTABLE将与L2中与其重叠的SSTABLE一起压缩

Cassandra中的LeveledCompactionStrategy（LCS）实现了LevelDB的内部结构。您可以在中查看具体的实现细节

为了给您一个简单的解释，请考虑以下几点：

每个sstable都是在达到固定（相对较小）大小限制时创建的。默认情况下，L0获得5MB的文件，并且每个后续级别的大小都是其大小的10倍。（在L1中，您将拥有50MB的数据，L2将拥有500MB的数据，依此类推）

创建Sstables时要保证它们不会重叠

当一个料位填满时，将触发压实，并将料位L的料位提升至料位L+1。因此，在L1中，10个文件中有50MB，100个文件中有500MB，等等

以粗体显示的相关详细信息证明了从同一文件（sstable）读取90%的正确性。让我们一起计算，一切都会变得更清楚（我希望：）

假设您在L0中有键A、B、C、D、E，每个键需要1MB的数据

接下来，我们插入键F。因为级别0已填充，压缩将在级别1中创建一个包含[a、B、C、D、E]的文件，而F将保留在级别0中

这是L1中1个文件中约83%的数据

接下来我们插入G，H，I，J和K。因此L0再次填充，L1得到一个新的sstable，其中包含[I，G，H，I，J]

现在我们在L0中有K，[A，B，C，D，E]，在L1中有[I，G，H，I，J]

这是L1中约90%的数据

如果我们继续插入密钥，我们将获得相同的行为，这就是为什么90%的读取都来自大致相同的文件/表

我提到的链接（压缩选择的大小不同，因为它们是LevelDB默认值，而不是C*s），在本段中给出了更深入和详细的信息（更新和墓碑会发生什么情况）：

当级别L的大小超过其限制时，我们将其压缩到后台线程中。压缩从级别L拾取一个文件，并从下一个级别L+1拾取所有重叠文件。请注意，如果级别L文件仅与级别-（L+1）文件的一部分重叠，则级别-（L+1）的整个文件将用作压缩的输入，并将在压缩后丢弃。旁白：因为0级是特殊的（其中的文件可能会相互重叠），所以我们专门处理从0级到1级的压缩：如果其中一些文件相互重叠，0级压缩可能会拾取多个0级文件

压缩合并拾取的文件的内容，以生成一系列级别-（L+1）的文件。在当前输出文件达到目标文件大小（2MB）后，我们切换到生成一个新的级别-（L+1）文件。当当前输出文件的键范围增长到足以重叠超过10个级别-（L+2）文件时，我们也会切换到新的输出文件。最后一条规则确保以后对级别-（L+1）文件的压缩不会从级别-（L+2）拾取太多数据

---

希望这有帮助

我已经编辑了我的问题。你能解释一下吗？谢谢你的详细解释。一个问题是，如果重复行的另一个条目作为示例出现，该怎么办：键A、C、G的条目出现了。还有一件事可能是打字错误。它将是[F，G，H，I，J]而不是[I，G，H，I，J]对吗？@Chaity也来自LevelDB文档：“压缩会删除覆盖的值。如果没有更高编号的级别包含范围与当前键重叠的文件，它们也会删除标记。”@LuísCorreia是第二级故意重复两次的I？AFAIK一旦SSTable在L0中创建，如果可能，Cassandra将尝试将其压缩到L1。它不必等到L0中有5个SSTABLE。这仅指L1及以上。