Cassandra分布式数据库框架总结，cassandra框架
框架介绍：
对cassandra分布式数据库的一些总结（由于cassandra资料比较少，总结只是个人理解，仅作为参考）:
Cassandra是NOSQL数据库的一种，是基于列族存储的轻量级分布式数据库。
thrift框架：
Cassandra客户端和服务端是通过thrift框架进行通信的，thrift框架是一个跨语言的服务部署框架，使用了一种中间语言IDL来定义RPC的接口和数据类型。经过thrift专用的编译器编译IDL文件后，生成指定编程语言的服务端和客户端接口库文件。用户可以使用相应的服务端或客户端的接口完成自己的逻辑功能。（Cassandra中服务端程序已经实现，只要启用就行，我们要完成的工作是客户端的编写）。实现所谓的RPC（远程过程调用），所谓的远程过程调用是参考了本地过程调用的概念，（正常程序的代码中如果使用到该代码文件中没有的函数调用，则需要在编译链接的阶段获取到所需要函数在整个可执行文件中相对的偏移位，也就是该函数的指针，到执行函数时通过该指针跳转到函数的代码中执行），RPC的原理是通过通信的方式，让不在同一可执行文件中的函数调用通过网络通信的方式实现，在RPC中事先设置服务端和客户端的接口名和参数一致，其中服务端负责实现该接口的功能，客户端调用该同名接口时，会使用thrift框架生成的通信接口发送该函数名和参数列表给服务端，服务端根据函数名和参数列表信息在map容器查找到服务端已经实现了功能的同名函数的指针，执行该函数，并且把函数的返回值通过通信的方式返回给客户端，客户端接收该函数返回值，完成一次RPC调用。
在Cassandra中，interface目录下保存一份cassandra.thrift文件，该文件使用IDL语言定义了Cassandra的基本数据结构和接口。由于本身Cassandra默认提供了cassandra.thrift编译后产生的接口文件库，所以不用手工再编译一次。可以直接使用这些库文件进行Cassandra客户端程序的编写，实现对数据库服务器的访问。
Cassandra的存储数据结构：
Cassandra数据库的逻辑层的数据结构相对简单，主要是以下层次1.keyspace（相当于oracle数据库中的表空间）,跟oracle类似，也有系统表空间和用户自己建立的表空间2.columnfamily列族（相当oracle中的表）3.column和supercolumn，这个是cassandra数据结构中最小的单元。每一个column都由三个元素构成name,value,timemap.
Cassandra数据库集群的写流程：
一个key：18028682078下的某列数据column_name=cust_name, column_value=郑人峰，timemap=xxxx。这列数据写入数据库的过程大概如下：首先对key值进行哈希运算，获得一个token值比如3，根据该token值查找到对应的3号节点，如果该节点是客户端访问的本地节点的话，则存入本地节点，如果是其他节点则通过节点间的通信，把数据送到对应节点进行入库。如果该列族有指定的备份策略的话，比如备份数为3，则会在token对应节点后面的2个节点中同时写入数据。在cassandra中为了减少随机io，开辟了一块写缓存Mentable,每个Mentable对应一个列族column_family。数据进入Mentable后，在Mentable搜寻key值为18028682078的数据，并合并在一起。当然在进入Mentable前先要往commitlog日志中写日志，commitlog相当oracle中的重做日志，在数据库出现异常，导致Mentable缓存的数据丢失时进行恢复。在Mentable中的数据量到达一定后顺序输出到sstable文件中，一个sstable文件主要由下列四种文件组成：data文件（真正保存数据的文件），filter文件（主要用来快速查找该sstable文件中是否有某个key对应的列存在，是辅助文件），index文件（主要用来某key下的数据在data文件中的位置），statistics（主要保存一些统计信息）。sstable文件是这四种文件的总概念。
总体流程：哈希key值得到token值找到对应得节点和（备份节点）-〉在重做日志commitlog登记-〉进入Mentable缓存-〉输出到sstable文件（分别生成对应得四类文件）
Cassandra数据库集群的读流程：
比如说要读取key值为18028682078下所有列的值，首先，找到最合适的节点（具体的算法不是很清楚，估计要考虑到网络通信速度等情况，比如是否为同个网段机架之类）。然后向该节点的服务器发送读请求，如果需要较高的一致性级别的话，则还需从其他节点读取数据（以便比较多份数据，根据时间戳找出最新的一份数据），接受到读请求后，服务器便先在写缓存Mentable中寻找记录，比如找到了key为18028682078的一列（column_name=cust_name, column_value=郑人峰，timemap=xxxx） ，然后再去读缓存rowcash中找，比如找到了key为18028682078的另外一列（column_name =cust_addrss, column_value=信华小区），然后再去keycash中找是否有该key值，获取对应的data文件的偏移位。上面的两种读缓存，如果没有命中的话，将在找到该key的数据后进行添加。在读写缓存中只能找到部分列的数据，剩下的需要去sstable中的data文件中获取，首先用filter快速判断该key是否有数据存储在正在查找的sstable文件中，如果有则读取index索引文件(为了加快筛选的过程，filter文件和部分index文件会在启动时加载如内存），找到该key对应数据在data文件中的偏移位。最后去data文件中读取数据。
总体流程：客户端发送读请求到合适节点和备份节点的服务器端-〉在写缓存Mentable查找该key对应的数据-〉在读缓存rowcash和keycash中查找-〉最后去sstable文件中查找-〉最后根据要求的一致性在多个节点得出的多份数据中提取出满足一致性要求一份数据。
Cassandra数据库的物理存储和压缩：
cassandra数据库基于列族存储，所以cassandra的columnfamily(相当于传统数据库中的表）的物理存储跟单纯的列存储模式和单纯的行存储模式都有所区别。比如key为18028682078有多列数据，很可能在cassandra中的存储是这样的：Mentable中保存着（column_name=cust_name, column_value=郑人峰，timemap=xxxx），sstable1的data文件中保存着（column_name =cust_addrss, column_value=信华小区，timemap=xxxx），（column_name =cust_company, column_value=广东电信，timemap=xxxx）两列数据，并且这两列数据物理上是连续的。sstable2的data文件中保存着column_name =cust_sex, column_value=男，timemap=xxxx），（column_name =cust_age, column_value=25，timemap=xxxx）两列数据，同样物理上是连续的。之所以出现这种情况，是因为Mentable中的数据是间断性输出到磁盘上形成sstable文件的，所以第一次写入了key为18028682078对应的两列数据，直到Mentable数据量到达一定了则输出sstable1文件，同样第二次输出了sstable2文件。最后的一列暂时还没输出到磁盘，还保存在写缓存中。这种存储模式会导致一个问题就是key下的各个列会比较分散，查找一列数据则需要去多份sstable文件中寻找，影响查询速度，并且占用过多的文件标识符资源。所以引入了压缩的概念，这种压缩并不是对字符集进行算法压缩，而是指对上面这种情况，进行多份sstable文件合并工作，尽量让一个key下的多列存储在一份sstable文件中。另外压缩还指去掉不需要的冗余，比如cassandra数据库的更新和删除和传统数据库不一大一样，某种意义而言cassandra是没有更新功能的，同一key下的同一列如果不断写了多份数据后，这些多份数据都会保存在data文件中，并不会出现覆盖旧数据的情况，而能取到最新的一份数据则靠读的一致性来解决。另外数据删除也是一样，对cassandra的数据删除只是在对应的数据上打上删除的标记。并没有真正从磁盘中删除。这样，cassandra数据库会形式比较大的冗余，而压缩可以用来清除这些冗余，比如进行压缩后只保留多份数据的最新的一份，删除掉打了删除标记的数据。
总体而言：压缩减少了无用数据冗余，合并了有效数据，提高了读效率。