电子发烧友App
数据的读取
Cassandra 的写的性能要好于读的性能，为何写的性能要比读好很多呢？原因是，Cassandra 的设计原则就是充分让写的速度更快、更方便而牺牲了读的性能。事实也的确如此，仅仅看 Cassandra 的数据的存储形式就能发现，首先是写到 Memtable 中，然后将 Memtable 中数据刷到磁盘中，而且都是顺序保存的不检查数据的唯一性，而且是只写不删（删除规则在后面介绍），最后才将顺序结构的多个 SSTable 文件合并。这每一步难道不是让 Cassandra 写的更快。这个设计想想对读会有什么影响。首先，数据结构的复杂性，Memtable 中和 SSTable 中数据结构肯定不同，但是返回给用户的肯定是一样的，这必然会要转化。其次，数据在多个文件中，要找的数据可能在 Memtable 中，也可能在某个 SSTable 中，如果有 10 个 SSTable，那么就要在到 10 个 SSTable 中每个找一遍，虽然使用了 BloomFilter 算法可以很快判断到底哪个 SSTable 中含有指定的 key。还有可能在 Memtable 到 SSTable 的转化过程中，这也是要检查一遍的，也就是数据有可能存在什么地方，就要到哪里去找一遍。还有找出来的数据可能是已经被删除的，但也没办法还是要取。
下面是读取数据的相关类图：
图 13. 读取相关类图
根据上面的类图读取的逻辑是，CassandraServer 创建 ReadCommand 对象，这个对象保存了用户要获取记录的所有必须指定的条件。然后交给 weakReadLocalCallable 这个线程去到 ColumnFamilyStore 对象中去搜索数据，包括 Memtable 和 SSTable。将找到的数据组装成 Row 返回，这样一个查询过程就结束了。这个查询逻辑可以用下面的时序图来表示：
图 14. 查询数据时序图
在上图中还一个地方要说明的是，取得 key 对应的 ColumnFamily 要至少在三个地方查询，第一个就是 Memtable 中，第二个是 MemtablesPendingFlush，这个是将 Memtable 转化为 SSTable 之前的一个临时 Memtable。第三个是 SSTable。在 SSTable 中查询最为复杂，它首先将要查询的 key 与每个 SSTable 所对应的 Filter 做比较，这个 Filter 保存了所有这个 SSTable 文件中含有的所有 key 的 Hash 值，这个 Hsah 算法能快速判断指定的 key 在不在这个 SSTable 中，这个 Filter 的值在全部保存在内存中，这样能快速判断要查询的 key 在那个 SSTable 中。接下去就要在 SSTable 所对应的 Index 中查询 key 所对应的位置，从前面的 Index 文件的存储结构知道，Index 中保存了具体数据在 Data 文件中的 Offset。，拿到这个 Offset 后就可以直接到 Data 文件中取出相应的长度的字节数据，反序列化就可以达到目标的 ColumnFamily。由于 Cassandra 的存储方式，同一个 key 所对应的值可能存在于多个 SSTable 中，所以直到查找完所有的 SSTable 文件后再与前面的两个 Memtable 查找出来的结果合并，最终才是要查询的值。
另外，前面所描述的是最坏的情况，也就是查询在完全没有缓存的情况下，当然 Cassandra 在对查询操作也提供了多级缓存。第一级直接针对查询结果做缓存，这个缓存的设置的配置项是 Keyspace 下面的 RowsCached。查询的时候首先会在这个 Cache 中找。第二级 Cache 对应 SSTable 的 Index 文件，它可以直接缓存要查询 key 所对应的索引。这个配置项同样在 Keyspace 下面的 KeysCached 中，如果这个 Cache 能命中，将会省去 Index 文件的一次 IO 查询。最后一级 Cache 是做磁盘文件与内存文件的 mmap，这种方式可以提高磁盘 IO 的操作效率，鉴于索引大小的限制，如果 Data 文件太大只能在 64 位机器上使用这个技术。
数据的删除
从前面的数据写入规则可以想象，Cassandra 要想删除数据是一件麻烦的事，为何这样说？理由如下：
1.数据有多处 同时还可能在多个节点都有保存。
2.数据的结构有多种 数据会写在 CommitLog 中、Memtable 中、SSTable 中，它们的数据结构都不一样。
4.数据时效性不一致 由于是集群，所以数据在节点之间传输必然有延时。
6.除了这三点之外还有其它一些难点如 SSTable 持久化数据是顺序存储的，如果删除中间一段，那数据有如何移动，这些问题都非常棘手，如果设计不合理，性能将会非常之差。
本部分将讨论 Cassandra 是如何解决这些问题的。
CassandraServer 中删除数据的接口只有一个 remove，下面是 remove 方法的源码：
清单 3. CassandraServer.remove
public void remove（String table， String key， ColumnPath column_path，
long timestamp， ConsistencyLevel consistency_level）{
checkLoginDone（）;
ThriftValidation.validateKey（key）;
ThriftValidation.validateColumnPathOrParent（table， column_path）;
RowMutation rm = new RowMutation（table， key）;
rm.delete（new QueryPath（column_path）， timestamp）;
doInsert（consistency_level， rm）;
}
仔细和 insert 方法比较，发现只有一行不同：insert 方法调用的是 rm.add 而这里是 rm.delete。那么这个 rm.delete 又做了什么事情呢？下面是 delete 方法的源码：
清单 4. RowMutation. Delete
public void delete（QueryPath path， long timestamp）{
....
if （columnFamily == null）
columnFamily = ColumnFamily.create（table_， cfName）;
if （path.superColumnName == null && path.columnName == null）{
columnFamily.delete（localDeleteTime， timestamp）;
}else if （path.columnName == null）{
SuperColumn sc = new SuperColumn（path.superColumnName，
DatabaseDescriptor.getSubComparator（table_， cfName））;
sc.markForDeleteAt（localDeleteTime， timestamp）;
columnFamily.addColumn（sc）;
}else{
ByteBuffer bytes = ByteBuffer.allocate（4）;
bytes.putInt（localDeleteTime）;
columnFamily.addColumn（path， bytes.array（）， timestamp， true）;
}
}
这段代码的主要逻辑就是，如果是删除指定 Key 下的某个 Column，那么将这个 Key 所对应的 Column 的 vlaue 设置为当前系统时间，并将 Column 的 isMarkedForDelete 属性设置为 TRUE，如果是要删除这个 Key 下的所有 Column 则设置这个 ColumnFamily 的删除时间期限属性。然后将这个新增的一条数据按照 Insert 方法执行下去。
这个思路现在已经很明显了，它就是通过设置同一个 Key 下对应不同的数据来更新已经在 ConcurrentSkipListMap 集合中存在的数据。这种方法的确很好，它能够达到如下目的：
1.简化了数据的操作逻辑。将添加、修改和删除逻辑都统一起来。
2.解决了前面提到的三个难点。因为它就是按照数据产生的方式，来修改数据。有点以其人之道还治其人之身的意思。
4.但是这仍然有两个问题：这个只是修改了指定的数据，它并没有删除这条数据；还有就是 SSTable 是根据 Memtable 中的数据保存的，很可能会出现不同的 SSTable 中保存相同的数据，这个又怎么解决？的确如此，Cassandra 并没有删除你要删除的数据，Cassandra 只是在你查询数据返回之前，过滤掉 isMarkedForDelete 为 TRUE 的记录。它能够保证你删除的数据你不能再查到，至于什么时候真正删除，你就不需要关心了。Cassandra 删除数据的过程很复杂，真正删除数据是在 SSTable 被压缩的过程中，SSTable 压缩的目的就是把同一个 Key 下对应的数据都统一到一个 SSTable 文件中，这样就解决了同一条数据在多处的问题。压缩的过程中 Cassandra 会根据判断规则判定哪些数据应该被删除。
SSTable 的压缩
数据的压缩实际上是数据写入 Cassandra 的一个延伸，前面描述的数据写入和数据的读取都有一些限制，如：在写的过程中，数据会不停的将一定大小的 Memtable 刷到磁盘中，这样不停的刷，势必会产生很多的同样大小的 SSTable 文件，不可能这样无限下去。同样在读的过程中，如果太多的 SSTable 文件必然会影响读的效率，SSTable 越多就会越影响查询。还有一个 Key 对应的 Column 分散在多个 SSTable 同样也会是问题。还有我们知道 Cassandra 的删除同样也是一个写操作，同样要处理这些无效的数据。
鉴于以上问题，必然要对 SSTable 文件进行合并，合并的最终目的就是要将一个 Key 对应的所有 value 合并在一起。该组合的组合、该修改的修改，该删除的删除。然后将这个 Key 所对应的数据写在 SSTable 所对应的 Data 文件的一段连续的空间上。
何时压缩 SSTable 文件由 Cassandra 来控制，理想的 SSTable 文件个数在 4~32 个。当新增一个 SSTable 文件后 Cassandra 会计算当期的平均 SSTable 文件的大小当新增的 SSTable 大小在平均 SSTable 大小的 0.5~1.5 倍时 Cassandra 就会调用压缩程序压缩 SSTable 文件，导致的结果就是重新建立 Key 的索引。这个过程可以用下图描述：
图 15 数据压缩
工商网监
评论