Cassandra的读写以及应用业务场景分析

分布式存储系统都要面临CAP定律问题，任何一个分布式存储系统不可能同时满足一致性(consistency)，可用性(availability)和分区容错性(partition tolerance)。Cassandra是优先保证AP，即可用性和分区容错性。

Cassandra高效写操作
写入操作非常高效，这对于实时数据非常大的应用场景，Cassandra的这一特性无疑极具优势。
数据读取方面则要视情况而定：

如果是单个读取即指定了键值，会很快的返回查询结果。
如果是范围查询，由于查询的目标可能存储在多个节点上，这就需要对多个节点进行查询，所以返回速度会很慢
读取全表数据，非常低效。

Cassandra 高可靠性
  Cassandra采用gossip作为集群中结点的通信协议，该协议整个集群中的节点都处于同等地位，没有主从之分，这就使得任一节点的退出都不会导致整个集群失效。
  Cassandra和HBase都是借鉴了Google BigTable的思想来构建自己的系统，但Cassandra另一重要的创新就是将原本存在于文件共享架构的p2p(peer to peer)引入了NoSQL。
  P2P的一大特点就是去中心化，集群中的所有节点享有同等地位，这极大避免了单个节点退出而使整个集群不能工作的可能。
  与之形成对比的是HBase采用了Master/Slave的方式，这就存在单点失效的可能。

Cassandra高可扩性
  随着时间的推移，集群中原有的规模不足以存储新增加的数据，此时进行系统扩容。Cassandra级联可扩，非常容易实现添加新的节点到已有集群，操作简单。

----------------------------------------------------------------------------------------------------------------------------------------------------------

对Cassandra数据库试着写对数据分页展示的程序。有一个需求是要计算出某查询条件下数据库里有多少条数据。
直接用count()函数做，在数据量小的时候是没问题的。对性能也没有太明显的影响。
然而当我试着往Cassandra里面插入十万条数据的时候，数据就加载不出来了，直接各种报错。
试着在cql命令行下使用
select count(*) from tableName;
直接就报超时错误了：

Cassandra的读写以及应用业务场景分析

可以通过修改配置文件提高 timeout 时间的方式来解决 Timeout

但是从根本上来说 Cassandra 并不适合做这样的业务场景。

Cassandra 本身不适合用来做数据分析统计，比如 count，是需要去遍历数据库的，分布式数据库，那么就要通通遍历一次。

Cassandra 更适合多写，做一些简单查询，如果是偏分析类的场景，要么做成延时任务，要么用 Spark 或者 Hadoop 来做。

Cassandra的读写以及应用业务场景分析

相关推荐