真正了解Cassandra数据库

作者：宇文湛泉来源： DBAplus社群点击数：916发布时间： 2020-02-13 15:37:13

读过本文才算真正了解Cassandra数据库。严格来说，数据库是长期储存在计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享。

Cassandra数据库，值得介绍的技术细节其实挺多的。因为它很多实现思路和关系型数据库或者其他的NoSQL数据库，是有一些不同的。这种不同是在数据库设计实现思路上也是根源上的。所以衍生开来的诸多特点，在介绍起来就不太容易和其他数据库去类比。那么Cassandra有这么大量的内容，本文只能选讲其中的一部分，这部分内容是如何挑选的呢?

在《Cassandra The Definitive Guide》这本书里，有一段概括性的描述，即用50个word描述Cassandra。它归纳了Cassandra的几大特性，依次为：开源、分布式、去中心化、可扩展性、高可用、容错性、可配置的一致性、行存储。

我把这几大特性分为四类：

第一类开源，这个不需要讨论。其余的三类7个特性，就是选讲的核心提纲。
第二类是高可用、容错性、可配置的一致性，这是围绕着多节点冗余数据的特性，换句话说，如果Cassandra的数据，每一行数据只有一份而没有副本，那么第二类特点就是不存在的。
第三类是分布式、去中心化、可扩展性，这三个特点围绕的是数据库的可拆分性，且各节点可以独立运行的能力。若只装一个单机的Cassandra，那这一类特点就不存在。
第四类是行存储，是描述数据库底层存放数据的最基本的存储结构特征，也是我切入的第一个特征。

行存储结构

任何数据库设计和优化始终围绕一个核心事情——查询优化。查询永远是使用数据的核心需求。为什么要INSERT?为了以后这个数据要查询。为什么要DELETE?因为不再查询，并且让其他的数据更快的查询。为什么要UPDATE，因为要实时的查询使用。无论是数据库的存储结构，像Oracle的段、区、块的设计，还是辅助的存储结构，像索引这种，归根结底，为了更快速的查询出需要数据。Cassandra也不例外，了解它的存储结构，就更加能够理解它是如何在这个存储体系下提高查询性能的，即便它是一个号称更擅长于INSERT的数据库。

在早期的Cassandra中，数据库表一直被称之为ColumnFamily(列族)，我也有很长的时间将其理解为列的集合的意思。所以，我有一段时间认为Cassandra是一个列存储的数据库。那为什么Cassandra的数据模型，可以认为是行存储(ROW-ORIENTED)的，但又会在早期表被称之ColumnFamily呢?因为从根本上来讲，Cassandra不能算一个严格的行存储，当然它更不是列存储，它的数据是存储在一个稀疏矩阵中的。可能这个解释略微抽象。那么我先来说下它为什么不是行存储。

任何传统的行存储数据库，一旦DDL定义了数据表有多少个列。那么这一行数据一定存储了所有的列值。即使出现了这一列没有值的情况，那么也一定存储了一个NULL值，或者是由应用程序存储一个空格或0来表示没有值。这一列对应的存储空间一定是存在的，当然数据库中的varchar或者压缩算法会使得这个存储空间尽可能小。

但是，Cassandra允许对于任何给定的行，你可以只包含其中几列，而并非一行数据要有所有的列，当然KEY列是要有的。这种在列值存储上的动态性，是传统的行存储数据库根本不具备的。我猜这也可能早期为何有ColumnFamily概念的根源。

前文提到了，我有一段时间认为Cassandra是一个列存储的数据库。但是，我从来都认为它是一个不彻底的列存储数据库，而是一个受限的列存储数据库。不彻底在哪里?大部分的列存储数据库，都是为了OLAP而生的，它的优势在于，在某一列上做聚合的性能无语伦比。

比如我一个表有100列，我要对某一列求个SUM。列存储数据库可以完美绕过多余的99列，只把需要的这一列一个不差的拿出来做SUM。但是，用过Cassandra数据库的人都知道，在任何一列上做全列级的聚合，那简直是灾难性的。就凭Cassandra会将不同的KEY部署在不同的数据库节点/分区PARTITION(注意这里和传统数据库分区不同)，任何列级的操作，都会需要在多个数据库上打转。更何况，CQL语句到来的时候，还要搞清楚，这个聚合列在这行数据上有没有。所以，Cassandra是不具备列存储数据库的特质的。

