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测试的，与真实数据还是相差不少。以后会进行真实数据的测试。
