cassandra 3.x官方文档(7)---内部原理之如何读写数据

写在前面

cassandra3.x官方文档的非官方翻译。翻译内容水平全依赖本人英文水平和对cassandra的理解。因此强烈建议阅读英文版cassandra 3.x 官方文档。此文档一半是翻译，一半是我的对cassandra的认知。尽可能将个人理解经过引用的方式标注，以示区别。另外文档翻译是项长期并有挑战的工做，若是你愿意加入cassandra git book,能够发信给我。固然你也能够加入咱们的QQ群,104822562。一块儿学习探讨cassandra.

如何写

Cassandra写的时候分好几个阶段写处理数据，从当即写一个write操做开始，到把数据写到磁盘中

• 写log到commit log

• 写数据到memtable

• 从memtable中flush数据

• 将数据存储在SSTables中的磁盘中

写Log及memtable存储

当一个写发生的时候，Cassandra将数据存储在一个内存结构中，叫memtable,而且提供了可配置

的持久化，同时也追加写操做到磁盘上的commit log中。commit log记载了每个到Cassandra 节点的写入。

这些持久化的写入永久的存活即便某个节点掉电了。memtable是一个数据分区写回的缓存。Cassandra经过key

来查找。memtables顺序写，直到达到配置的限制，而后flushed.

从memtable中Flushing数据

为了flush数据，Cassandra以memtable-sorted的顺序将数据写入到磁盘。同时也会在磁盘上建立一个分区索引，

将数据的token map到磁盘的位置。当memtable 内容超过了配置的阈值或者commitlog的空间超过了

commitlog_total_space_in_mb的值，memtable 会被放入到一个队列中，而后flush到磁盘中。这个队列能够经过

cassandra.yaml文件中memtable_heap_space_in_mb,或者memtable_offheap_space_in_mb来配置。若是待flush的

数据超过了memtable_cleanup_threshold，Cassandra会block住写操做。直到下一次flush成功。你能够手动的flush一张表，

使用nodetool flush 或者nodetool drain(flushes memtables 不须要监听跟其余节点的链接)。为了下降commit log

的恢复时间，建议的最佳实践是在从新启动节点以前，flush memtable.若是一个节点中止了工做，将会从节点中止前开始，将commit log

恢复到memtable中。

当数据从memtable中flush到磁盘的一个SSTable中，对应的commit log数据将会被清除。

将数据存储到磁盘中的SSTables中

Memtables 和 SSTables是根据每张表来维护的。而commit log则是表之间共用的。SSTables是不可改变的，当memtable被flushed后，

是不可以从新写入的。所以，一个分区存储着多个SSTable文件。有几个其余的SSTable 结构存在帮助读操做。

对于每个SSTable，Cassandra 建立了这些结构:

Data(Data.db)

SSTable的数据

Primary Index(Index.db)

行index的指针，指向文件中的位置

Bloom filter (Filter.db)

一种存储在内存中的结构，在访问磁盘中的SSTable以前,检查行数据是否存在memtable中

Compression Information(CompressionInfo.db)

保存未压缩的数据长度，chunk的起点和其余压缩信息。

Statistics(Statistics.db)

SSTable的内容统计数据元数据。

Digest(Digest.crc32, Digest.adler32, Digest.sha1)

保存adler32 checksum的数据文件

CRC (CRC.db)

保存没有被压缩的文件中的chunks的CRC32

SSTable Index Summary(SUMMARY.db)

存储在内存中的的分区索引的一个样例。

SSTable Table of Contents(TOC.txt)

存储SSTable TOC 中全部的组件的列表。

Secondary Index(SL_.*.db)

内置的secondary index。每一个SSTable可能存在多个SIs中。

SSTables是存储在磁盘中的文件。SSTable文件的命名从Cassandra 2.2开始后发生变化为了

缩短文件路径。变化发生在安装的时候,数据文件存储在一个数据目录中。对于每个keyspace,

一个目录的下面一个数据目录存储着一张表。例如,

