【问题标题】：LeveledCompactionStrategy : what is the impact of tuning the sstable_size_in_mb?LeveledCompactionStrategy：调整 sstable_size_in_mb 有什么影响？
【发布时间】：2019-10-02 09:53:12
【问题描述】：
为了提高读取性能，我尝试使用 LCS 减少底层 SSTable，因此我按照一些文章的建议将 sstable_size_in_mb 设置为 1280MB ，其中指出 160MB 默认值是 Cassandra 核心团队很久以前在一台相当旧的服务器上挑选出来的，现在只有 2GB 内存。但是，我担心具有较高值的含义 sstable_size_in_mb。
据我了解，LCS 会定期将 L0 中的所有 SSTable 与 L1 中的所有 SSTable 一起压缩，然后替换 L1 的全部内容。所以每次更换 L1 时，硬件要求 CPU/RAM 和写入放大可能会更高，sstable_size_in_mb 的值越大。确实，如果sstable_size_in_mb = 1280MB，那么L1中的10个1280MB的表每次都要与所有L0表合并。即使要替换的 SSTables 看起来更低（一个 L1 SSTables 与 10 个 L2 SSTables 合并，然后这 10 个 L2 SSTables 被替换），也可能在更高级别上也有影响。
问题：
-
具有较高的 sstable_size_in_mb 值可能会通过降低 CQL 表中涉及的 SSTable 的数量来提高读取性能。但是，对于 sstable_size_in_mb 具有如此高的值（如 1280MB）还有什么其他影响？
-
如果值更高，是否有任何相应的配置需要调整（垃圾收集器、块缓存等），以便在压缩那些更大的 SSTable 时获得更好的性能，并减少 GC 活动？
-
更主观的问题，您在部署中使用的 sstable_size_in_mb 的典型值是多少？
【问题讨论】：
标签：
cassandra
datastax
datastax-enterprise
cassandra-3.0
【解决方案1】：
为了回答您的第一个问题，我想引用 Jonathan Ellis 在 CASSANDRA-5727 中的一些原文，当时社区最初调查了 sstable_size_in_mb（随后决定使用 160 号）。
"更大的文件意味着每个级别包含更多的数据，所以读取会
必须接触更少的 sstables，但我们也在压缩更少不变
我们向前合并时的数据。”（注意：我怀疑有一个错字，他的意思是“我们在向前合并时压缩更多未更改的数据”，这与您在第二次中所说的一致段，以及他所说的影响“压缩效率”的更大文件的含义。）
至于任何其他含义：它可能会推动 LCS 节点密度上限的信封，因为对于每个节点相同数量的 SSTable，它会允许更高的密度。
要回答您的第二个问题，压缩确实会在堆中产生大量流失，因为它会从 SSTables 创建许多短期对象。当您使用 1280MB 大小时，由于压缩涉及更大的 SSTable，您应该注意您的 gc.log 并注意“Humongous Allocation”消息（如果您使用 G1GC）。如果事实证明它们经常发生，您可以通过使用 -XX:G1HeapRegionSize 选项来增加区域大小以避免昂贵的巨大对象集合。
对于您的第三个问题，据我所知，许多人已经使用 160MB 默认值很长时间了，因为我们还没有发布关于使用现代硬件对较大 SSTable 大小进行基准测试的影响/益处的全面分析（我试图进行一些快速测试，但忙于其他事情并没有完成这项工作，抱歉）。但是，我确实认为如果人们对使用 LCS 实现更高的节点密度感兴趣，那么这个 SSTable 大小是一个值得探索的参数。