真正了解Cassandra数据库_数据库视频_数据管理视频_数据结构视频_课课家

为什么，最后Cassandra还是被描述为是一个ROW-ORIENTED呢?

首先，它的存储是紧紧围绕着Key的。Key，它是一行数据的唯一标识符号。一行数据围绕着Partition Key存在一起,并且围绕着Clusterting Key局部有序。可见它ROW-ORIENTED的特点还是很鲜明的。什么样的存储结构，就决定一个数据库擅长做什么。按主键排序的行存储DB2数据库最擅长的是什么?是在OLTP系统里，通过主键做单条记录的快速查询(Select by Key)，这也正是Cassandra最为常见的CQL形态。什么样的存储结构，也决定了什么样的操作会有限制。

在理解了Cassandra数据库的ROW-ORIENTED的稀疏矩阵存储之后，再来看看CQL语句的语法限制，那么这些限制就很容易理解。例如：Select 语句，Where条件里，一定要送Partition Key(没有次索引的情况)。如果不送，则语法上必须要添加ALLOW FILTERING。

为什么是这样，刚才提到了，Partition Key决定了数据存在哪里，它像是一个指针，直接指向了这一行数据的物理位置。ALLOW FILTERING表示什么，表示的是Cassandra数据库获得这条记录是通过筛选得来的，而不是通过直接定位得来的。

类比一下传统数据库，Where 条件送Partition Key就好比通过HASH索引定位记录，ALLOW FILTERING就如同先做一次TABLE SCAN，读出大量记录再从记录里过滤出符合WHERE条件的。再看看关于Clusterting Key的，CQL语法要求，范围查找、Order by一类的语法都需要使用Clusterting Key，这就十分好理解。在定位的Partition Key确定了位置之后，同一Partition Key的数据，都是Clusterting Key有序存放的，那么通过在这个有序的Key列上，无论范围也好、排序也好，都不会需要数据库引擎真正去排序，这就好像在传统数据库里，ORDER BY的列，和某一个索引一致的情况下，执行计划里不会真的排序是一个道理。

搞清楚了Cassandra的存储结构之后，我们来看Cassandra在某一个节点上怎么做增删改查。无论Cassandra的多节点特点多么鲜明，在单一节点上面，数据的读写，永远才是数据库性能的根基。节点再多，如果单节点上读写性能不行，那数据库终究是快不起来的。所以这里我们来看一下，Cassandra是怎么样读写数据的。

先翻译《Cassandra The Definitive Guide》一段话。“在Cassandra中，写入数据非常快，因为它的memtables和SSTables设计，使它插入时，不需要执行磁盘读取或搜索，这些减慢数据库速度的操作。Cassandra中的所有写入都是追加形态的。”

我们看一下Cassandra的写入步骤，来解读它的写入优势。

第一步，写Commit Logs。这个步骤完全不是什么新发明。我觉得它和传统数据库的REDO Log几乎是一样的。无论是什么数据库，这个Log的写入，都是追加形态的。但是，注意看这个图，Commit Logs直接写在硬盘上，我认为这个描述并不准确。无论时传统数据库的REDO LOG还是Cassandra 的Commit Logs，它都是先到内存，再FLUSH到磁盘上的。而FLUSH的策略是由一些参数决定的，比如commitlog_sync。这和传统数据库非常相似，这里不展开来讨论，只需要认识到一点，FLUSH的动作频率越高，系统奔溃时丢失的数据越少，同时损失部分数据插入性能。就像MySQL数据库的参数Innodb_flush_log_at_trx_commit=1时，Mysql是最安全，但是也是最慢的。

第二步，Add to memtable，这是关键的一步，Cassandra的这一步是完完全全的内存动作。而若是传统的数据库，则大约需要做这么几个动作：

逐层搜索索引，若这个索引块不在DATA BUFFER里，触发磁盘IO。
通过索引定位数据块，若数据块不在DATA BUFFER里，触发磁盘IO。
修改索引块，修改数据块，如果修改并发量大时，可能产生锁等。

