我有一个用例，其中频繁读取和更新Cassandra中的许多行，其中写/读比率略高于1。而且，在大多数情况下，写会替换一行中的所有值。我想知道如何针对这种用例进行优化。通常，建议使用分层压缩，但由于实际上要重新插入整行，因此按大小分级压缩似乎是一种更好的方法。我对吗？在这种情况下，是否还可以进行一些特定的优化？
答案 0 :(得分：1)
这取决于您要尝试优化的内容。分层压缩和大小分层压缩在您的用例中具有不同的优点和缺点，哪种对您更有利，取决于您的用例或硬件的具体情况：
其他人似乎在其答复中强烈推荐的分层压缩策略（LCS），其好处是浪费最少的磁盘磁盘空间-大约10％-存储旧数据，已经被覆盖。另一方面，LCS的最大缺点是它使用大量的磁盘I / O-反复重写相同的数据以保持较低的空间使用率。由于用例的写操作很繁琐（多达一半的请求被写），所以这种额外的写I / O可能会成为一个大问题。
分层压缩策略（STCS）将需要减少每次写入的I / O工作，但同时浪费更多的磁盘空间：默认情况下，每行可以存储多达4个版本（！）。在开始压缩之前，先将它分成4个不同的sstables并删除旧的副本。您可以通过设置min_threshold=2而不是默认的4来显着减少这种浪费，但是它仍然不能接近分层压缩的空间最优性。 Cassandra的Size-Tiered压缩实现还存在一个问题，即在压缩过程中它需要输入和输出文件同时存在-导致经常被引用的需求是始终保留一半的磁盘空间（ScyllaDB有一个解决方案最后一个问题，但Apache Cassandra没有）。
总而言之，使用STCS，您将需要更多的磁盘空间；而使用LCS，则将需要更多的磁盘带宽。对您而言，哪个问题更严重取决于您的硬件以及磁盘带宽，磁盘空间量（或两者都不存在）成为瓶颈的距离。
有关这些问题的更多详细信息，您可以查看我在Size-tiered compaction and space amplification problem上撰写的博客文章，以及在Leveled Compaction and its write-amplification problem上撰写的博客文章。