[轉載] Cassandra入門 框架模型 總結

轉載自http://asyty.iteye.com/blog/1202072

1、Cassandra框架
2、Cassandra數據模型
Colum / Colum Family, SuperColum / SuperColum Family
Colum排序
3、分區策略
Token，Partitioner
bloom-filter，HASH
4、副本存儲
5、網絡嗅探
6、一致性
Quorum NRW
維護最終一致性
7、存儲機制
CommitLog
MenTable

SSTable
附

 

1、Cassandra框架

圖1  Cassandra

Cassandra是社交網絡理想的數據庫，適合於實時事務處理和提供交互型數據。以Amazon的徹底分佈式的Dynamo爲基礎，結合了Google BigTable基於列族（Column Family）的數據模型，P2P去中心化的存儲，目前twitter和digg中都有使用。

在CAP特性上，HBase選擇了CP，Cassandra更傾向於AP，而在一致性上有所減弱。

Cassandra的類Dynamo特性有如下幾點：

l 對稱的，P2P架構

n 無特殊節點，無單點故障

l 基於Gossip的分佈式管理

l 經過分佈式hash表放置數據

n 可插拔的分區

n 可插拔的拓撲發現

n 可配置的放置策略

l 可配置的，最終一致性

 

類BigTable特性：

l 列族數據模型

n 可配置，2級maps，Super Colum Family

l SSTable磁盤存儲

n Append-only commit log

n Mentable (buffer and sort)

n 不可修改的SSTable文件

l 集成Hadoop

2、 Cassandra數據模型

Colum / Colum Family, SuperColum / SuperColum Family

Column是數據增量最底層（也就是最小）的部分。它是一個包含名稱（name）、值（value）和時間戳（timestamp）的三重元組。

下面是一個用JSON格式表示的column：

{  // 這是一個Column

name: "emailAddress", 

value: "arin@example.com",

timestamp: 123456789  

}       

須要注意的是，name和value都是二進制的（技術上指byte[]），而且能夠是任意長度。

與HBase相比，除了Colum/Colum Family外，Cassandra還支持SuperColum/SuperColum Family。

SuperColum與Colum的區別就是，標準Column的value是一個「字符串」，而 SuperColumn的value是一個包含多個Column的map，另外一個細微的差異是：SuperColumn沒有時間戳。

{ // 這是一個SuperColumn 

name: "homeAddress",

// 無限數量的Column   

value: { 

street: {name: "street", value: "1234 x street", timestamp: 123456789},

city: {name: "city", value: "san francisco", timestamp: 123456789}, 

zip: {name: "zip", value: "94107", timestamp: 123456789},

}

}

Column Family（CF）是某個特定Key的Colum集合，是一個行結構類型，每一個CF物理上被存放在單獨的文件中。從概念上看，CF像數據庫中的Table。

SuperColum Family概念上和Column Family（CF）類似，只不過它是Super Colum的集合。

 

Colum排序

不一樣於數據庫能夠經過Order by定義排序規則，Cassandra取出的數據順序是老是必定的，數據保存時已經按照定義的規則存放，因此取出來的順序已經肯定了。另外，Cassandra按照column name而不是column value來進行排序。

Cassandra能夠經過Colum Family的CompareWith屬性配置Colume值的排序，在SuperColum中，則是經過SuperColum Family的CompareSubcolumnsWith屬性配置Colum的排序。

Cassandra提供瞭如下一些選：BytesType，UTF8Type，LexicalUUIDType，TimeUUIDType，AsciiType， Column name識別成爲不一樣的類型，以此來達到靈活排序的目的。

3、分區策略

Token，Partitioner

Cassandra中，Token是用來分區數據的關鍵。每一個節點都有一個第一無二的Token，代表該節點分配的數據範圍。節點的Token造成一個Token環。例如使用一致性HASH進行分區時，鍵值對將根據一致性Hash值來判斷數據應當屬於哪一個Token。

 

          圖3 Token Ring

 

分區策略的不一樣，Token的類型和設置原則也有所不一樣。 Cassandra (0.6版本)自己支持三種分區策略：

RandomPartitioner：隨機分區是一種hash分區策略，使用的Token是大整數型(BigInteger)，範圍爲0~2^127，Cassandra採用了MD5做爲hash函數，其結果是128位的整數值(其中一位是符號位，Token取絕對值爲結果)。所以極端狀況下，一個採用隨機分區策略的Cassandra集羣的節點能夠達到2^127+1個節點。採用隨機分區策略的集羣沒法支持針對Key的範圍查詢。

OrderPreservingPartitioner：若是要支持針對Key的範圍查詢，那麼能夠選擇這種有序分區策略。該策略採用的是字符串類型的Token。每一個節點的具體選擇須要根據Key的狀況來肯定。若是沒有指定InitialToken，則系統會使用一個長度爲16的隨機字符串做爲Token，字符串包含大小寫字符和數字。

CollatingOrderPreservingPartitioner：和OrderPreservingPartitioner同樣是有序分區策略。只是排序的方式不同，採用的是字節型Token，支持設置不一樣語言環境的排序方式，代碼中默認是en_US。