当然，若是像Oracle数据库那样的堆表设计，纯粹的INSERT动作在b的IO触发可能性要少一点，但是在UPDATE(Cassandra中也是Insert)场景下，这些开销都是不可少的。Cassandra为什么可以在Memtable上纯粹的做追加写入，这个Cassandra记录的Timestamp概念是分不开的，即无论你写入多少次，数据库只会以最新Timestamp的记录为准。这样就不需要去对记录资源上锁。这样的设计，不要说没有锁冲突了，就连去把需要上锁的记录找出来的开销都省了，快就快在这个地方。

但是，这个快是有代价的，那就是数据的一致性。比如一个简单的需求，在数据写入之前，需要看看这条数据是不是存在，如果存在了就不能插入(CQL的IF NOT EXIST语法)，或者UPDATE需要看数据条件(WHERE IF Column = ‘*’) 。一旦这种带条件CQL使用，那可以推断，上面的这些优势，也就不存在了。

看第三步，如果这行数据在Row Caches里，使它失效。注意这个地方，Row Caches里的记录是不改的。那么Row Caches的使用场景，只有特别热点的数据读取的时候使用，它并不适合高并发热点数据修改的场景。

常规交易，做完这三步就返回成功了，不需要等待Memtable的内容落盘。换句话说，直接影响交易性能的步骤，结束了。这和传统数据库也没有太大的差别。那么接下来的步骤，就不直接影响数据库的写入能力。

第四步，数据的落盘，这个动作通常是异步的，在后面会详细展开将SSTable的存储。第五步，这个就是多节点特性了，是一个节点异常的处理过程。

总结一下，传统的数据库的写入(包括INSERT、UPDATE、Delete)，通常是一个读后写的过程。而Cassandra的写入，是没有先读这个动作的，这也是它快的根本原因。一旦使用了IF NOT EXIST之类的语法，那么它的写入性能也就会要受损。

接下来看一下Cassandra的读取，它的读取是多节点、多副本的读取。此处，我们先关注一个节点上的情况。

第一步，如果这一行数据在Row Caches中，直接返回数据，这个好理解。

第二步，检查检查KeyCaches里的索引，这里可以理解为，这是一个主键索引，它存储的是未来在Memtables或者SSTables用来定位的信息(书上原文是offset location)。需要注意的是，这里面的值，在第三步、和第四步的时候，都可能用得上，而不是仅仅用于第三步。看到这个地方，可以发现，其实这个图有个问题，就是没有指出KeyCaches的维护。Cache是可以在建表时配置的一个参数。可以推测，假如我们建表的时候，keys的Cache采用了ALL的设置，那么应该是在有新的KEY值写入Memtables时，维护到了Key Caches中。

第三步，这一步需要关注是，对于一个指定的表(或列族)，是只会使用唯一的一个Memtable 的，那么这个搜索就是线性的。Memtable中的内容，是还没有FLUSH到SSTables里的数据，在查询是，它里面的内容和SSTables中的内容，都是要同步读取的，但对单节点而言，它的内容通常更新。

与写入场景大有不同的地方是，读数据的关键步骤，是第4步，读SSTables。这里在后面的内容展开，看一下第五步，如果Row Caches还可用，把这条记录加入的Row Caches。Row Caches放的是一整行的数据，如前面提到了，适合于存放热点读取的数据。

所有的数据库，通常都是有四大常规操作，谓之“增删改查”。介绍了写入、查询之后，这里简单的介绍一下Cassandra的删和改。一句话简述之，Cassandra的删除都是修改，Cassandra的修改都是写入，所以Cassandra只有写入和查询。Cassandra一直写入数据，岂不是会存储爆炸不成。在这里，我们介绍三个新概念(相对传统数据库)-Tombstones，Timestamps，Compaction。

Cassandra的删除都是修改，这个好理解，在很多业务数据库表里面，经常会为了保留痕迹，而做一个逻辑删除动作。也就是修改某个标识，表示这条记录以及删除或作废，而并没有在数据库里真正的删除。Cassandra在收到Delete命令时，并不会立刻去删除这行记录。而是会给这行记录一个Tombstones，表示它被删除了。

