Cassandra在國內資料少，用的也不多，大家更多抱觀望態度吧。
為了擴大Cassandra隊伍幫助自己采坑，決定寫一篇文章，就自己對Cassandra的理解范圍進行介紹。
選用Cassandra的基本原因
- 集群，集群意味着存儲能力、負載能力的平行擴展，多節點提供快速故障轉移，這是主要原因。
- 寫入，Cassandra寫入的能力還是不錯，讀性能正常水平，但是由於原因1，可以使用更多的設備來彌補。
- 單表海量數據的存儲，Cassandra提供分區功能，類似在mysql中分表操作，減少了分表這一層邏輯，但是也帶來了一些限制。
- CQL 類似 SQL，這里是和redis相比，Cassandra的數據操作更加可控，同時自動管理緩存，可以當做mysql + redis用，然而不需要寫兩套代碼，數據可以設置生存時間，相比redis，數據的落地做的更好，更接近mysql這種關系數據庫的數據保障。
- 客戶端，Cassandra提供較完整的客戶端，包括PHP、JAVA、PYTHON、C 等等，而且近一年來（2015）更新頻繁，可以說在技術支持上提供了較好保障。
值得一提的是，Cassandra在PHP提供了異步編程模式，這使得較少涉及異步編程的PHP可以同時處理許多耗時的查詢。 - 技術單一，你只需要一個Cassandra安裝包，就可以完成集群架設，算是非常簡單，這一點是相比HBase。
限制和坑
- Cassandra無法替代MySQL(下面有介紹)，你可能只能在部分業務中使用，可以替換redis 幾乎所有的功能，目前發現就是可排序的計數器還是無法實現。
- 連接過程異常緩慢，即使在沒有賬號密碼驗證的情況下可能也需要幾十ms，基本無法容忍，需要有連接池、長連接的支持，如果你需要在PHP中使用Cassandra，可能需要自己實現一個中間件來避免每次請求的連接或者連接數量龐大的問題。
- 不支持跳頁，也就是limit 100,100，只能limit 100 再用條件看“下一頁”。
- 讀取速度基本和mysql相當，別指望用Cassandra后頁面變快了，不過PHP程序員可以期待一下異步編程帶來的速度提升。前面提到，節點不斷擴展后，整體的集群負載能力是比mysql要高的，新版本mysql7 不算在內，尚未發現有專業人士提供測試對比數據。
- 無法提供非常精確的備份還原點，Cassandra是基於鏡像和增量備份做還原，只能提供有限的還原時間點。
- CQL 不是 SQL，你會遇到一些操作限制，比如排序的時候不能用主鍵的第一級排序 primary key (uid,pid)，只能用pid排序。
- 文檔以英文為主，國內有一些翻譯，但是不完整，也可能是我沒找對地方。許多同行已經在分享Cassandra的寶貴經驗了，stackoverflow會是一個解決問題的好去處。
- 這一點要非常小心 Cassandra保證最終一致性，你會遇到一些並發導致數據短時不一致問題，在計數器的使用的時候，這個問題非常明顯，比如你要將計數器清0，但是可能變成負數，因為有2個進程可能並發請求。這一點可以看另一篇專門介紹計數器的文章。http://www.cnblogs.com/didda/p/4789013.html
對比redis
Cassandra 在操作速度上還是和redis有差距，但是它提供更復雜的數據結構和並發的操作方式，比如你可以給一行數據某些字段加上過期時間，某些字段使用Map結構，另外一些字段像mysql一樣保存text、int、blob數據。這一切都可以在同一個table實現。而在使用redis的時候，你需要更細的規划和管理所有的key，避免有些key在redis中，其他人不知道~~。另外通過合並多種數據類型操作，Cassandra在操作次數上可以比redis減少較多。最后就是你不需要總是寫一個邏輯：
如果一個數據在redis中，就讀redis 返回
否則讀取db，寫入redis，返回
很眼熟吧，Cassandra自己做完這個事了。
PHP開發的一些問題和解決方法
- 連接特別慢，使用swoole 做中間件，保持所有的Cassandra連接，可以解決。
- timeuuid bigint map set 等數據類型在入庫的時候，你需要像強類型語言一樣，指定類型，這個沒有辦法，你可以為每張表寫一個類型映射，進行自動匹配。