database - ScyllaDB 中多个压缩重叠的可能性是多少？

Question

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

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

Answer 1

你完全正确:

使用size-tiered compaction strategy 压缩可能会暂时使磁盘需求加倍。但它不会使整个磁盘需求加倍，而只是参与此压缩的 sstables(另请参阅我的 blog post 关于大小分层压缩及其空间放大)。 “整个磁盘使用”和“压缩中涉及的 sstables”之间确实存在差异，原因有二:

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

第二个原因不能指望 - 因为分片选择何时独立压缩，如果你不走运，所有分片可能决定同时压缩同一张表，更糟糕的是 - 可能碰巧进行最大的压缩同时。如果您开始“主要压缩”(nodetool compact)，这种“不幸”也有 100% 的概率发生。

第一个原因，你问的那个，确实更有用和可靠:除了所有分片不太可能选择压缩所有 sstables 完全相同的时间之外，Scylla 的压缩算法中有一个重要的细节在这里有帮助:每个分片一次只进行一次(大致)给定大小的压缩。因此，如果您有许多大小大致相等的表，则任何分片都不能一次对多个表进行完全压缩。这是有保证的 - 这不是概率问题。

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

发行中https://github.com/scylladb/scylla/issues/2871我提出了一个关于 Scylla 如何保证的想法，即当磁盘空间不足时，分片(第 1 点)也用于减少临时磁盘空间的使用。我们没有实现这个想法，而是实现了一个更好的想法——“增量压缩策略”，它分 block 进行大量压缩(“增量”)以避免大部分临时磁盘使用。参见 this blog post了解这种新的压缩策略是如何工作的，以及展示它如何降低临时磁盘使用率的图表。请注意，增量压缩策略目前是 Scylla Enterprise 版本的一部分(它不在开源版本中)。