求知 文章 文库 Lib 视频 iProcess 课程 角色 咨询 工具 讲座 Modeler   Code  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
使用Leveled Compaction的时机
 

作者:nosqlfan ,发布于2012-9-3

 

Leveled Compaction策略是1.0版本提出的,主要为了在某些场合克服SizeTiered Compaction策略的缺点。不过很不幸,什么时机选择适用Leveled Compaction策略,并不是那么明朗。下面的内容会给出一些选择Compaction策略的指导建议。

SizeTiered Compaction策略与Leveled Compaction策略的不同

Leveled Compaction有一个基本的特征,可以帮助开发人员确定它是否适合:为了保障,一行数据不会分布在更多的sstable中,在Compaction过程进行的时候,Leveled Compaction策略需要更多的I/O操作。但是SizeTiered Compaction无法提供这个保障,尽管一行数据可能分布的最多sstable数量为10左右。【Leveled Compaction能够保证一行数据不会出现在太多的sstable中,这个大家都是知道的,具体,如果单机有10T数据,最多只会出现在7个sstable中。SizeTiered Compaction没有这个保证,原文中说的10个左右,也是有单机数据量的限制的,如果数据量再多,比如达到单机1T左右,可能会有三分之一的数据是重复的】。

当使用SizeTiered Compaction的时候,频繁的更新某一行,会出现如下的分布情况。

上图中,灰色的块代表sstable文件,蓝色的线代表统一行数据。

当要读取这一行被频繁更新的数据,代价是非常大的,几乎要读每一个sstable文件。seek磁盘次数太多,性能严重下降。

但是,当使用LeveledCompaction的时候,情况就完全不一样了。

使用Leveled Compaction,当你需要读取一行数据,90%的时间是只需要读一个sstable文件。我们假设N是要读取完整一行数据所必须读的sstable数量,读取N个不同文件的概率会随着N的增大,指数级的降低。概率分布如下:

如果你熟悉一点数学,会算出,当读取某一随机行的时候,期望平均的sstable数量是1.111.这个和使用SizeTiered的情况相比,要小很多。当然,如果你停止更新这一行数据,SizeTiered Compaction会最终把多份合并到一个sstable文件中。但是如果你持续更新,那同一行数据,还是会分布在多个sstable中的。但是使用Leveled Compaction,即使持续更新某一行,也能够保证,要读取的sstable数量,远少于SizeTiered Compaction。

什么时候Leveled Compaction是一个好的选择

对读延迟高度敏感

除了在通常意义下,Leveled Compaction会降低读延迟之外,Leveled Compaction也会降低读过程中的变数【让读延迟更加可控】。如果你的应用在99%的时间里,对读延迟都有严格的要求,那么Leveled Compaction必须是唯一满足这些要求的选择,因为它保证了读取sstable数量的上限,使得事情可控。

高读写比例

如果你的应用中,读写比例为至少2:1,Leveled Compaction可以节省磁盘I/O,尽管Compaction操作会消耗多一些I/O。尤其是当读非常随机的时候,而不是集中在某一部分热数据的时候,更会节省磁盘I/O。

数据频繁更新

无论是处理行数据不断被覆盖重写的情况,还是新的column不断的加入的情况,使用SizeTiered Compaction都会使得数据分布在多个sstable文件中。但是Leveled Compaction可以保证sstable文件数量的上线,即使非常频繁的更新。

如果,你更新的一行数据具有很多列,定期的将所有列都切换到新的一行,会再一定程度上降低SizeTiered Compaction的影响,但是还是远不如Leveled Compaction。如果,你的数据中,只有很少的column,Cassandra1.1以后,提供了一个新的优化,使得SizeTiered Compaction可以更多的进行合并(但是并没有回收磁盘空间)。

在多列的数据中删除某一column或者某一column数据过期

如果你在具有很多column的行数据中,设置了TTLs(过期时间),当过期时间来到的时候,会有很多过期的数据。同样,如果采用column来实现队列机制,当不断删除column的时候,也会在每一行产生很多过期数据。

过期的column和普通的column是一样的,会让读操作seek更多的sstable。如果一行中非过期数据很好,那么读的时候,就会浪费很多字段在读没有用的column上。

值得注意的是,Cassandra1.2将会在SizeTiered Compaction下改进这个,尝试频繁的移除过期数据,这个会在一定程度上,减少读取sstable的数量。

什么时候Leveled Compaction可能不是一个好的选择

磁盘不能够承受如此多的Compaction I/O操作

如果你的集群,I/O压力已经很大,这时再切换到Leveled Compaction,只会使得问题更加糟糕。Compaction操作需要更多的I/O操作是Leveled Compaction的最主要的缺点。所以在使用之前,要检查是否I/O已经压力非常大。

写压力大的场景

Leveled Compaction操作很难处理写多,读少的场景,Compaction的速度远远更不上写的速度的时候,Leveled Compaction就不是一个好的选择。因为这个时候,读带来的好处,已经不明显,不需要了。

没有更新

如果所有的数据都是只写一次,没有更新,不会存在多个sstable中,那么使用SizeTiered Compaction即可。因为已经不需要从多个文件中读取。

关于Leveled Compaction的其他建议

写采样(Write Sampling)

很难提前知道,在将Compaction策略切换到Leveled Compaction策略的时候,你的节点的Compaction操作是否能否跟得上。最好的办法,是采用live traffic sampling机制(后文会进行详解!)。如果是在生产环境中适用个,强烈建议使用这种机制。

SSD和可以载入内存的数据

SizeTiered Compaction和Leveled Compaction在SSD下,都有良好的表现。但是Leveled Compaction还是要突出一些,这不仅仅体现在Leveled Compaction可以减少读次数。而且Leveled Compaction可以降低CPU和内存的使用,在Compaction的过程中。

需要更少的磁盘空间

在Compaction的过程中个,SizeTiered Compaction需要最大的Column Family的大小的一倍空闲空间,而Leveled Compaction只需要10*sstable_size_in_mb的空闲空间。但是即便如此,也要流出更多的磁盘空间给其他操作,如:accommodate streaming, repair和snapshots等,这些操作可能很容易的就用到10G以上的空间。更进一步,磁盘会在空间使用80-90%之后,性能下降。所以,不要把磁盘写得满满的。

除了在Compaction过程中,Leveled Compaction会需要很少的空闲空间,整体上而言,Leveled Compaction需要的空间也比SizeTiered Compaction要少。


相关文章 相关文档 相关视频



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优

 
分享到
 
 
     


MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


GE 区块链技术与实现培训
航天科工某子公司 Nodejs高级应用开发
中盛益华 卓越管理者必须具备的五项能力
某信息技术公司 Python培训
某博彩IT系统厂商 易用性测试与评估
中国邮储银行 测试成熟度模型集成(TMMI)
中物院 产品经理与产品管理
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号