[译]Cassandra的数据读写与压缩

本文翻译主要来自Datastax的cassandra1.2文档。http://www.datastax.com/documentation/cassandra/1.2/index.html。此外还有一些来自于相关官方博客。

该翻译做为ISE实验室大数据组Laud的学习材料的一部分，适合对Cassandra已经有必定了解的读者。

未经本人许可，请勿转载。

---

简述 数据模型

一、不是sql（没有事务、没有join），可是不只仅是kv

二、来自于Google BigTable的灵感。

三、基于列族的。

例子：

还有二级索引、分布式counter、复合列等等

---

Cassandra Storage Engine

目标：最小化随机IO。

一次写入的流程：

 

写入的特色是：

没有读取、没有seek

只有顺序io

sstable再也不改变：很容易备份

一次读的流程：

 

压缩

目的：减小sstable数量

合并多个sstable的顺序

顺序IO

 

SStable的样子：

 

再说压缩：

Cassandra中，讲新的列写入新的sstable中，那么压缩就是为了将多个sstable合并成一个。

Figure 1: adding sstables with size tiered compaction

所以，一段时间后，会有一行的许多版本会存在于多个不一样的sstable中。这些版本中的每个均可能有不一样的列集合。若是sstable就这么积攒下去，读一行数据就须要屡次定位到多个文件中去。

所以须要合并，合并也是高性能的，不须要随机IO，由于行也都被有序的存储在了各自的sstable中（基于primary key的顺序）。

Figure 2: sstables under size-tiered compaction after many inserts

cassnadra的大小分层压缩策略跟bigtable论文中的很像：当到达足够数量的sstable（默认4个）的时候，就进行合并。

图1中，一个绿色格子就表明一个sstable，一行就表明一次压缩合并。一旦sstable到了4个，就合并在一块儿。图2展现了一段时间以后的层次结构，第一层的sstable合并成第二层，第二层的会合并成第三层…

 

在频繁更新的任务中，会出现三个问题：

一、性能会不一致，由于不能确保一行到底跨越了多少个sstable。最糟糕的例子是，咱们可能在每一个sstable都有某一行的某些列。

二、由于没法肯定到底过期的列会被合并的多块，所以可能会浪费大量的空间，尤为是不少delete的时候。

三、Space can also be a problem as sstables grow larger from repeated compactions, since an obsolete sstable cannot be removed until the merged sstable is completely written.  In the worst case of a single set of large sstable with no obsolete rows to remove, Cassandra would need 100% as much free space as is used by the sstables being compacted, into which to write the merged one.

Cassandra1.0以后引进了Leveled compaction策略，这是基于Chromium团队的levelDB的

Leveled Compaction （译者注：翻译的不是很懂）

leveled compation建立固定大小的sstable（默认5MB）,他们组成了“levels”。在每一层里面，sstable们能确保不重叠。每一层都比前一层大10倍。

Figure 3: adding sstables under leveled compaction

图3中，新的sstable首先加入第一层level， L0.而后马上合并成sstable到L1，（蓝色的），当L1满了，就合并成L2（紫色的）。Subsequent sstables generated in L1 will be compacted with the sstables in L2 with which they overlap. As more data is added, leveled compaction results in a situation like the one shown in figure 4.

Figure 4: sstables under leveled compaction after many inserts

这种方式能解决上述问题：

一、这种合并压缩能确保90%的读取都能从单个sstable中获取（假设行的大小统一）。最坏的状况是读取层的数量次。好比 10T的数据会读取7个。

二、之多10%的空间会由于过期行而浪费。

三、在compact时只须要有10*sstable大小的空间被临时使用。

 

使用：经过在建立或者更新表结构时 加入：compaction_strategy option set to LeveledCompactionStrategy.（更新也是后台的，因此对于已经存在的表，修改compact类型不影响读写）

 

因为leveled compaction要确保上面的问题，他比size-tiered compation 要花费大概两倍的io。对于写入为主的负载，这种额外的io并不会由于上面的好处带来不少收益，由于没有多少行的旧版本涉及。

设置的一些细节：Leveled compaction ignores the concurrent_compactors setting. Concurrent compaction is designed to avoid tiered compaction’s problem of a backlog of small compaction sets becoming blocked temporarily while the compaction system is busy with a large set. Leveled compaction does not have this problem, since all compaction sets are roughly the same size. Leveled compaction does honor the multithreaded_compaction setting, which allows using one thread per sstable to speed up compaction. However, most compaction tuning will still involve usingcompaction_throughput_mb_per_sec (default: 16) to throttle compaction back.

何时使用leveled compation呢：英文版，中文版

---

数据管理

为了管理和访问数据，那么就必须知道Cassandra如何读写数据的，hinted handoff特征，与ACID的一致和不一致的地方。在Cassandra中，一致性指的是如何更新和同步一行的数据到他的全部副本上。In Cassandra, consistency refers to how up-to-date and synchronized a row of data is on all of its replicas.

to be continue…