LeveledCompactionStrategy ：调整 sstable_size_in_mb 有何影响？

Question

为了提高读取性能，我尝试使用LCS来减少底层 SSTable 的数量，因此我按照一些文章的建议将sstable_size_in_mb设置为1280MB，这些文章指出160MB默认值是 Cassandra 核心团队很久以前就挑选出来的，相当不错。旧服务器现在只有 2GB RAM。但是，我担心的是sstable_size_in_mb具有较高值的​​影响 。

我的理解是LCS定期将L0中的所有SSTable与L1中的所有SSTable压缩在一起，然后替换L1的全部内容。因此，每次更换 L1 时，随着sstable_size_in_mb的值增大，对 CPU/RAM 和写入放大的硬件要求可能会更高。事实上，如果sstable_size_in_mb = 1280MB，那么 L1 中的 10 个 1280MB 表每次都必须与所有 L0 表合并。即使要替换的 SSTable 看起来较低（一个 L1 SSTable 与 10 个 L2 SSTable 合并，然后这 10 个 L2 SSTable 被替换），也许还会对更高级别产生影响。

问题 ：

1. 具有较高的sstable_size_in_mb值可以通过减少 CQL 表中涉及的 SSTable 数量来提高读取性能。但是， sstable_size_in_mb具有如此高的值（例如 1280MB）还有什么其他含义？

2. 如果值较高，是否有任何相应的配置需要调整（垃圾收集器、块缓存等），以便为那些较大的 SSTable 的压缩提供更好的性能，并减少 GC 活动？

3. 更主观的问题，您在部署中使用的sstable_size_in_mb的典型值是多少？

Answer 1

为了回答你的第一个问题，我想引用 Jonathan Ellis 在 CASSANDRA-5727 中的一些原文，当时社区最初研究了 sstable_size_in_mb（随后决定了 160 这个数字）。

“更大的文件意味着每个级别包含更多数据，因此读取将不得不接触更少的sstable，但是当我们向前合并时，我们也会压缩更少的未更改数据。” （注意：我怀疑有一个拼写错误，他的意思是“当我们向前合并时，我们还会压缩更多未更改的数据”，这与您在第二段中所说的内容一致，以及他所说的较大文件影响“压缩效率”的含义.)

至于任何其他含义：它可能会推动 LCS 节点密度上限的极限，因为对于每个节点相同数量的 SSTable，它允许更高的密度。

为了回答你的第二个问题，压缩确实会在堆中产生大量的混乱，因为它从 SSTables 中创建了许多短暂存在的对象。当您使用 1280MB 大小时，考虑到压缩中涉及更大的 SSTable，您应该注意 gc.log 并留意“巨大分配”消息（如果您使用 G1GC）。如果它们经常发生，您可以使用 -XX:G1HeapRegionSize 选项增加区域大小，以避免代价高昂的巨大对象集合。

对于你的第三个问题，据我所知，许多人长期以来一直使用 160MB 默认值，因为我们还没有发布关于使用现代硬件对更大的 SSTable 大小进行基准测试的影响/好处的全面分析（我尝试过进行一些快速测试，但忙于其他事情而没有完成这项工作，抱歉）。然而，我确实认为，如果人们有兴趣通过 LCS 实现更高的节点密度，那么这个 SSTable 大小是一个值得探索的参数。