/data/data/ks1/cf1-5be396077b811e3a3ab9dc4b9ac088d/la-1-big-Data.db 表明着

一个数据文件.ks1 表明着keyspace 名字为了在streaming或者bulk loading数据的时候区分

keyspace。一个十六进制的字符串，5be396077b811e3a3ab9dc4b9ac088d在这个例子中，被加到

table名字中表明着unique的table IDs.

Cassandra为每张表建立了子目录，容许你能够为每一个table建立syslink，map到一个物理驱动或者数据

磁盘中。这样能够将很是活跃的表移动到更快的媒介中，好比SSDs,得到更好的性能，同时也将表拆分到各个

挂载的存储设备中，在存储层得到更好的I/O平衡。

数据是如何维护

Cassandra 写入过程当中将数据存入到的文件叫作SSTables.SSTables 是不可更改的。Cassandra在写入或者更新时不是去覆盖已有的行，而是写入一个带有新的时间戳版本的数据到新的SSTables中。Cassandra删除操做不是去移除数据，而是将它标记为墓碑。

随着时间的推移，Cassandra可能会在不一样的SSTables中写入一行的多个版本的数据。每一个版本均可能有独立的不一样的时间戳的列集合。随着SSTables的增长，数据的分布须要收集愈来愈多的SSTables来返回一个完整的行数据。

为了保证数据库的健康性，Cassandra周期性的合并SSTables,并将老数据废弃掉。这个过程称之为合并压缩。

合并压缩

Cassandra 支持不一样类型的压缩策略，这个决定了哪些SSTables被选中作compaction，以及压缩的行在新的SSTables中如何排序。每一种策略都有本身的优点，下面的段落解释了每一种Cassandra’s compaction 策略。

尽管下面片断的开始都介绍了一个经常使用的推荐，可是有不少的影响因子使得compaction策略的选择变得很复杂。

SizeTieredCompactionStrategy(STCS)

建议用在写占比高的状况。 
当Cassandra 相同大小的SSTables数目达到一个固定的数目(默认是4),STCS 开始压缩。STCS将这些SSTables合并成一个大的SSTable。当这些大的SSTable数量增长，STCS将它们合并成更大的SSTables。在给定的时间范围内，SSTables大小变化以下图所示 

STCS 在写占比高的状况下压缩效果比较好，它将读变得慢了，由于根据大小来合并的过程不会将数据按行进行分组，这样使得某个特定行的多个版本更有可能分布在多个SSTables中。并且，STCS不会预期的回收删除的数据，由于触发压缩的是SSTable的大小，SSTables可能增加的足够快去合并和回收老数据。随着最大的SSTables 大小在增长，disk须要空间同时去存储老的SSTables和新的SSTables。在STCS压缩的过程当中可能回超过一个节点上典型大小的磁盘大小。

• 优点: 写占比高的状况压缩很好
• 劣势: 可能将过时的数据保存的好久，随着时间推移，须要的内存大小随之增长。

LeveledCompactionStrategy(LCS)

建议用在读占比高的状况。

LCS减小了STCS多操做的一些问题。这种策略是经过一系列层级来工做的。首先，memtables中数据被flush到SSTables是第一层(L0)。LCS 压缩将这些第一层的SSTables合并成更大的SSTables L1。

Leveled compaction —— 添加SSTables 

高于L1层的SSTables会被合并到一个大小大于等于sstable_size_in_md（默认值:160MB）的SSTables中。若是一个L1层的SSTable存储的一部分数据大于L2，LCS会将L2层的SSTable移动到一个更高的等级。

许多插入操做以后的Leveled compaction 

在每一个高于L0层的等级中，LCS建立相同大小的SSTables。每一层大小是上一层的10倍，所以L1层的SSTable是L0层的10倍，L2层是L0层100倍。若是L1层的压缩结果超过了10倍，超出的SSTables就会被移到L2层。

