摘要
本篇文章主要是介绍cassandra与其他NoSQL的区别以及自身的特点与应用场景。在关系数据库我们没必要选择数据库，通常需要适配oracle/mysql/sql server/db2 等多种数据库。但是今天的NoSQL 还不够成熟，以及每一款的NoSQL 数据库应用领域不是很宽泛，设计理念也有很大差异，所以通常我们需要为我们的应用评估究竟哪款NoSQL数据库比较合适。个人认为各个NoSQL数据库并没有谁好谁差，需要从自己的应用本身出发来考量。
NoSQL比较——华山论剑，谁与争锋
排名
从DB Engines提供的数据可以看出，cassandra目前在NoSQL数据库排名第二，仅次于与MongoDB。所有数据库中排名第七。而且从趋势图中可以看出，cassandra目前处于快速上升阶段.
性能比较
有很多大公司或者学校的科研机构对目前比较流行的NoSQL 做过详细的benchmark.综合来看，cassandra的 insert throughput 有优势，线性扩展很好(貌似最流行的mongoDB在这一方面表现的不是很好)，写操作要优于读操作。但是write，read latency还是比较大,不如其他的NoSQL.具体的读者可以参考下下面的两个链接信息.
http://www.planetcassandra.org/nosql-performance-benchmarks/
http://www.csdn.net/article/2013-04-15/2814886-nosql-benchmark
cassandra案例
cassandra 试用的场景主要有5个方面
1.物联网
物联网应用中有大量的传感器和设备，需要采集环境信息，然后发送给上位机。这些信息都是时间顺序排列的，cassandra非常适合用来存储这些信息。
2.个性化
使用cassandra接收，分析。可以提供快速，低成本，可扩展的用户体验
3.message
最早facebook就是使用cassandra来存储message(不过后期好像替换掉了)
4.欺骗检测
cassandra可以是欺骗分析模式变得更快速，精确，高效
5.列表
产品目录，电影评分，cassandra可以将用户选中的诸多项目作为一个集合存储起来
目前apple拥有最大的cassandra cluster.超过75,000nodes，存储数据达到10PB.不过apple没有关于他们使用cassandra的用途的相关报告。此外netflix 也有2500 nodes的cassandra cluster,netflix 是一家流媒体公司，使用cassandra来储存用户的访问痕迹，以及log数据，能够处理10M transactions/s的并发量。netflix在cassandra的实践过程中，遇到过很多的坑，也诞生了很多优秀的解决方案，他们都通过blog，code等方式开源了一部分出来。，是后续cassandra学习者不可多得的参考资料。
国内cassandra最早的实践者应该是360,用在搜索业务上，超过了1000Nodes.然后还有宜搜一家创业公司，做手机端的搜索，规模也有250Nodes.
总体架构——会当凌绝顶，一览众山小
CAP
在NoSQL领域，CAP理论不可不提的。
C:Consistency 一致性，数据信息保持一致
A:Available 可用性
P:Partition tolerance 集群能够容纳一部分节点/数据分区 down掉的情况发生
CAP 理论指出你不可能想获得一个操作低延迟，同时使CAP 都满足。cassandra 是牺牲了一部分的C，保证
AP.从而降低延迟。当然如果你不在乎延迟，那么在cassandra中你也是可以调整的，使C也得到保证。
Constistency Level
cassandra创建keyspace的时候可以指定数据在cluster中存储几份
create keyspace test with replication={'class':'NetworkTopologyStrategy','replication_factor':3}
RF=3
在cassandra client 端，对于每次的write/read操作都可以分别指定consistency level.
如
consistency level=ONE 表示只要有一份数据返回，就认为操作成功了。
consistency level=quorum,表示只要有(n+1)/2 【向上取整】份数据返回，就认为操作成功了。n
就是上面创建Keyspace 时指定的RF
一般来说，只要保证W+R>N就可以实现一致性。W等于write写操作指定的consistency level.R等于读指定的consistency level.N等于replication_factor
值
上面我们说过，如果你不在乎延迟，那么可以调节。使consistency得到保证。在这里，你可以指定Consistency Level=ALL。
这样就是强一致性。
通过我们的写操作Consistency Level 设置为QUORUM,即超过一半的replication写人成功就认为这次写操作成功。剩下的replication我们不能
保证一定能写入成功。cassandra有其他的机制保证一条记录最终能够一致，及达到RF设置的要求。所以cassandra的一致性又称之为最终一致性。
最终一致性
1.read repair
cassandra去读数据的时候，当有read consistency level 份数据成功返回的时候就认为成功了。但是会有异步操作去检测这条record是不是都存在，如果有个Node上面丢失了这个record，就会去修复。
2.hintedhandoff repair
当某个节点down后，coordinator会将应当写入到这个down node的信息写入到自己本地hinted 文件。当检测到这个节点
恢复了，coordinator会使用hint将这些数据再写入到down node.当然，超过设定的max_hint_window_in_ms时间后，hint
文件就会被删除。down node节点的数据就不会通过这种方式来恢复了。
3.anti-entropy repair
这种方式需要手动执行。nodetool repair.
cassandra 有一个叫Merkle trees 的结构来存储每份复制数据应该保存在哪个节点。
nodetool repair 就是比较发现目前cluster与Merkle trees的差别，然后修复复制数据。
分片
数据分片的技术在关系型数据中就有，就是将相似的数据放在一起，这样查询相似的数据，就可以查询更少的物理节点/分区了，
大大减少了延迟。
cassandra 提供了灵活的分片规则，你可以指定不同的partition key来对数据分片。
默认使用org.apache.cassandra.dht.Murmur3Partitioner来实现。
create table test (
name text,
age int,
address text,
PRIMARY KEY(name,address,age)
);
test 这种表的partition key 就是name 字段，根据name的hash value值在token ring 中的范围，来存储一条记录。
这样一样name的数据会有一样的hash value.就会存储在一个partition中。
参考
http://db-engines.com/en/ranking
http://db-engines.com/en/ranking_trend
http://stackoverflow.com/questions/2892729/mongodb-vs-cassandra