Cassandra LeveledCompaction策略在SSD上对读性能的影响

有关Cassandra的Compaction机制写了好几篇博客了。好像像我这么纠结Compaction机制的比较少吧。我比较了不同Compaction策略对写性能的影响、读性能的影响，以及compaction本身的性能我也有测试。就是想以具体的数字，来证实Compaction机制的特点，从而找到合适的应用场景。 LeveledCompaction是1.0以后，参考Leveldb实现的一个机制。确实有很多好处，如下：

• 保证90%的读只读一个sstable文件，最坏的情况，当单机有10T数据的时候，7（7层）个sstable
• 无用数据（删除的，过期的）比较少，最多占到10%
• Compaction空间开销比较小。具体多少需要测试，因为sstable等大小，所以比SizeTiered小是肯定的。不需要比较

这些都是官方的一些说法，我自己变了花样，更好理解一些。但这些，有一个大前提：就是Compaction已经做的差不多了--就是说L0层的数据已经比较占比较小的比例了。如果不然，leveled的性能要比SizeTiered差很多。下面给出一组数据，写入100G数据：

• Compaction刚刚开始做：读性能统计如下：

RunTim(ms)	558488
Thoughput(ops/sc)	1790.549
Options	1000000
vgLtncy(us)	55669.79
MinLtncy(us)	1008
MxLtncy(us)	1221040
95thPcntilLtncy(ms)	84
99thPcntilLtncy(ms)	108

• Compaction进行到三分之一左右读性能统计如下：

RunTime(ms)	189432
Throughput(ops/sec)	5278.939
Operations	1000000
AverageLatency(us)	18872.15
MinLatency(us)	990
MaxLatency(us)	1187677
95thPercentileLatency(ms)	35
99thPercentileLatency(ms)	61

• Compaction进行到，L0层只占三分之一是，读性能统计如下：

RunTime(ms)	161981
Throughput(ops/sec)	6173.564
gOperations	1000000
gAverageLatency(us)	16069.64
gMinLatency(us)	765
gMaxLatency(us)	1276868
g95thPercentileLatency(ms)	28
g99thPercentileLatency(ms)	58

• 关闭Compaction读性能统计如下：

RunTime(ms)	86075
Throughput(ops/sec)	11617.78
Operations	1000000
AverageLatency(us)	8531.47
MinLatency(us)	376
MaxLatency(us)	251596
95thPercentileLatency(ms)	15
99thPercentileLatency(ms)	31

上面的数字并不好看，比SizeTiered难看多了。原因是什么呢，即使关闭Compaction操作，性能，也没有达到热启动的SizeTiered的OPS。主要原因有二：

• compaction的速度：Leveled只有一个线程在跑，现在数据量比较小，compaction没有SizeTieredcompaction快。
• 重复数据的分布。

第一个原因，在数据量比较大的时候，就不再是缺点，反而是优势，从这可以得出一点，LeveledCompaction适合更大量的数据。第二个原因，由于我采用的是YCSB做的测试，数据分布随机不可控个，而且这部分我没有看过源码，从数据推断，数据重复的不少，当重复的比较多的时候，L0的文件也很多的时候，读sstable文件的数量就比较多。性能影响比较严重。 我在HDD上也测试过这两个Compaction的比较，总数据量为1.2T，Leveled读性能是要高20%-30%的。但是在SSD上，这个比例会适当降低，根据不同的应用场景。结合上面的数据，就得到Leveled的适用场景：

• 数据量比较大
• 磁盘空间比较紧张
• 更新周期进行。（一定不能频繁进行）

SizeTiered适用场景：

• 数据量相对小
• 磁盘空间不是问题
• 几乎不更新，或者更新非常频繁发生。

上述测试数据都是用YCSB测试的，与真实数据还是相差不少。以后会进行真实数据的测试。

转载于:https://www.cnblogs.com/sing1ee/archive/2012/05/16/2765040.html