LCS压缩过程确保了从L1层开始的SSTables不会有重复的数据。对于许多读，这个过程是的Cassandra可以从一个或者二个SSTables中获取到所有的数据。实际上，90%的都可以知足从一个SSTable中获取。由于LCS不去compact L0 tables。资源敏感型的读涉及到多个L0 SSTables的状况仍是会发生。

高于L0层，LCS须要更少的磁盘空间去作压缩——通常是SSTable大小的10倍。过期的数据回收的更频繁，所以删除的数据占用磁盘空间更少的比例。然而，LCS 压缩操做使用了更多的I/O操做，增长了节点的I/O负担。对于写占比高的状况，使用这种策略的获取的报酬不值得付出的I/O操做对性能形成损失的代价。在大多数状况下，配置成LCS的表的测试代表写和压缩I/O饱和了。

注： 
当使用LCS策略bootstrapping一个新节点到集群中，Cassandra绕过了compaction操做。初始的数据被直接搬到正确的层级由于这儿没有已有的数据，所以每一层没有分片重复。获取更多的信息，查看

优点： 磁盘空间的要求容易预测。读操做的延迟更容易预测。过期的数据回收的更及时。

劣势: 更高的I/O使用影响操做延迟。

TimeWindowCompactionStrategy(TWCS)

建议用在时间序列且设置了TTL的状况。

TWCS有点相似于简单设置的DTCS。TWCS经过使用一系列的时间窗口将SSTables进行分组。在compaction阶段，TWCS在最新的时间窗口内使用STCS去压缩SSTables。在一个时间窗口的结束，TWCS将掉落在这个时间窗口的全部的SSTables压缩层一个单独的SSTable，在SSTable maximum timestamp基础上。一旦一个时间窗口的主要压缩完成了，这部分数据就不会再有进一步的压缩了。这个过程结束以后SSTable开始写入下一个时间窗口。 

如上图所示，从上午10点到上午11点，memtables flush到100MB的SSTables中。使用STCS策略将这些SSTables压缩到一个更大的SSTables中。在上午11点的时候，这些SSTables被合并到一个单独的SSTable,并且不会被TWCS再进行压缩了。在中午12点，上午11点到中午12点建立的新的SSTables被STCS进行压缩，在这个时间窗口结束的时候，TWCS压缩开始。注意在每一个TWCS时间窗口包含不一样大小的数据。

注: 能够在这里看动画解释。

TWCS配置有两个主要的属性设置

• compaction_window_unit: 时间单位，用来定义窗口大小(milliseconds,seconds,hours等等)
• compaction_window_size: 每一个窗口有多少单元(1,2,3等等)

上面配置的一个例子：compaction_window_unit = ‘minutes’,compaction_window_size = 60

优点:用做时间序列数据，为表中全部数据使用默认的TTL。比DTCS配置更简单。

劣势: 不适用于时间乱序的数据，由于SSTables不会继续作压缩，存储会没有边界的增加，因此也不适用于没有设置TTL的数据。相比较DTCS，须要更少的调优配置。

DateTieredCompactionStrategy(DTCS)

Cassandra 3.0.8/3.8 中弃用了。

DTCS相似于STCS。可是STCS压缩事基于SSTable 大小，而DTCS是基于SSTable年纪(在一个SSTable中，每一列都标记着一个写入的时间戳。)对于一个SSTable的年纪，DTCS使用SSTable中任意列中的oldest(最小的)时间戳。

配置DTCS时间戳

哪种压缩策略最好

为了实现最好的压缩策略: 
1. Review 你应用的需求 
2. 配置表使用最合适的策略 
3. 测试压缩策略

下面的问题基于有Cassandra 开发者和使用者的使用经验以及上述描述的策略。

你的表处理的是时间序列的数据吗

若是是的，你最好的选择是TWCS 或者DTCS。想要看更多的细节，参考上面的描述。

若是你的表不是局限于时间序列的数据，选择就变得更加复杂了。下面的问题可能会给你其余的考虑去作选择。

