读过本文才算真正了解Cassandra数据库( 四 ) _Cassandra

文章插图
我们来看一下，SSTable到底是什么，它的读取是什么样子的。我们根据SSTable的访问顺序来看，在3.0版本中，SSTable包含以下这么几个文件：
Filter.db这是SSTable的Bloom过滤器，简单的讲，它告诉你，你要的Key，在我这里有没有。Bloom过滤器的工作方式是将数据集中的值映射到位数组，并使用散列函数将较大的数据集压缩为摘要字符串。根据定义，摘要使用的内存量比原始数据少得多。它速度快，可能误报，但不会漏。简言之，有可能告诉你有，但是没有。但绝不会告诉没有，却有。注意！这里划一个重点，Cassandra会维护一个Bloom filter的副本在内存里面。所以，这一步不一定会有实际IO 。在书上也提到，如果加大内存，是可以减少Bloom过滤器误报的情况。
Summary.db，这里是索引的抽样，用来加速读取的。
Index.db，提供Data.db里的行列偏移量。
CompressionInfo.db提供有关Data.db文件压缩的元数据。这里值得关注的是，它用了Compression这个词，我猜测，如果Data.db里面采用了压缩算法，比如说字典压缩之类的，那么这个文件里面应该就会存储字典数据，或者类似的Compress相关的元素据。这也就是为什么这个文件，在访问流程中是不可绕过的。因为一旦Data.db的数据进行了压缩，那就必须依靠相关的元数据来解压缩数据。从图上可以看出，这个元数据在内存中，相对性能会比较快。
Data.db是存储实际数据的文件，是Cassandra备份机制保留的唯一文件。它是唯一的真实数据，其他的都是辅助数据。比如索引可以重建，字典可以重建等等。
Digest.adler32是Data.db校验用的。
Statistics.db存储nodetool tablehistograms命令使用的有关SSTable的统计信息。
TOC.txt列出此SSTable的文件组件。
其中1-5是跟SSTable访问数据性能相关的文件。如果Cache是ALL的情况下，Cassandra在通常都可以在内存访问之后，直接定位到SSTable的具体文件和数据所在偏移量中去。相对于传统数据库，B树索引层层向下，遇到没有的索引块就要IO 。这个性能应该还是非常可观的。
讲到这里，不知道你有没有感受到，Cassandra的一个重要精华所在，那就是没有锁，或者叫没有资源上的冲突和争抢。通过Timestamps概念，解决数据可相同Key数据不要上锁的问题。尽管我们前面的内容，全部都还只是在围绕单节点数据库介绍。但是Timestamps的使用，是为Cassandra分布式、去中心、可扩展、高可用、容错性、可配置一致性提供了更多灵活方便的地方。

文章插图
分布式、去中心、可扩展性
前面我们把这六条分成了两类，分布式、去中心、可扩展，这三个围绕的是KEY的独立性。尤其是Partition Key，它是具有极强的独立性的。由于它的极度独立，理论上任何不同Partition Key的数据，就都可以放在不同机器上，去独立的提供服务，也就成就它的分布式、去中心和可扩展。对照这几条特性看一下。
分布式，百度词条上解释为，建立在网络上的软件系统。有四大特性：

分布性。分布式系统由多台计算机组成，它们在地域上是分散的，可以散布在一个单位、一个城市、一个国家，甚至全球范围内。整个系统的功能是分散在各个节点上实现的，因而分布式系统具有数据处理的分布性。一个逻辑上的数据库表，他是分散存储来多个Node中的。不同的Key值的记录会由Cassandra的不能节点提供分散的的服务。

自治性。分布式系统中的各个节点都包含自己的处理机和内存，各自具有独立的处理数据的功能。通常，彼此在地位上是平等的，无主次之分，既能自治地进行工作，又能利用共享的通信线路来传送信息，协调任务处理。Cassandra只有在Partition Key划分数据所属Node的存储位置时，有主次副本之分。比如说，我的Node1要存放的Key值是多少到多少，其他的勉强称之为副本。其实Cassandra存的是多个地位平等主本，且都具备独立处理数据等能力，它们协同处理任务，并非传统意义上的主备数据概念。