摘要
本篇文章主要是介紹cassandra與其他NoSQL的區(qū)別以及其身的特點與應用場景梆砸。在關系數(shù)據(jù)庫我們沒必要選擇數(shù)據(jù)庫趴俘,通常需要適配oracle/mysql/sql server/db2 等多種數(shù)據(jù)庫。但是今天的NoSQL 還不夠成熟抒痒,以及每一款的NoSQL 數(shù)據(jù)庫應用領域不是很寬泛按声,設計理念也有很大差異,所以通常我們需要為我們的應用評估究竟哪款NoSQL數(shù)據(jù)庫比較合適掖桦。個人認為各個NoSQL數(shù)據(jù)庫并沒有誰好誰差,需要從自己的應用本身出發(fā)來考量供汛。
NoSQL比較——華山論劍,誰與爭鋒
排名
從DB Engines提供的數(shù)據(jù)可以看出涌穆,cassandra目前在NoSQL數(shù)據(jù)庫排名第二怔昨,僅次于與MongoDB。所有數(shù)據(jù)庫中排名第七宿稀。而且從趨勢圖中可以看出趁舀,cassandra目前處于快速上升階段.
性能比較
有很多大公司或者學校的科研機構(gòu)對目前比較流行的NoSQL 做過詳細的benchmark.綜合來看,cassandra的 insert throughput 有優(yōu)勢祝沸,線性擴展很好(貌似最流行的mongoDB在這一方面表現(xiàn)的不是很好)矮烹,寫操作要優(yōu)于讀操作越庇。但是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.物聯(lián)網(wǎng)
物聯(lián)網(wǎng)應用中有大量的傳感器和設備奉狈,需要采集環(huán)境信息卤唉,然后發(fā)送給上位機。這些信息都是時間順序排列的仁期,cassandra非常適合用來存儲這些信息桑驱。
2.個性化
使用cassandra接收,分析跛蛋“镜模可以提供快速,低成本赊级,可擴展的用戶體驗
3.message
最早facebook就是使用cassandra來存儲message(不過后期好像替換掉了)
4.欺騙檢測
cassandra可以是欺騙分析模式變得更快速押框,精確,高效
5.列表
產(chǎn)品目錄理逊,電源評分强戴,cassandra可以將用戶選中的諸多項目作為一個集合存儲起來
目前apple擁有最大的cassandra cluster.超過75,000nodes,存儲數(shù)據(jù)達到10PB.不過apple沒有關于他們使用cassandra的用途的相關報告挡鞍。此外netflix 也有2500 nodes的cassandra cluster,netflix 是一家流媒體公司骑歹,使用cassandra來儲存用戶的訪問痕跡,以及l(fā)og數(shù)據(jù)墨微,能夠處理10M transactions/s的并發(fā)量道媚。netflix在cassandra的實踐過程中,遇到過很多的坑翘县,也誕生了很多優(yōu)秀的解決方案最域,他們都通過blog,code等方式開源了一部分出來锈麸。镀脂,是后續(xù)cassandra學習者不可多得的參考資料。
國內(nèi)cassandra最早的實踐者應該是360,用在搜索業(yè)務上忘伞,超過了1000Nodes.然后還有宜搜一家創(chuàng)業(yè)公司薄翅,做手機端的搜索,規(guī)模也有250Nodes.
總體架構(gòu)——會當凌絕頂氓奈,一覽眾山小###
CAP
在NoSQL領域翘魄,CAP理論不可不提的。
C:Consistency 一致性舀奶,數(shù)據(jù)信息保持一致
A:Available 可用性
P:Partition tolerance 集群能夠容納一部分節(jié)點/數(shù)據(jù)分區(qū) down掉的情況發(fā)生
CAP 理論指出你不可能想獲得一個操作低延遲暑竟,同時使CAP 都滿足。cassandra 是犧牲了一部分的C育勺,保證
AP.從而降低延遲但荤。當然如果你不在乎延遲罗岖,那么在cassandra中你也是可以調(diào)整的,使C也得到保證腹躁。
Constistency Level
cassandra創(chuàng)建keyspace的時候可以指定數(shù)據(jù)在cluster中存儲幾份
create keyspace test with replication={'class':'NetworkTopologyStrategy','replication_factor':3}
RF=3
在cassandra client 端桑包,對于每次的write/read操作都可以分別指定consistency level.
如
consistency level=ONE 表示只要有一份數(shù)據(jù)返回,就認為操作成功了潜慎。
consistency level=quorum,表示只要有(n+1)/2 【向上取整】份數(shù)據(jù)返回捡多,就認為操作成功了。n
就是上面創(chuàng)建Keyspace 時指定的RF
一般來說铐炫,只要保證W+R>N就可以實現(xiàn)一致性垒手。W等于write寫操作指定的consistency level.R等于讀指定的consistency level.N等于replication_factor
值
上面我們說過,如果你不在乎延遲倒信,那么可以調(diào)節(jié)科贬。使consistency得到保證。在這里鳖悠,你可以指定Consistency Level=ALL榜掌。
這樣就是強一致性。
通過我們的寫操作Consistency Level 設置為QUORUM,即超過一半的replication寫人成功就認為這次寫操作成功乘综。剩下的replication我們不能
保證一定能寫入成功憎账。cassandra有其他的機制保證一條記錄最終能夠一致,及達到RF設置的要求卡辰。所以cassandra的一致性又稱之為最終一致性胞皱。
最終一致性
1.read repair
cassandra去讀數(shù)據(jù)的時候,當有read consistency level 份數(shù)據(jù)成功返回的時候就認為成功了九妈。但是會有異步操作去檢測這條record是不是都存在反砌,如果有個Node上面丟失了這個record,就會去修復萌朱。
2.hintedhandoff repair
當某個節(jié)點down后宴树,coordinator會將應當寫入到這個down node的信息寫入到自己本地hinted 文件。當檢測到這個節(jié)點
恢復了晶疼,coordinator會使用hint將這些數(shù)據(jù)再寫入到down node.當然酒贬,超過設定的max_hint_window_in_ms時間后,hint
文件就會被刪除冒晰。down node節(jié)點的數(shù)據(jù)就不會通過這種方式來恢復了同衣。
3.anti-entropy repair
這種方式需要手動執(zhí)行。nodetool repair.
cassandra 有一個叫Merkle trees 的結(jié)構(gòu)來存儲每份復制數(shù)據(jù)應該保存在哪個節(jié)點壶运。
nodetool repair 就是比較發(fā)現(xiàn)目前cluster與Merkle trees的差別,然后修復復制數(shù)據(jù)浪秘。
分片
數(shù)據(jù)分片的技術(shù)在關系型數(shù)據(jù)中就有蒋情,就是將相似的數(shù)據(jù)放在一起埠况,這樣查詢相似的數(shù)據(jù),就可以查詢更少的物理節(jié)點/分區(qū)了棵癣,
大大減少了延遲辕翰。
cassandra 提供了靈活的分片規(guī)則,你可以指定不同的partition key來對數(shù)據(jù)分片狈谊。
默認使用org.apache.cassandra.dht.Murmur3Partitioner來實現(xiàn)喜命。
create table test (
name text,
age int,
address text,
PRIMARY KEY(name,address,age)
);
test 這種表的partition key 就是name 字段,根據(jù)name的hash value值在token ring 中的范圍河劝,來存儲一條記錄壁榕。
這樣一樣name的數(shù)據(jù)會有一樣的hash value.就會存儲在一個partition中。
參考
http://db-engines.com/en/ranking
http://db-engines.com/en/ranking_trend
http://stackoverflow.com/questions/2892729/mongodb-vs-cassandra