Cassandra的修改都是写入。前面提到Cassandra速度快，快在不需要定位数据。任何Update命令，在传统数据库上，都需要把这条记录读到内存里，并上锁。而在Cassandra上，Update命令会变成一条INSERT语句，那岂不是在系统里重KEY了吗?这里便要依靠记录上的Timestamps。

Cassandra的每次查询，都会把所有重的KEY读出来，但是永远会以最新的Timestamps为准。这就解决了把所有的修改，都变成写入的问题。但是，这么干有两大显而易见问题。第一，数据会无限的膨胀，吃掉磁盘。第二，数据膨胀会带来查询需要读出的重复数据增加，无限的膨胀则会无限的增加，读取性能就会受损。

所以这里，就要介绍压缩(Compaction)的概念。这里要特别的注意，这不是我们通常说的数据库压缩技术，那个通常用的Compress。只是由于多个官方文档都把Compaction翻译成了压缩，我个人觉得它更应该翻译成数据的整理。Compaction是在数据库后台异步做的，接着前面的内容，它的内容至少有比如把墓碑数据真实移除，把时间戳比较老的数据移除，重新整理SSTable的存储文件等。这样来解决前面那两个问题。这个动作在某种意义上来讲甚至有一点像DB2数据库的REORG动作。不同的数据库表，可以在Keyspace级别选择不一样的CompactionStrategy。它常翻译为压缩算法，我觉得翻译成整理策略更加合适。我觉压缩算法，应该和Compress的那个概念一致。毕竟，这个Compaction没有给数据文件里连续的值，用个RLE算法，或者建个字典什么的对吧。介绍完了这些之后，让我们来直面数据库最大的瓶颈。

只要一个数据库不是内存数据库，那它永远都要面对它最大的性能瓶颈，磁盘IO。我们前面提到的诸多概念，比如Cache、列存储、索引等等，他们优化性能的本质都指向一处，减少磁盘IO。前面讲读写部分时，都跳过了第4步。而对于SSTable的读取，其实才是影响性能的关键步骤。

我们来看一下，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存的是多个地位平等主本，且都具备独立处理数据等能力，它们协同处理任务，并非传统意义上的主备数据概念。
并行性。一个大的任务可以划分为若干个子任务，分别在不同的主机上执行。每个Node自然是自己提供涉及的Key的服务，相互之间独立、并行。对于不同的CQL而言，可能会由不同Node来完成查询。也可以是一个CQL里面涉及的多个Node，它们也基本上是并行来完成这个CQL的。
全局性。分布式系统中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。同时，还应当有全局的保护机制。系统中所有机器上有统一的系统调用集合，它们必须适应分布式的环境。在所有CPU上运行同样的内核，使协调工作更加容易。Cassandra是完全符合这个定义的，Coordinator节点并不是固定的。每个节点都可以接受任何的CQL，并且来充当协调者的角色。重要的是，对于一个应用程序或者客户端而且，可以不关心Cassandra后来是怎么样存储和查询数据的。它从外面看到的，始终只有一张完整的逻辑数据表。

有了分布式的基础，Cassandra可以运行在多个Node下，并且多个Node可以部署在真实的不同的数据中心机房里，不同机架上，也就能做到去中心Decentralized。有了这个基础，就可以配合Cassandra的多中心的复制策略NetworkTopologyStrategy，在每一个数据中心定义数据复制了。

可扩展这个词其实，并不是特别准确，它的重点其实是可水平扩展。简而言之，就是在图中环上加Node，就可以提高Cassandra的处理能力。这其实和它的分布式特点是密不可分的。Cassandra的拆分粒度最细，理论上几乎可以到一个Partition KEY。或者说，每一个Partition KEY，都可以被看作可以拆分的，独立处理的最小的单位。增加数据的同时只要增加Node就可以了，这就使得它的水平扩展性是很好的。

做一个偏激的假设，如果Cassandra只有一份数据存储，就凭Key独立的特点，把不同的Key分到不同的机器上提供服务，也可以算得上是分布式、去中心和可扩展的。但是它这个特点是不完美，不彻底的。因为机器分得越多，任何一台机器故障，它提供的服务就是不完整的。

