Cassandra 3.x官方文档_数据如何读取?

为了满足读，Cassandra必须结合活跃的memtable和潜在的多个SSTables的结果。Cassandra在读路径上要经过多个阶段来处理数据，来发现数据存储在哪里，从memtable开始，到SSTables结束。

 

•检查memtable

•如果启用了，检查行缓存

•检查布隆过滤器

•如果启用了，检查分区键缓存

•如果一个分区键在分区键缓存里找到了，就直接去compression偏移映射里去，或者如果没有找到，检查分区摘要。如果检查了分区摘要，则访问分区索引。

•使用compression偏移映射定位磁盘上的数据

•获取磁盘上SSTable的数据

 

图：读取请求流

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

Memtable

如果memtable有想要的分区数据，数据会被读取，然后和SSTables中的数据一起合并。SSTable的数据被访问的步骤如下所示：

 

行缓存

对于任何典型的数据库，当最需要的数据存入内存时读取时最快的。操作系统页面缓存是提高性能最好的方式，即使行缓存在读操作占负载95%的时候可以提高一些读密集的操作中提高一些改进。行缓存是写密集操作的禁忌。行缓存如果启用，会把存在在磁盘的SSTables上的一些分区数据存储在内存上。在Cassandra2.2和后来的版本中，它完全存储在堆外内存上，实现了一种可以减轻JVM上的垃圾回收器的压力。存储在行缓存中的子集使用了在指定的一段时间里可配置的内存大小。行缓存在缓存满的时候使用LRU(最近最少使用)策略来回收内存。

 

When the desiredpartition data is not found in the row cache, then the Bloom filter ischecked.

行缓存大小是可配置的，比如要存储的行数。配置要存储的行数是一个非常有用的功能，可以使“最近10个条目”的查询非常快。如果行缓存启用，所需要的分区数据从行缓存读取，潜在的节省了从磁盘查找数据的步骤。存储在行缓存里的行是被频繁访问的行，当他们被从SSTables访问的时候被合并然后存储在行缓存里。存储完后，这些数据可以用做接下来的查询。行缓存是非写通过的。如果该行有一条写操作，这一行的缓存会失效，不会被再次缓存，直到这一行被读取。类似的，如果一个分区更新了，整个分区会从缓存中移除。当需要的分区数据在行缓存中未找到，就会检查布隆过滤器。

 

 

布隆过滤器

首先，Cassandra检查布隆过滤器来发现哪一个SSTables可能有请求的分区数据。布隆过滤器存储在堆外内存中。每一个SSTable都有一个相关的布隆过滤器。布隆过滤器可以确定一个SSTable没有某一个分区数据。布隆过滤器也可以找到分区数据可能存储的SSTable。通过缩小秘钥池，加快了分区键查找的过程。然而，因为布隆过滤器是一个概率函数，它可能导致错误的结果。并不是所有布隆过滤器识别的SSTables都有数据。如果布隆过滤器不能排除SSTable，Cassandra会检查分区键缓存。

 

布隆过滤器每十亿分区增长大概1-2GB。以极端情况下，你可以有每行一个分区，这样你在每个机器上很容易有数十亿条目。如果你想用内存换性能，布隆过滤器是可调优的。

 

分区键缓存

如果启用了，分区键缓存会把分区索引缓存存储在堆外内存中。键缓存使用一个小的，可配置大小的内存，而且读操作的每一次的“命中”都会保存一条。如果一个分区键在键缓存里找到了，就可以直接定位到compression偏移映射中找到磁盘中拥有该数据的压缩块。分区键缓存方法更好的地方是，一旦热起来，就会大大超过冷启动读的性能。如果一个节点上的内存是非常有限的，可以限制保存在键缓存上的分区键的数量。如果在键缓存上找不到分区键，可以搜索分区摘要。

 

分区键缓存大小是可配置的，因为分区键的数量也保存在键缓存中。

 

分区摘要

分区摘要是一种在堆外内存的结构，它存储了分区索引的采样。一个分区索引包含所有分区键，而一个分区摘要采样每一个X键，然后把每一个X键的位置映射到索引文件的位置上。例如，如果分区摘要设置成每20秒采样一次，它会保存第一个键的位置作为SSTable文件的开始。当不能准确知道分区键的位置时，分区摘要缩短扫描分区数据位置的时间。在查询分区键的值得可能分布以后，会搜索分区索引。

 

通过配置采样的频率，你可以用内存来换取性能，分区摘要的比率越高，就会用越多的内存。使用表定义里的index interval修改采样的频率。使用index_summary_capacity_in_mb属性配置一个固定的内存，默认是堆大小的5%。

 

分区索引

分区索引驻留在磁盘上，存储所有分区键偏移量映射的索引。如果分区摘要已经检查了一系列的分区键，则搜索将传递给分区索引来查找所需要的分区键的位置。执行传入范围内的列的单个查找和顺序读取。利用已经找到的信息，分区索引会去compression偏移映射去寻找拥有数据的压缩块。如果分区索引必须被搜索，那么要找到所需要的数据需要两次磁盘查找。。

 

 

Compression偏移映射

Compression偏移映射存储了磁盘上所需要的分区数据的具体位置的指针。它保存在堆外内存上，要么是分区键缓存访问，要么是分区索引访问。一旦compression偏移映射确认了磁盘的位置，所需要的compression分区数据就可以从正确的SSTable上面获取。查询接收结果集。

 

注：在一个分区内，不是所有行的查询代价是一样的。分区的开头查询代价更小，因为没有必要咨询分区级别索引。

 

Compression偏移索引每TB压缩数据增长大概1-3GB。你压缩的数据越多，压缩块的数量就越多，compression偏移表就越大。Compression默认是禁用的，即使通过compression偏移映射消耗CPU资源。启用compression可以使页缓存更有效率。

 

写模式如何影响读取？

A brief descriptionabout how write patterns affect reads.

在集群中，考虑写操作会如何影响读操作是非常重要的。Cassandra的执行compaction策略是可配置的，而且显著的影响了读性能。使用SizeTieredCompactionStrategy 或者DateTieredCompactionStrategy，当行频繁更新的时候，可能导致数据的碎片化。在这种情况下，LeveledCompactionStrategy设计成防止碎片化。