http://www.cnblogs.com/LBSer/p/3328841.html
9月初聽了一個講座，演講者是張月同學，他給我們分享了Cassandra nosql資料庫，講得很精彩，聽完之後收益良多。
Cassandra是一個noSQL資料庫，在國外被廣泛使用，比如FaceBook、Twitter、Intel等，國內用的較少，只有奇虎360等公司在大規模使用。張月首先講了Cassandra怎麼來的，之後講了Cassandra的一些具體細節，讓我印象比較深刻的有資料分佈以及通訊協議兩個部分，最後講了Cassandra的效率以及使用情況。
1. Cassandra怎麼來的
他山之石可以攻玉，Cassandra從Dynamo和BigTable中借鑑了相應的思想。
|
類似Dynamo的特性 |
類似bigTable的特性 |
|
對稱、P2P的結構，沒有主節點 |
稀疏、列儲存模型 |
|
基於 Gossip的叢集管理 |
commit log，記憶體有 MemTable，SSTable Files |
|
分散式哈西表 |
支援Hadoop |
|
最終一致性 |
|
2. Cassandra中的資料是怎樣分佈的？
1.2版本之前使用的是普通一致性哈西演算法，如圖上部所示，一共6個節點，每個節點計算Hash值a，之後各個節點根據各自的hash值對映到一段區間上，比如Node1對應著A，此外，各個節點儲存著其它節點的兩個副本，比如Node1還儲存著Node5的E，以及Node6的F。
普通的一致性哈西有個缺點，當增加或刪除節點時會導致資料分佈不均衡，比如Node2當機後，原先Node2的資料全部分佈到Node3上，造成Node3的資料量大大多餘其它節點；同理，當在區間B插入一個節點Node7時，會使得Node2和Node7的資料量大大小於其它節點。
為了解決上述問題，1.2版本使用帶有虛擬節點的一致性哈西演算法，如圖下部所示，一共6個節點，每個節點需要計算兩次hash，首先與傳統一樣計算Hash值a，然後根據這個值a計算多個hash值a1,a2,a3...，即將一個節點對映到多個hash值，從而每個節點不再僅僅對應一個區間，而是對應著許多小區間，如果保證各個hash值是隨機的，則能使得這些小區間的分佈也是隨機的，從而確保了資料分佈的均衡性
3. Gossip協議管理叢集
每隔T秒，叢集中各個節點將都會將自己的Heartbeat資訊通過Gossip傳遞給其他節點。Gossip協議效率較高，只需要Log(N)次就能將所有節點狀態資訊傳遞給各個節點。
4. Cassandra的效率以及使用情況
張月給了張圖，上面顯示Cassandra讀寫速度遠遠大於Hbase和MongoDB，但是也有很多人質疑這個圖，因為他沒有給出這張圖的實驗條件，比如多大資料量，各個資料庫是否在同一叢集上等等。不過我後來檢視了些文獻，發現Cassandra的效能還是很不錯的。
5. 討論
會後有個問題：既然Cassandra效能這麼出色， 為什麼國內很少有公司使用Cassandra？ 為什麼國外的facebook和twitter等都棄用Cassandra而轉用HBase了，Cassandra有什麼不足？
張月的回答是國內的宣傳不夠，至於facebook和twitter為什麼轉用HBase，可能和HBase天生支援Hadoop有關係，可以結合mapreduce，雖然Cassandra也支援Hadoop，但是配置起來特別麻煩。
後來我網上查了下，Cassandra還是有一些缺點，或許因為這些使得很多大公司轉向HBase。
a）Cassandra來源自Facebook，但是在Facebook內部Cassandra 目前只用在inbox search產品上，容量大約有一兩百T，且Inbox Search在Facebook的也不是核心應用；
b）Cassandra出身較晚，自身還存在不少問題。