高可用、容错性、可配置一致性

接下来，我们继续看另外三个特点，高可用、容错性、可配置的一致性，这些特点围绕的核心就数据冗余。

任何的高可用背后，一定是有数据冗余的。传统数据库通常偏爱的是主备模式，就是当提供服务的数据库节点DOWN掉之后，备节点开始提供服务。这时候往往故障检测、主备切换，应用切换的时间就会成为关注的焦点，做得好一点的数据库可以在1分钟或者几十秒内完成切换。不过在如今7*24*365的环境下，1分钟的故障恢复时间通常并不能让用户十分满意，当切换时间压缩到一定程度，还会出现一个矛盾点，就是数据库异常时间监测阈值。如果设得太长，主备切换就慢，设太短了，一个网络抖动，就可能触发不必要的主备切换误判。

Cassandra的数据复制(replicas)并不像传统的备份数据，它更像是多份主数据，这些数据都是时时刻刻对外提供服务的，换句话说，有一个数据库节点DOWN掉，完全不需要主备切换时间。在资源充足的情况下，甚至是几乎无感的(比如7个replicas坏了1个)。

在Cassandra里面，数据复制(replicas)多少份，怎么存储，这个策略是可以根据不同的Keyspace来设置的，相当于提供一个灵活的选择，可以根据数据库表的实际使用场景和形态，来决定数据复制的策略。

数据冗余可以说是分布式系统中的常规操作，像参数数据之类的，经常会采用数据冗余的方法来处理。然而，有冗余的地方就有同步。数据一致性问题，永远和数据冗余相伴而生。好在Cassandra有Timestamps来解决一致性问题，容错性只是一致性的一个衍生产品，简单的说，只是Cassandra发现了一个老Timestamps的错误数据，后台修复一下而已。

而可配置一致性，就是Cassandra的一个特别重要的特性了。因为它的影响但不仅仅是对于高可用，它还直接影响数据库性能。就传统数据库而言，开不开备库，对OLTP交易性能也是有直接影响的(包括Redis也是)。从理论上来说，Cassandra要等更多的Node写入数据，那响应时间就会越慢。这个响应时间取决与最慢的那个Node。若要交易响应更快，就需要通过异步的方式。所以Cassandra通常都不会等所有的Node都响应，等多少Node，等哪些Node，就是可配置一致性。

在数据写入读取方面Cassandra的一直性级别有：

ANY(仅写入),ONE,TWO,THREE ,QUORUM,ALL

LOCAL_ONE, LOCAL_QUORUM,EACH_QUORUM

以上这些级别很好理解，不需要逐个解释。关于高可用和强一致性，永远都是鱼和熊掌。假如我们的系统使用了最快的方式写入，比如写ANY，读ONE。那么读到的数据并不是最实时的准确数据的可能性就会大幅增加。如上面的图，有6个节点在写入数据，任意一个写成功，程序就成功返回。那么假定其余5个节点还没有完成写入。那这时候，有一个读ONE的程序，恰好读到了这5节点中的一个，并成功返回，这就产生了数据的不一致。要做到数据的强一致，读写策略就必须配合设置，满足这样的条件。

W+R>RF W—写一致性级别 R—读一致性级别 RF—副本数

Cassandra的这个设计非常的巧妙，它提供极好的调优灵活性。数据库调优的本质无非是个损有余而补不足的过程，这个有余并非指损性能好的地方去补性能不好的地方。

数据库或数据，有些地方有些功能，我们不用或者少用，性能不需要那么好，称之为有余;有些地方有些功能我们常用，主要用，性能要越快越好，我们称之为不足。比如很多系统的某个数据库表，它的访问形态是有局限性的。有可能一张表，100次插入，只有1次读取，像流水数据。有可能一张表，1次插入，100次读取，像参数数据。这里面就有了极大的灵活性，我们可以损失冷门操作的性能，来保障我们的主要操作。例如，以读取为主的表，我们可以设置写入的一致性为ALL ,读取的一致性为ONE。从而获得一个非常高效的系统性能。