分區策略和每一個節點的Token(Initial Token)均可以在storage-conf.xml配置文件中設置。

 

bloom-filter, HASH

Bloom Filter是一種空間效率很高的隨機數據結構，本質上就是利用一個位數組來表示一個集合，並能判斷一個元素是否屬於這個集合。Bloom Filter的這種高效是有偏差的：在判斷一個元素是否屬於某個集合時，有可能會把不屬於這個集合的元素誤認爲屬於這個集合（false positive）。所以，Bloom Filter不適合那些「零錯誤」的應用場合，而在能容忍低錯誤率的場合下，Bloom Filter經過極少的錯誤換取了存儲空間的極大節省。

原理：位數組 + K個獨立hash（y）函數。將位數組中hash函數對應的值的位置設爲1，查找時若是發現全部hash函數對應位都是1說明存在，很明顯這個過程並不保證查找的結果是徹底正確的。

 

在Cassandra中，每一個鍵值對使用1Byte的位數組來實現bloom-filter。

 

 

圖4 Bloom Filter

 

4、副本存儲

Cassandra不像HBase是基於HDFS的分佈式存儲，它的數據是存在每一個節點的本地文件系統中。

Cassandra有三種副本配置策略：

1) SimpleStrategy （RackUnawareStrategy）：

副本不考慮機架的因素，按照Token放置在連續下幾個節點。如圖3所示，假如副本數爲3，屬於A節點的數據在B.C兩個節點中也放置副本。

2) OldNetworkTopologyStrategy （RackAwareStrategy）:

考慮機架的因素，除了基本的數據外，先找一個處於不一樣數據中心的點放置一個副本，其他N-2個副本放置在同一數據中心的不一樣機架中。

3)  NetworkTopologyStrategy （DatacenterShardStrategy）：

將M個副本放置到其餘的數據中心，將N-M-1的副本放置在同一數據中心的不一樣機架中。

5、網絡嗅探

網絡嗅探主要用來計算不一樣host的相對距離，進而告訴Cassandra網絡拓撲結構，以便更高效地對用戶請求進行路由。主要有三種配置策略：

1)       org.apache.cassandra.locator.SimpleSnitch：

將不一樣host邏輯上的距離（Cassandra Ring）做爲他們之間的相對距離。

2)       org.apache.cassandra.locator.RackInferringSnitch:

相對距離是由rack和data center決定的，分別對應ip的第3和第2個八位組。即，若是兩個節點的ip的前3個八位組相同，則認爲它們在同一個rack（同一個rack中不一樣節點，距離相同）；若是兩個節點的ip的前兩個八位組相同，則認爲它們在同一個數據中心（同一個data center中不一樣節點，距離相同）。

3)       org.apache.cassandra.locator.PropertyFileSnitch:

相對距離是由rack和data center決定的，且它們是在配置文件cassandra-topology.properties中設置的。

6、一致性

在一致性上，Cassandra採用了最終一致性，能夠根據具體狀況來選擇一個最佳的折衷，來知足特定操做的需求。Cassandra可讓用戶指定讀/插入/刪除操做的一致性級別，一致性級別有多種，如圖5所示。

 

 圖5  Cassandra一致性級別

 

注：一致性級別是由副本數決定，而不是集羣的節點數目決定。

 

Quorum NRW

 

• N: 複製的節點數量，即副本數
• R: 成功讀操做的最小節點數
• W: 成功寫操做的最小節點數

Quorum協議中，R 表明一次成功的讀取操做中最小參與節點數量，W 表明一次成功的寫操做中最小參與節點數量。R + W>N ，則會產生相似quorum 的效果。該模型中的讀(寫)延遲由最慢的 R(W)複製決定，爲獲得比較小的延遲，R和W有的時候的和比N小。

Quorum協議中，只需W + R > N，就能夠保證強一致性。由於讀取數據的節點和被同步寫入的節點是有重疊的。在一個RDBMS的複製模型中（Master/salve)，假如N=2,那麼W=2,R=1此時是一種強一致性,可是這樣形成的問題就是可用性的減低，由於要想寫操做成功，必需要等 2個節點的寫操做都完成之後才能夠。

在分佈式系統中，通常都要有容錯性，所以N通常大於3的，此時根據CAP理論，咱們就須要在一致性和分區容錯性之間作一平衡，若是要高的一致性，那麼就配置N=W，R=1,這個時候可用性就會大大下降。若是想要高的可用性，那麼此時就須要放鬆一致性的要求，此時能夠配置W=1，這樣使得寫操做延遲最低，同時經過異步的機制更新剩餘的N-W個節點。

當存儲系統保證最終一致性時，存儲系統的配置通常是W+R<=N，此時讀取和寫入操做是不重疊的，不一致性的窗口就依賴於存儲系統的異步實現方式，不一致性的窗口大小也就等於從更新開始到全部的節點都異步更新完成之間的時間。

通常來講，Quorum中比較典型的NRW爲（3,2,2）。

 

