Cassandra新特性:分层压缩

标签: Cassandra Compaction LevelDB 压缩 | 发表时间:2011-10-17 16:59 | 作者:nosqlfan gnawux
出处:http://blog.nosqlfan.com

Cassandra的数据模型借鉴自Google的BigData模型,简单来说就是将写操作放在一个内存块中,当内存块大小达到一定大小时,将内存中的数据排序后写成一个sstable文件,而这种方式会有一些问题,而前段时间Google的Chromium团队开发的一个开源的key-value存储以其分层压缩机制给了大家一种新的思路,Cassandra也适时的将这种思路引入到Cassandra中,也就是今天我们要介绍的Cassandra的分层压缩。

目前的压缩机制:Tiered Compaction

在讲分层压缩之前,我们先来看一下Cassandra目前的数据存储模型和数据压缩机制。

像我们上面说的一样,Cassandra在内存数据达到一定大小时,会将数据排序写入磁盘生成一个sstable文件块,当第一级的sstable数目达到四个时,由于这四个sstable相当于是按时间划分的一段时间的数据快照,所以这四个块中会有一些相同的数据。我们将这四个sstable会进行合并压缩,就可憎减小空间。具体过程如下图所未:

上图绿色块就表示一个sstable,当第一级的sstable达到四个,就会合并成一个新的第二级的sstable。当然,当第二级的sstable也达到四个,就会再进行合并生成第三级的sstable,以此类推。如果下图所未,当一二三四级sstable都已经有三个,可能这个合并就会一直进行下去。

由于sstable之间可能有重复的数据,也就是同一个数据的不同版本可能存在在多个sstable中,所以上面的方式在更新比较频繁的系统中,可能会有下面一些问题:

  • 第一是性能的影响,由于一条记录可能存在在多个sstable中,最BT的情况下可能某一条记录会存在在所有sstable中,所以具体需要合并多个少sstable才能保证一条记录在所有sstable中只存了一次就变得不太确定了。
  • 这种方式在存储空间上也比较浪费,因为一个被删除的记录可能的老版本可能会一直存在在一些老的sstable中,直到进行一次完整的合并才行。这对于一个经常会有删除操作的系统来说会造成空间的极大浪费。
  • 在不怎么删除的系统上,也会造成一些空间的浪费,最坏的情况下,如果一条记录都没有重复,那么合并操作实际上完全是浪费时间,合并后的数据大小和合并前相比不会变,但是合并操作本身会需要和当前数据集一样大的空间成本。

新的压缩机制:Leveled Compaction

新的压缩机制借鉴自LevelDB,这种机制最大的特点在于其同一层的各个sstable之间不会有重复的数据。所以在某一层和它上一层的数据块进行合并时,可以明确的知道某个key值处在哪个数据块中,可以一个数据块一个数据块的合并,合并后生成新块就丢掉老块。不用一直到所有合并完成后才能删除老的块。

另外,新的分层式压缩方式将数据分成条个层,最底层的叫L0,其上分别是L1,L2….,每一层的数据大小是其上的那一层数据最大大小的10倍,其中最底层L0的大小为5M

如下图所未,当浅绿色的L0块生成时,它会马上和L1层的数据进行合并,并生成新的L1块(蓝色块),当L1的块越来越多,大于这一层的最大大小时,这些块又会和L2层的数据进行合并并生新的L2层的块(紫色块)

可以这样理解,层级越小的块,其保存的数据越少,也越新,比如L0层保存的就是最新的数据版本,但是其只会保存5M数据,其上的L1层会保存50M数据,但是并不是最新的。当一个系统运行的时间足够长,那么其数据结构可能会如下图所未:

这种方式的优点是同一层的块之间没有重复数据,带来的好处就是在合并操作的时候,并不需要扫描一层中的所有数据块。合并的开销变小了。具体能够保证以下一些优点:

  • 可以保证90%的读操作只需要对一个sstable进行随机读操作。而最坏情况下,也能保证读操作最大只会等于层数,如果10T数据的话,也只有七层,只需要七次随机读操作。
  • 在空间利用上,可以保证最多只有10%的空间会浪费在无用数据上。
  • 在压缩合并操作的开销上,也最多只会使用10倍于sstable大小的空间。

你可以通过在创建Column Family时指定compaction_strategy参数为LeveledCompactionStrategy来使用新的分层压缩策略。

当然,这种策略也不是万能的,对于一个更新操作和删除操作比较多的系统,使用分层压缩是比较合适的。因为这种系统会产生同一份数据的多个版本。但是由于这种压缩会在压缩中进行更多的IO操作,所以如果是一个主要是insert操作的系统,建议不要使用分层压缩方法。

来源:www.datastax.com

相关文章:

Cassandra1.0改进:数据压缩

Cassandra运维之道

图形化理解 HBase 数据写操作、压缩操作过程

