ScyllaDB 中多重压缩重叠的可能性有多大？

Question

在开源版本中，Scylla 建议为 \xe2\x80\x9ccompactions\xe2\x80\x9d 保留最多 50% 的可用磁盘空间。同时，文档指出每个表都是相互独立压缩的。从逻辑上讲，这表明在具有数十个（甚至多个）表的应用程序中，\xe2\x80\x99s 如此多的压缩同时发生的可能性很小。

\n

是否有一个数学模型来计算在具有多个表的应用程序中多重压缩如何重叠？根据粗略的分析，似乎多次重叠压缩的可能性很小，特别是当我们处理数十个独立表时。

\n

Answer 1

你是绝对正确的：

使用大小分层压缩策略，压缩可能会暂时使磁盘需求增加一倍。但它不会使整个磁盘要求加倍，而只会使压缩中涉及的 sstables 要求加倍（另请参阅我关于大小分层压缩及其空间放大的博客文章）。“整个磁盘使用情况”和“此压缩中涉及的 sstables”之间确实存在差异，原因有两个：

1. 正如您在问题中指出的，如果您有 10 个大小相似的表，则仅压缩其中一个表只能处理 10% 的数据，因此压缩期间的临时磁盘使用量可能是磁盘使用量的 10%，而不是 100% 。
2. 此外，Scylla 是分片的，这意味着不同的 CPU 完全独立地处理它们的稳定表和压缩。如果你的机器上有 8 个 CPU，每个 CPU 只处理 1/8 的数据，所以当它进行压缩时，最大的临时开销将是表大小的 1/8，而不是整个表大小。

第二个原因不能指望 - 因为分片选择何时独立压缩，如果不幸的话，所有分片可能决定在完全相同的时间压缩同一个表，更糟糕的是 - 可能碰巧同时进行最大的压缩时间。如果您启动“主要压缩”（nodetool Compact），这种“不幸”也可能以 100% 的概率发生。

第一个原因，即您询问的原因，确实更有用和可靠：除了所有分片不太可能选择完全相同地压缩所有 sstable 之外，Scylla 的压缩算法中有一个重要的细节可以在这里提供帮助：每个分片一次仅对（大致）给定大小进行一次压缩。因此，如果您有许多大小大致相等的表，则没有分片可以一次对多个表进行完全压缩。这是有保证的——这不是概率问题。

当然，这个“技巧”仅在您确实有许多大小大致相等的表时才有用。如果一个表比其他表大得多，或者表的大小差异很大，那么控制最大临时磁盘使用量不会对您有太大帮助。

在问题https://github.com/scylladb/scylla/issues/2871中，我提出了一个想法，即 Scylla 如何保证当磁盘空间不足时，分片（第 1 点）也用于减少临时磁盘空间使用。我们还没有实现这个想法，而是实现了一个更好的想法——“增量压缩策略”，它分块进行巨大的压缩（“增量”）以避免大部分临时磁盘使用。请参阅这篇博客文章，了解这种新的压缩策略的工作原理，以及演示它如何降低临时磁盘使用率的图表。请注意，增量压缩策略目前是 Scylla Enterprise 版本的一部分（不在开源版本中）。