再看Cassandra 之NOSQL 数据库

Cassandra或许不会因为是NoSQL而得到关注,但是它在完成某些特定工作上,有迷人的魅力,这Netflix和Instagram两家公司一定知道。

 
过去的这些年,NoSQL的参与者,例如MongoDB已经得到了快速发展,受到了非常多的关注,但是 Apache Cassandra的光环褪去,作为创造了Cassandra的Facebook已经放弃了它,Cassandra的社区也好像过时了快。但
是Cassandra的命运迎来的转机,Netflix近来决心把他们自己的数据中心的oracle改成Cassandra Amazon云。不久
以后,Facebook也再次开始使用Cassandra,而Twitter和WebEx都不同程度的使用着Cassandra.
 
Cassandra的一个大问题在于它太个性,好像不好把它进行分类,虽然类似HBase,它是一个Column-family数据库,但是它却有很大的独得性。它跟文档NoSQL数据库也是不同的类别例如MongoDB或Couchbase,或key-value-pair数据库DynamoDB,Redis,Riak,等等都不一样,它自成一类。
 
什么是cloumn-family数据库?
 
一个column-family数据库它按行关键字来存储数据,它非常类似一张表,跟人们熟悉的关系数据库的表很容易混淆,尤其是自从google著名的column-family应用被称为BigTable以后,人们更容易把column的存储结构与关系数据库下的表相混淆了,但是一定要注意此表非彼表。
 
首先,他们基本上缺少架构schema,架构可以让你很容易的添加你想添加的列(但是你需要考虑存储优化,数据分布等问题),在Cassandra里,表的关键字不紧紧围了方便查找,它可以允许系统有效的在集群上对数据分片,看下面标准的column family结构吧,它看起来非常类似JSON.
 
ColumnFamilyName {

rowkey1 = {column1:"value1", column2:"value2"},

rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"},

rowkey3 = {column2:"value3.2", column3:"value3.3"},

rowkey4 = {column1:"value4.1", column3:"value4.3"}

}
 
上面是标准的column family数据库数据存储结构,看起来有一定的局限性,但是作为补充,它还包括一个超级列的概念,类似下面的结构:
 
SuperColumnFamily {

ColumnFamily1 {

cf1rowkey1 = {column1:"value1", column2:"value2"},

cf1rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"},

cf1rowkey3 = {column2:"value3.2", column3:"value3.3"},

cf1rowkey4 = {column1:"value4.1", column3:"value4.3"}

},

ColumnFamily2 {

cf2rowkey1 = {column1:"value1", column2:"value2"},

cf2rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"},

cf2rowkey3 = {column2:"value3.2", column3:"value3.3"},

cf2rowkey4 = {column1:"value4.1", column3:"value4.3"}

}

}
 
 
另外你还可以找到另外几种结构,例如composite columns和其他类型的列,包括静态和动态列等等。还有些特殊的列类型包括计数列,时间戳列等。
 
 
什么情况下使用Cassandra?
 
一,时间类型的数据
 
       时间类型的数据包括任何温度传感器,工作日志,或股票价格数据等,也包括博客数据,电影片段数据等等,这些数据被证明如果使用文档数据库例如MongoDB会导致失败。
 
二,产品目录
 
三,信息过滤系统的子系统信息推荐系统-Recommendations
 
四,诈骗与垃圾信息侦听系统
 
五,后端的大数据存储系统
 
        应该说后台数据库存储系统,用Cassandra的地方不是太多,主要是应用它的缓存功能全局网数据复制
        的能力,如果你需要异地备份双活数据库的话,你可以使用下Cassandra.
 
 Cassandra与Hbase
 
 Cassandra有自己的优点和缺点,正如Hbase一样,它们都有各自的使用场合两者都在Hadoop生态下,Cassandra用来对读写进行高复合工作,而对毫秒级的数据一致性不是太擅长,而HBase则可以弥补这些,从更大的范围讲,Cassandra适合业务系统,而HBase则更多的用在数据仓库和事务场景的系统上。
 
说说事务......
 
 开发人员经常困惑什么时候才真正的需要原子级别的一致性,同样如果你开始使用RDBMS,你也会困惑,因为关系型数据库经常需要跨越多个地点收集相同的一组数据。这样一个人的信息可能被打乱放到了多个表中,因为它们有不同的电话好吗,有不同的地址等等,这样就引出-好的数据库架构到底是什么样的?
 
 在现在的任何系统之下,你都需要对数据一致性进行妥协,因为无论你使用什么类型的数据库,都不可能提供长时间运行的事务(足够轻量级的可以满足互联网应用级的要求),因为没有人可以在信息持久话的模式下做操作,而且每个用户对应一个连接,而事务则经常打断用户的操作,影响用户的体验,这就是进行原子级的数据一致性的代价。
 
但是在很多情况下,一毫秒甚至500毫秒不会有太多的不同,如果我修改了一些行关键字,最终Cassandra会进行持久话,那么我就可以进行读操作,可能这读操作是虚拟读。这里的问题在于,你不会关注一个短暂的错误,例如你正在看电影,发现里面的片段少了,没有数据加载,但是紧紧一会后,你再次单击那部电影,恢复正常了,可以正常观看了,这里你不太会太在意,你在意的是,每当电影目录被更新,你的操作都会被奇怪的中断,所以当前在互联网级的应用上,你需要在性能和系统规模及数据一致性之间做出妥协,有的时候,一致性跟性能及规模来说并不是过于重要。
 
                                                                                                                                                             翻译文章
   

 

再看Cassandra 之NOSQL 数据库,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。