維護最終一致性

Cassandra 經過4個技術來維護數據的最終一致性，分別爲逆熵（Anti-Entropy），讀修復（Read Repair），提示移交（Hinted Handoff）和分佈式刪除。

1)       逆熵

這是一種備份之間的同步機制。節點之間按期互相檢查數據對象的一致性，這裏採用的檢查不一致的方法是 Merkle Tree；

2)       讀修復

客戶端讀取某個對象的時候，觸發對該對象的一致性檢查：

讀取Key A的數據時，系統會讀取Key A的全部數據副本，若是發現有不一致，則進行一致性修復。

若是讀一致性要求爲ONE，會當即返回離客戶端最近的一份數據副本。而後會在後臺執行Read Repair。這意味着第一次讀取到的數據可能不是最新的數據；若是讀一致性要求爲QUORUM，則會在讀取超過半數的一致性的副本後返回一份副本給客戶端，剩餘節點的一致性檢查和修復則在後臺執行；若是讀一致性要求高(ALL)，則只有Read Repair完成後才能返回一致性的一份數據副本給客戶端。可見，該機制有利於減小最終一致的時間窗口。

3)       提示移交

對寫操做，若是其中一個目標節點不在線，先將該對象中繼到另外一個節點上，中繼節點等目標節點上線再把對象給它：

Key A按照規則首要寫入節點爲N1，而後複製到N2。假如N1宕機，若是寫入N2能知足ConsistencyLevel要求，則Key A對應的RowMutation將封裝一個帶hint信息的頭部（包含了目標爲N1的信息），而後隨機寫入一個節點N3，此副本不可讀。同時正常複製一份數據到N2，此副本能夠提供讀。若是寫N2不知足寫一致性要求，則寫會失敗。 等到N1恢復後，本來應該寫入N1的帶hint頭的信息將從新寫回N1。

4)       分佈式刪除

單機刪除很是簡單，只須要把數據直接從磁盤上去掉便可，而對於分佈式，則不一樣，分佈式刪除的難點在於：若是某對象的一個備份節點 A 當前不在線，而其餘備份節點刪除了該對象，那麼等 A 再次上線時，它並不知道該數據已被刪除，因此會嘗試恢復其餘備份節點上的這個對象，這使得刪除操做無效。Cassandra 的解決方案是：本地並不當即刪除一個數據對象，而是給該對象標記一個hint，按期對標記了hint的對象進行垃圾回收。在垃圾回收以前，hint一直存在，這使得其餘節點能夠有機會由其餘幾個一致性保證機制獲得這個hint。Cassandra 經過將刪除操做轉化爲一個插入操做，巧妙地解決了這個問題。

7、存儲機制

Cassandra的存儲機制借鑑了Bigtable的設計，採用Memtable和SSTable的方式。

 

CommitLog

和HBase同樣，Cassandra在寫數據以前，也須要先記錄日誌，稱之爲Commit Log，而後數據纔會寫入到Column Family對應的MemTable中，且MemTable中的數據是按照key排序好的。SSTable一旦完成寫入，就不可變動，只能讀取。下一次Memtable須要刷新到一個新的SSTable文件中。因此對於Cassandra來講，能夠認爲只有順序寫，沒有隨機寫操做。

 

MenTable

MemTable是一種內存結構，當數據量達到塊大小時，將批量flush到磁盤上，存儲爲SSTable。這種機制，至關於緩存寫回機制(Write-back Cache)，優點在於將隨機IO寫變成順序IO寫，下降大量的寫操做對於存儲系統的壓力。因此咱們能夠認爲Cassandra中只有順序寫操做，沒有隨機寫操做。

 

SSTable

SSTable是Read Only的，且通常狀況下，一個CF會對應多個SSTable，當用戶檢索數據時，Cassandra使用了Bloom Filter，即經過多個hash函數將key映射到一個位圖中，來快速判斷這個key屬於哪一個SSTable。

爲了減小大量SSTable帶來的開銷，Cassandra會按期進行compaction，簡單的說，compaction就是將同一個CF的多個SSTable合併成一個SSTable。在Cassandra中，compaction主要完成的任務是：

1） 垃圾回收： cassandra並不直接刪除數據，所以磁盤空間會消耗得愈來愈多，compaction 會把標記爲刪除的數據真正刪除；

2） 合併SSTable：compaction 將多個 SSTable 合併爲一個（合併的文件包括索引文件，數據文件，bloom filter文件），以提升讀操做的效率；

3） 生成 MerkleTree：在合併的過程當中會生成關於這個 CF 中數據的 MerkleTree，用於與其餘存儲節點對比以及修復數據。

 

詳細存儲數據結構參考 http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu2

附

單體、模塊化

Cassandra和HBase的一個重要區別是， Cassandra在每一個節點是是一個單 Java 進程，而完整的HBase 解決方案卻由不一樣部分組成：有數據庫進程自己，它可能會運行在多個模式；一個配置好的 hadoop HDFS 分佈式文件系統，以及一個 Zookeeper 系統來協調不一樣的 HBase 進程。