层级压实策略：调整sstable_size_in_mb参数会带来什么影响？

Question

为提高读取性能，我尝试使用较少的底层SSTables来进行LCS，因此我将sstable_size_in_mb设置为1280MB，这是一些文章建议的。这些文章指出，160MB的默认值很久以前由Cassandra核心团队在一台相当老旧且只有2GB RAM的服务器上选择。然而，我的担忧在于使用更高值的sstable_size_in_mb可能会产生什么影响。

我了解到LCS经常将所有L0中的SSTables与所有L1中的SSTables一起压缩，然后替换L1的整个内容。因此，每次替换L1时，硬件需求CPU/RAM和写入放大可能会随着sstable_size_in_mb的增加而增加。实际上，如果sstable_size_in_mb=1280MB，则每次需要合并10个大小为1280MB的表格与所有L0表格。即使要替换的SSTables数量似乎较少（一个L1 SSTables与10个L2 SSTables合并，然后替换这10个L2 SSTables），也可能对更高级别产生影响。

问题：

1.使用更高值的sstable_size_in_mb（如1280MB）可能通过减少涉及到CQL表的SSTables的数量来提高读取性能。然而，使用这样更高的值（如1280MB）对sstable_size_in_mb有什么其他影响？

2.如果使用更高值，是否有相应的配置可以调整（垃圾收集器、块缓存等），以使这些更大的SSTables的压缩和GC活动更好地实现更好的性能？

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

- Klun

Answer 1

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

“更大的文件意味着每个级别包含更多数据，因此读取将需要触摸较少的sstables，但我们在向前合并时也会压缩更少的未更改数据。”（注意：我怀疑有一个打字错误，他的意思是“我们在向前合并时也会压缩更多未更改的数据”，这与您在第二段所述的内容以及他所说的更大的文件影响“压缩效率”相一致。）

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

回答您的第二个问题，压缩确实会在堆中产生很多变化，因为它从SSTables创建许多短暂对象。由于使用1280MB大小时涉及到的SSTables更大，您应该注意gc.log并注意“Humongous Allocation”消息（如果您使用G1GC）。如果它们经常发生，您可以使用-XX：G1HeapRegionSize选项增加区域大小，以避免昂贵的巨型对象集合。

对于您的第三个问题，据我所知，许多人长期以来都使用了160MB的默认值，因为我们尚未发布关于使用现代硬件进行基准测试的更大SSTable大小的影响/收益的综合分析（我尝试运行了一些快速测试，但忙于其他事情，没有完成这项工作，抱歉）。但是，我认为如果人们有兴趣在LCS中实现更高的节点密度，则这个SSTable大小是值得探索的参数。

- weideng