你的表处理读比写多，或者写多于读吗 
LCS 是一个好的选择，若是表处理的读是写的两倍或者更多——尤为是随机读。若是读的比重和写的比重相似。LCS对性能的影响可能不值得获取的好处。要意识到LCS可能会被一大批写很快覆盖掉。

表中的数据是否常常改变 
LCS的一个优点在于它将相关的数据都保持在小范围的SSTables中，若是你的数据是不可更改的或者不是常常作upserts.STCS能够实现相同类型的分组而不用付出LCS在性能上影响。

是否须要预测读和写等级 
LCS 保证SSTables在一个可预测的大小和数量中。例如，若是你的表读/写比例比较小，对于读，指望得到一致的服务层面的一致性，或许值得付出写性能的牺牲去确保读速率和延迟在一个可预测的等级。并且能够经过水平扩展（添加更多的节点）来克服掉写入牺牲。

表会经过一个batch操做插入数据吗 
batch 写或batch读，STCS表现的都比LCS好。batch过程形成不多或没有碎片，所以LCS的好处实现不了，batch操做能够经过LCS配置来覆盖。

系统有受限的磁盘空间吗 
LCS处理磁盘空间比STCS更高高效：除了数据自己占用的空间，须要大约10%的预留空间。STCS和DTCS须要更多，在某些状况下，差很少须要50%。

系统是否到达I/O限制 
LCS相比较DTCS 或者STCS，对I/O更加的敏感。换成LCS，可能须要引入更多的I/O来实现这种策略优点。

数据如何更新？

Cassandra将每一个新行都当作一个upsert:若是一个新行和一个已有的行有相同的primary key，Cassandra就会对这已有的行进行更新操做。

写数据时，Cassandra将每一个新行都添加到数据库中，而不去检查是否有重复的记录存在。这个方法将有可能致使相同行在数据库中有多个版本存在。想要了解更多的信息，请查看数据如何写入。

间断性的，存储在内存中的行会被冲刷到磁盘中的叫作SSTables结构文件中。在一个肯定的间隔中，Cassandra将小的SSTables compacts成大的SSTables。若是在这个过程当中，Cassandra遇到2个或更多版本的同一行数据。Cassandra只会将最新版本的数据写到新的SSTable。compaction结束后，Cassandra会删除掉原来的SSTables，以及过期的行。

大部分的Cassandra环境会将每一行的副本存在两个或多个节点上。每一个节点都独立的执行compaction。这意味着即便一个过期版本的行数据在某个节点上被删除了，可能仍然存在于其余节点上。

这就是为何Cassandra会在读操做过程当中会执行另一轮比较。当一个客户端根据一个特定的主键请求数据时，Cassandra会从一个或多个副本中产生多个版本的行数据。带有最新的时间戳的数据是惟一会被返回到客户端的数据(“最后写赢策略”)。

注：数据库操做可能只会更新一行数据的部分字段，所以有些版本的行只包括一些列，而不是所有。在写操做和compaction阶段，Cassandra从各个部分更新收集一个完整的行数据。每一列都使用最新的版本。

笔者注：

Cassandra更新数据不一样于通常数据库，不会更新原来的数据。只会追加新的数据。所以数据库中可能会有多个版本的数据，会在compaction和repair阶段去修复多个版本的行数据。以及在读阶段从多个版本的行数据中获取最新的那行数据。 
另外cassandra每行每一个字段都有一个时间戳，因此行版本都是取每列的最新版本。

数据是如何删除的

Cassandra删除数据的过程是为了提升性能，以及和Cassandra一些内置的属性是实现数据的分布，和故障容忍。

Cassandra将一个删除视为一个插入或者upsert。DELETE命令中添加的数据会被加上一个删除标记，叫作墓碑。墓碑标记走的也是Cassandra写过程，会被写到一个或多个节点的SSTables。墓碑最主要的不一样点在于:它有一个内置的过时日期/时间。在它过时的时候(更多细节在下面),墓碑会做为Cassandra’compaction的一部分过程删除掉。