Cassandra SF 会议精华集锦

基于Flume和Cassandra的实时日志处理
无觅

相关 [cassandra 压缩] 推荐:

Cassandra新特性:分层压缩

- gnawux - NoSQLFan
目前的压缩机制:Tiered Compaction. 在讲分层压缩之前,我们先来看一下Cassandra目前的数据存储模型和数据压缩机制. 像我们上面说的一样,Cassandra在内存数据达到一定大小时,会将数据排序写入磁盘生成一个sstable文件块,当第一级的sstable数目达到四个时,由于这四个sstable相当于是按时间划分的一段时间的数据快照,所以这四个块中会有一些相同的数据.

Cassandra代替Redis?

- - Tim[后端技术]
最近用Cassandra的又逐渐多了,除了之前的360案例,在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例. 而这篇 百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例. 考虑到到目前仍然有不少网友在讨论Redis的用法问题,Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题,因此简单谈下相关区别.

Cassandra on DC/OS

- - 灰狐博客
Apache Cassandra 是一个强大的开源分布式NoSQL数据库,高度的可伸展性. 基于DC/OS构建其分布式集群是个非常值得采纳的方法,其基本思路是:. 把Cassandra放到Docker里,然后由DC/OS调度Cassandra容器集群运行、管理. Mesos 的 persistence primitives 是一个新的强大的工具,它使得更多的有状态应用可以运行在 Mesos 上.

Cassandra 1.1的缓存策略

- - NoSQLFan
从0.5和0.6版本开始, Cassandra就提供了主键 缓存和行缓存. 在1.1 版本中,Cassandra的核心开发团队重新对缓存策略进行了设计和实现,以提供配置更简单但同时又更高效的缓存效果. 为什么要将缓存集成到数据库内部. 实际上,缓存既可以储存到数据库内部,也可以是外部的独立缓存层.

MariaDB的Cassandra存储引擎

- - InfoQ cn
MariaDB已经宣布了Cassandra存储引擎的一个预览版本. 该插件允许MariaDB通过标准SQL语法使用Cassandra集群. MariaDB并不是第一款为Cassandra提供SQL支持的产品. 例如,Simba提供了一个 Cassandra ODBC驱动,可用于大多数的ODBC兼容工具.

[转][转]Cassandra、MongoDB、CouchDB、Redis、Riak、HBase比较

- - heiyeluren的blog(黑夜路人的开源世界)
来源: http://blog.nosqlfan.com/html/1845.html. 在NoSQL如日中天的今天,各种NoSQL产品可谓百花齐放,但每一个产品都有自己的特点,有长处也有不适合的场景. 本文对 Cassandra,  Mongodb,  CouchDB,  Redis,  Riak 以及  HBase 进行了多方面的特点分析,希望看完此文的您能够对这些NoSQL产品的特性有所了解.

Cassandra HBase和MongoDb性能比较

- - 数据库 - ITeye博客
这是一篇基于亚马逊云平台上对三个主流的. NoSQL数据库性能比较,在读写两个操作不同的组合情况下性能表现不同. 横坐标是吞吐量,纵坐标是延迟,这是一对矛盾,吞吐量越大,延迟越低,代表越好. 纯粹插入,Cassandra领先,见下图:. 2.WorkloadA: 读修改操作各占一半情况下的修改性能:MongoDB明显延迟增加,落败:.

Dynamo和Cassandra海量存储基础

- - 忘我的追寻
提到这两个系统,他们在核心思路上是非常类似的,但有一些细节性的东西又有所偏重,在分布式系统中也算是独树一帜了,很有代表性的一个系列,这些不一致的地方,最明显的地方就在于一致性上. 可见,哪怕是从追求简单为上的工程化实现来说,各种不同的方式实现一致性也都有很大的不同,不过他们也有一些共性和一些独树一帜的概念,下面来做一下分别解说.

Cassandra性能优化的一些小tips

- - 邓的博客
最近,datastax的开发博客上发了一篇文章 How not to benchmark Cassandra (不要这样压测Cassandra),文章说了压测Cassandra时应该避免的几个地方. 其实,对于正常使用情况下提升Cassandra的性能,避免某些瓶颈,里面的有些tips还是非常有用的,所以摘录出来,本文并非原文翻译,而是选择了其中几点,并总结了自己优化Cassandra的一些实践,如果有需要,请直接查看链接.

Cassandra和HBase主要设计思路对比

- 三十不归 - 淘宝JAVA中间件团队博客
Cassandra HBase 一致性 Quorum NRW策略 通过Gossip协议同步Merkle Tree,维护集群节点间的数据一致性. 单节点,无复制,强一致性 可用性 1,基于Consistent Hash相邻节点复制数据,数据存在于多个节点,无单点故障. 2,某节点宕机,hash到该节点的新数据自动路由到下一节点做 hinted handoff,源节点恢复后,推送回源节点.