Cassandra LeveledCompaction策略在SSD上对读性能的影响
2012-05-16 14:11
309 查看
有关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刚刚开始做:读性能统计如下:
Compaction进行到三分之一左右读性能统计如下:
Compaction进行到,L0层只占三分之一是,读性能统计如下:
关闭Compaction读性能统计如下:
上面的数字并不好看,比SizeTiered难看多了。原因是什么呢,即使关闭Compaction操作,性能,也没有达到热启动的SizeTiered的OPS。主要原因有二:
compaction的速度:Leveled只有一个线程在跑,现在数据量比较小,compaction没有SizeTieredcompaction快。
重复数据的分布。
第一个原因,在数据量比较大的时候,就不再是缺点,反而是优势,从这可以得出一点,LeveledCompaction适合更大量的数据。第二个原因,由于我采用的是YCSB做的测试,数据分布随机不可控个,而且这部分我没有看过源码,从数据推断,数据重复的不少,当重复的比较多的时候,L0的文件也很多的时候,读sstable文件的数量就比较多。性能影响比较严重。 我在HDD上也测试过这两个Compaction的比较,总数据量为1.2T,Leveled读性能是要高20%-30%的。但是在SSD上,这个比例会适当降低,根据不同的应用场景。结合上面的数据,就得到Leveled的适用场景:
数据量比较大
磁盘空间比较紧张
更新周期进行。(一定不能频繁进行)
SizeTiered适用场景:
数据量相对小
磁盘空间不是问题
几乎不更新,或者更新非常频繁发生。
上述测试数据都是用YCSB测试的,与真实数据还是相差不少。以后会进行真实数据的测试。
保证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 |
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 |
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 |
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 |
compaction的速度:Leveled只有一个线程在跑,现在数据量比较小,compaction没有SizeTieredcompaction快。
重复数据的分布。
第一个原因,在数据量比较大的时候,就不再是缺点,反而是优势,从这可以得出一点,LeveledCompaction适合更大量的数据。第二个原因,由于我采用的是YCSB做的测试,数据分布随机不可控个,而且这部分我没有看过源码,从数据推断,数据重复的不少,当重复的比较多的时候,L0的文件也很多的时候,读sstable文件的数量就比较多。性能影响比较严重。 我在HDD上也测试过这两个Compaction的比较,总数据量为1.2T,Leveled读性能是要高20%-30%的。但是在SSD上,这个比例会适当降低,根据不同的应用场景。结合上面的数据,就得到Leveled的适用场景:
数据量比较大
磁盘空间比较紧张
更新周期进行。(一定不能频繁进行)
SizeTiered适用场景:
数据量相对小
磁盘空间不是问题
几乎不更新,或者更新非常频繁发生。
上述测试数据都是用YCSB测试的,与真实数据还是相差不少。以后会进行真实数据的测试。
相关文章推荐
- Cassandra LeveledCompaction在SSD上对写性能的影响
- 一组数据:不同Compaction策略对Cassandra1.1写性能的影响
- Cassandra SizeTieredCompaction在SSD上对写性能的影响
- Cassandra SizeTierCompaction在SSD上对读的影响
- SSD深度技术解析---FTL层算法对性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- 使用cpufreq-bench评估cpufreq策略对系统性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- 厂商SSD对数据库性能影响 测试报告
- 厂商SSD对数据库性能影响测试
- SSD深度技术解析---FTL层算法对性能的影响
- Cassandra1.1.0中SizeTieredCompactionStrategy和LeveledCompactionStrategy的理解
- cassandra1.1.0中Compaction部分源代码解析——LeveledCompactionStrategy
- SSD深度技术解析---FTL层算法对性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- SSD深度技术解析---FTL层算法对性能的影响
- Cassandra Leveled Compaction源码阅读
- SSD深度技术解析---FTL层算法对性能的影响