在分布式系统中作删除操做

在一个多节点的集群中，Cassandra能够在2个或者更多的节点上存储一份数据的多个副本。这样能够防止数据丢失，可是会使得删除过程变得复杂。若是一个节点接收到删除，在它存在本地，节点将这个特定记录标记为墓碑，而后尝试将墓碑传递给其余包含这个记录的节点。可是若是某个存有该数据的节点在这个时间点没有应答，不可以立刻收到墓碑，所以它仍会有这些记录的删除前的版本。若是在这个节点恢复过来以前，集群中其余被标记的墓碑数据都已经被删除了，Cassandra会将恢复过来的这个节点上的这个记录做为新的数据，而且将它传送到集群的其余节点。这种类型的删除大可是仍存活下来的记录叫作zombie

为了阻止zombies从新出现，Cassandra给每一个墓碑一个grace时间段。grace时间段的目的就是给没有应答的节点时间去回复和正常处理墓碑。若是一个客户端在grace period多墓碑数据写入了一个新的更新。Cassandra会覆盖掉墓碑。若是一个客户端在grace时间段，读墓碑记录，Cassandra会无视墓碑，若是可能的话从其余副本中读取记录。

当一个无应答的节点恢复过来，Cassandra使用hinted handoff来恢复节点down期间错过的数据的更改。Cassandra不会去为墓碑数据恢复更改在它grace period期间。可是若是在grace period结束后，节点尚未恢复，Cassandra会错过删除。

当墓碑的grace period结束后，Cassandra会在compaction阶段删除墓碑。

一个墓碑的grace period是经过设置gc_grace_seconds属性来设置的。默认值是86400秒(10天)。每一个表这个属性能够单独设置。

更多关于Cassandra删除

细节：

• 墓碑数据过时的日期/时间是它建立的日期/时间加上表属性gc_grace_seconds值。

• Cassandra也支持批量插入和更新。这个过程经过会带来恢复一个记录的插入的风险，当这条记录已经被集群的其余节点移除掉了。Cassandra不会在grace period期间，为一个墓碑数据恢复批量更改。

• 在一个单节点的集群中，你能够设置gc_grace_seconds的值为0

• 为了彻底阻止zombies记录的再出现，在节点恢复过来后、以及每一个表的gc_grace_seconds，跑nodetool repair

• 若是一个表的全部记录在建立的时候设置了TTL，以及全部的都容许过时，且不能手动删除，就没有必要为这张表按期跑nodetool repair

• 若是使用了SizeTieredCompactionStrategy 或者 DateTieredCompactionStrateg，你能够经过手动开启compaction当即删除掉墓碑。 
  当心： 
  若是你强制compaction,Cassandra可能从全部的数据中建立一个很是大的SSTable。Cassandra在很长的时间段中不会再触发另一个compaction。在强制compaction期间建立的SSTable数据可能会变得很是过期在一个长的没有compaction阶段。

• Cassandra 容许你为整张表设置一个默认的_time_to_live属性。列和行都被标记为一个TTLs;可是若是一条记录超过了表级别的TTL，Cassanda会当即将它删除，而没有标记墓碑或者compaction过程。

• Cassandra支持经过DROP KEYSPACE 和 DROP TABLE当即执行删除。

indexes是如何存储和更新的

Secondary indexes是被用来过滤非primary key列的表查询。例如，一个表存储cyclist names 和ages。使用cyclist的last name做为主键，可能会有一个age字段的secondary index，使得可以容许根据年龄来查询。查询匹配非主键的列是反范式的，由于这样的查询常常会致使表连续数据切片产生。

若是一个表根据last names时存储数据，表将会分红多个parittions存储在不一样的节点上。基于last names的某个特定范围的查询，好比全部的last name 为Matthews名字的cyclists，会致使表的顺序查询，可是基于age的查询，好比哪些cyclists 28岁，会致使全部节点都会去查一个值。不是primary keys在数据存储时是乱序的。这种根据非主键的查询会致使全partitions的扫描。扫描全部的partitions会致使很是高昂的读延迟，是不被容许的。

Secondary indexes 能够为表的某一个列构建。这些indexes经过一个后台进程都存储在每一个节点的本地的一个隐藏表中。若是一个secondary index被用在一个查询中并且没有限制一个特定的partition key,这样的query一样会有高昂的查询延迟，由于全部的节点都得查询。带这些参数的查询只容许查询选项为 ALLOW FILTERING。这个选项不适用生产环境。若是一个查询包括一个partiton key的条件和secondary index列条件，这样的查询才会成功，由于会被转换为单个节点的分区。

然而这种技术并不能保证零麻烦的索引，所以须要知道何时用/不用index。像上面描述的例子，age列上的index可使用，可是更好的解决方案是建立一个物化视图或者额外的一张根据age排序的表。

和关系型数据同样，维护index须要处理时间和资源，所以没必要要的indexes应该要避免。当一个列被更新的时候，它的index一样须要更新。若是当一个老的列值还存在于memtable中，这个常常发生在重复的更新某些行，Cassandra会将对应的过期的index删除;不然老的index entry仍然会被compaction清除掉。若是读操做在compaction清理以前看到一个过期的index entry，reader线程会设置它无效。

注:

在Casssandra Secondary Index介绍一文中有详细介绍过Secondary Indx

数据是如何读的

为了知足读，Cassandra必需要从存活的memtable和潜在的多个SSTables中联合查询结果。

Cassandra在读的过程当中为了找到数据存储在何处，须要在好几个阶段处理数据。从memtables开始，到SSTables结束。

• 检查 memtable
• 若是enabled了,检查row cache
• 检查Bloom filter
• 若是enable了,检查partition key 缓存
• 若是在partition key缓存中找到了partition key,直接去compression offset mao中，若是没有，检查 partition summary
• 根据compression offset map找到数据位置
• 从磁盘的SSTable中取出数据

读请求流程图 

行缓存和键缓存请求流程图 

MemTable

若是memtable有目标分区数据，这个数据会被读出来而且和从SSTables中读出来的数据进行合并。SSTable的数据访问以下面所示的步骤。

Row Cache

一般意义上，对于任何数据库，当读的大部分数据都在内存中读取的时候是很是快的。操做系统的页缓存是最有利提高性能的，通过行缓存对于读占比高的应用有必定性能提高，如读操做占95%。Row Cache对于写占比高的系统是禁用的。若是开启了row cache.就会将一部分存储在磁盘的SSTables数据存储在了内存中。在Cassandra2.2+，它们被存储在堆外内存，使用全新的实现避免形成垃圾回收对JVM形成压力。存在在row cache的子集数据能够在特定的一段时间内配置必定大小的内存。row cache使用LRU(least-recently-userd)进行回收在申请内存，当cache满的时候。

row cache的大小是能够配置的，值是能够存多少行。配置缓存的行数是一个很是有用的功能，使得相似’最后的10条’查询能够很快。若是row cache 开启了。目标的数据就会从row cache中读取，潜在的节省了对磁盘数据的两次检索。存储在row cache中的数据是SSTables中频繁被访问的数据。存储到row cache中后，数据就能够被后续的查询访问。row cache不是写更新。若是写某行了，这行的缓存就会失效，而且不会被继续缓存，直到这行被读到。相似的，若是一个partition更新了，整个partition的cache都会被移除，但目标的数据在row cache中找不到，就会去检查Bloom filter。

Bloom Filter

首先，Cassandra检查Bloom filter去发现哪一个SSTables中有可能有请求的分区数据。Bloom filter是存储在堆外内存。每一个SSTable都有一个关联的Bloom filter。一个Bloom filter能够创建一个SSTable没有包含的特定的分区数据。一样也能够找到分区数据存在SSTable中的可能性。它能够加速查找partition key的查找过程。然而，由于Bloom filter是一个几率函数，因此可能会获得错误的结果，并非全部的SSTables均可以被Bloom filter识别出是否有数据。若是Bloom filter不可以查找到SSTable，Cassandra会检查partition key cache.

Bloom filter 大小增加很适宜，每10亿数据1~2GB。在极端状况下，能够一个分区一行。均可以很轻松的将数十亿的entries存储在单个机器上。Bloom filter是能够调节的，若是你愿意用内存来换取性能。

Partition Key Cache

partition key 缓存若是开启了，将partition index存储在堆外内存。key cache使用一小块可配置大小的内存。在读的过程当中，每一个”hit”保存一个检索。若是在key cache中找到了partition key。就直接到compression offset map中招对应的块。partition key cache热启动后工做的更好，相比较冷启动，有很大的性能提高。若是一个节点上的内存很是受限制，可能的话，须要限制保存在key cache中的partition key数目。若是一个在key cache中没有找到partition key。就会去partition summary中去找。

partition key cache 大小是能够配置的，意义就是存储在key cache中的partition keys数目。

Partition Summary

partition summary 是存储在堆外内存的结构，存储一些partition index的样本。若是一个partition index包含全部的partition keys。鉴于一个partition summary从每X个keys中取样，而后将每X个key map到index 文件中。例如，若是一个partition summary设置了20keys进行取样。它就会存储SSTable file开始的一个key,20th 个key，以此类推。尽管并不知道partition key的具体位置，partition summary能够缩短找到partition 数据位置。当找到了partition key值可能的范围后，就会去找partition index。

经过配置取样频率，你能够用内存来换取性能，当partition summary包含的数据越多，使用的内存越多。能够经过表定义的index interval属性来改变样本频率。固定大小的内存能够经过index_summary_capacity_in_mb属性来设置，默认是堆大小的5%。

Partition Index

partition index驻扎在磁盘中，索引全部partition keys和偏移量的映射。若是partition summary 已经查到partition keys的范围，如今的检索就是根据这个范围值来检索目标partition key。须要进行单次检索和顺序读。根据找到的信息。而后去compression offset map中去找磁盘中有这个数据的块。若是partition index必需要被检索，则须要检索两次磁盘去找到目标数据。

Compression offset map

compression offset map存储磁盘数据准确位置的指针。存储在堆外内存，能够被partition key cache或者partition index访问。一旦compression offset map识别出来磁盘中的数据位置，就会从正确的SStable(s)中取出数据。查询就会收到结果集。

注: 在一个分区里，全部的行查询代价并非一致的。在一个分区的开始（第一行，根据clustering key定义）想对来讲代价更小，应为没有必要执行partition-level的index。

compression offset map 每TB增加量为1~3GB。压缩的数据越多，压缩块的数量越多，压缩偏移表就会越大。Compression 默认是开启的，即便压缩过程当中会消耗CPU资源。开启compression使得页缓存更加的高效,一般来讲是值得的。

注:

cassandra读取的数据是memtable中的数据和SStables中数据的合并结果。读取SSTables中的数据就是查找到具体的哪些的SSTables以及数据在这些SSTables中的偏移量(SSTables是按主键排序后的数据块)。首先若是row cache enable了话，会检测缓存。缓存命中直接返回数据。没有查找Bloom filter，查找可能的SSTable。而后有一层Partition key cache，找partition key的位置。若是有根据找到的partition去压缩偏移量映射表找具体的数据块。若是缓存没有，则要通过Partition summary,Partition index去找partition key。而后通过压缩偏移量映射表找具体的数据块。

读是如何影响写的

思考集群中写操做会对读操做有什么影响是很是重要的。compaction 策略的类型使得数据的处理是可配置的，同时会影响读的性能。使用SizeTieredCompactionStrategy或者DateTieredCompactionStrategy可能会在行被频繁更新的时候形成数据碎片化。LeveledCompactionStrategy(LCS)在这种状况下是被设计用来阻止数据碎片化的。