又稱為 C＊，是鍵值對和欄式結合的分散式料庫系統，此資料庫是使用 Java 語言。
New Study update on 2020/2/27, see https://github.com/QueenieCplusplus/DataMining_Cassandra/blob/master/README2.md
在 DB-Engines 中，Cassandra 是 noSQL 資料庫中排名第 2 高的（僅次於 MongoDB ）。
2007 年由臉書團隊為了解決收件箱太多資料要處理，但需要擴張的問題，從而設計讓資料得以複製與修改，且能隨時讀寫的後端資料庫系統架構，直至 2011年方才成熟。
目前貢獻的遞交者包含蘋果、LinkedIn、Twitter 和獨立開發者。
在 Cassandra 的早期版本，其忠實呈現了 Google BigTable 或是 Hadoop (Wide-Column) 和 AWS DynamoDB (Key) 的資料模型。 無綱要 No-Schema 的資料模型代表著，其能動態地定義欄位 Column，但一體兩面的是缺點則暴露在很難決定資料的意義與格式，然而當資料變得很龐大的時候，則體現其擴展性的優點。
NoSQL 包含 sharding 擴展性的高度容錯、sort & search 查詢效能、de-centralize 分散式作業的三大特性，Cassandra 自然是具備的。
分散式架構主要特點當然是與主從式不同，它不具有集中管理者，每個 node 或每個 cluster 的功能和權限都是一樣的。
傳統的 SQL 這種關聯性資料庫，一旦遇到大量資料部署和擴張，大開大合的情境，會讓關聯性資料庫受窘迫，因為要維持交易的 ACID，則共享資源為了避免競奪，勢必會在某情況中符合某一條件下，將其資源上鎖，這會造成無法忍受的等待，和使用者極差的感受。
但是一但橫向擴展設備，每台機器或是虛擬機完成不同任務，又要協調和整合其任務結果，保持一制性又要保持效能性，需要在兩者之間取得雙贏和平衡。
這樣就會讓系統架構師需要做到 2PC, 2 process commit 跨節點的協調以及分散式架構中的補償機制。（補充說明：補償機制即交易作業仍然維持已經遞交的狀態，但是交易成功與否，仍能以回滾方式取消。）
這類架構首先由 eBay 所採用，可以支撐到一天十億次的查詢情境。分片是將資料橫向拆分，座落在不同主機或是叢集中作業，各自獨立作業。
採取分片策略後，需要挑選一個好的主鍵，藉此排序資料。
分片策略具有的優勢特點是：最小化資源共用的風險以及可進行資源擴展。
關聯性資料庫固然在很多時候，也真的算上是時代性解決方案的最大贏家，但他僅僅解決某類型的資料存儲問題，由於集中性遇到大量資料需要擴展時，會需要備份和取消彼此的連結操作以避免被鎖死，這就是資料去中心化的原因囉！
- Decentralize, 去中心化
所謂的分散式架構，是指可以同時運行在多個節點上一同提供服務，且使用者不會有感受到任何差異。跟主從式 C/S 架構相比的話，主從架構分為主 master 與 從屬的副 slave 節點，而 cassandra 的去中心化，使得 cluster (叢集) 中每個 node 節點地位皆同，每個節點都執行與其他節點相同的工作任務。而節點彼此之間的通訊協定則使用點對點和 gossip 機制以維護結點間的相關資訊。
Cassandra 的去中心化架構也讓單點失效的發生情況無所遁形， Cassandra 中所有節點的功能都相同，此稱為[對稱服務]，因為所有節點都執行相同的工作任務，也無需特殊節點協調節點間的活動。
許多分散式解決方案中，如 RDBMS 叢集會將一份資料的多份副本存在在不同節點上，稱為 Replica，也因為同一份資料存放在多個節點上，倘若客戶端請求這份資料，因為叢集中的任一個節點皆可提供服務，如此便可有效的提升效能。但 RDBMS 協調彼此節點間的工作任務並不是以去中心化的方式完成，而是透過主/從 S/C 架構的方式進行的，此情況下的節點彼此的地位不同，也擁有不同的工作任務，分成主/副 master/slave 節點，主節點被定義為可信賴的資料來源端，並且協調同步 sync 副節點的副本資料，此架構下，若發生主節點失效，則整個資料庫將陷於危機，然而 noSQL 的 MongoDB 其實也使用主從架構進行任務分配。
- Scale Up, 高效擴展
擴展性式系統的架構能否持續提供服務的標準指標，具備良好擴展性的系統在持續服務更多需求的情況下也部會降低太多的效能。
擴展的向量分為水平的橫向 horizontal scaling 與垂直的縱向擴展 vertical scaling，前者是增加更多的 node ，藉以提供服務，而後者則是在同一節點上增添更多硬體設備如硬體的記憶體和存儲空間，其中前者的橫向擴展，要求軟體應用層建立某種資料 sync 同步機制！
業界中提及的彈性擴展，指的是橫向擴展能力，叢集可以無縫的增減 node，且免 downtime（無須中斷服務和重啟伺服器），即可加入減少節點，無須 重啟程序->修改程式的查詢->手動平衡叢集的資料，僅須簡單地增加主機， Cassandra 就會自動將它加入叢集中，以提供客戶需求的服務 。
- Fail Over, 高容錯性
正常來說，系統得可用性與容錯性，是根據是否能滿足客戶需求的服務而起，然而主機時常面對各種失效的問題，當然其中原因可能是元件失效抑或是網路中斷，都有可能！
如上述的解決方案，業界通常使用價格昂貴的複雜機制的伺服器做應變，以減緩如上問題的嚴重性，其內部有備援硬體，倘若遇到突發的失效事件，將會送出訊號通知，然後進行元件的熱切換 hot swap，儘管如此，任何系統都有可能遭遇網路中斷或是影響整個資料中心的災難事件，因此，若一系統要達到可用和容錯，應用程式必須有能力運行於叢集架構中，並且在某節點失效後，將需求切換到系統內的其他叢集節點上！
Cassandra 具備高度可用性與容錯性，不需 downtime 即可 hot swap。
可以跨越多個資料中心，甚至跨越地理的鴻溝，將資料複製到多個不同地理區域的資料中心，以提供效率更高的區域存取效能，也能在系統遭遇災害時避免 downtime。
也因為這一體兩面的特點，限制了其複雜查詢的表述（表達）能力。基於此緣故，Cassandra 導入自己的查詢語言。
此查詢語言介接 noSQL 和 RDBM 之間，有 Schema-Options 的選項，此指令不區分大寫小，可使用 help 或是 ? 來認識更多可運用的指令。
https://gist.github.com/hkhamm/a9a2b45dd749e5d3b3ae
(1) 設定 JAVA_HOME 環境變數： 在環境變數名稱欄位新增 JAVA_HOME 並在變數值欄位設定安裝 JAVA 或 JDK 或 JVM 的路徑 如果是微軟系統，請先安裝 JVM 如果是 * Nix 系統，請先安裝 JDK
(2) 重新啟動終端機，藉以讓系統取得新增的變數， 倘若環境變數和其值設定無誤， 則可以在啟動 Cassandra 過程中找到 Java 在終端機執行 echo %JAVA_HOME% 可以印出環境變數的值。
(3) 也可以順便設定 Cassandra 的環境變數和其值， 有利之後倘若運用 cqlsh 或是 nodetool 等資料庫服務工具帶來便利的享受。
開啟終端機，並且移至目錄
cd <cassandra-dir>/bin
然後，執行 cassandra -f 指令啟動服務
cassandra -f
啟動服務後，資料會建立在預設的 CASSANDRA_HOME 目錄中。
會有兩種資料，一是 data，一是 log。
另外，也能見到支援此資料庫的工具版本號，包含 Thrift API。
9160 ; 9042
初始化的資料結構
key
row
counter
主機與叢集中其他節點的溝通介面
JMX // Java Mgmt Plugin, this interface not allow remote connection.
gossip
clients
state jump // 節點的啟動狀態
這些日誌可供持續性的觀察，可紀錄週期性的輸出，包含 memcache 寫入磁碟等等。 另外，如果安裝新版本 C * ，最好刪除先前的日誌目錄，確保安全。
./stop-server
分成提供眾多安裝方式的社群、企業提供 Spark 的整合、AWS 打包好的虛擬機映像檔案。 選擇版本，可以依據自身的開發維運預算，並且考慮版本不同的部署環境、擴展性、穩定性、支援性來做更多的細部考量。
Test Cluster 是預設給本機主機的單一節點叢集，如下說明了主機已經連結此叢集，如下此腳本完成了展示其本機是否有運行節點和是否找到已經啟動的服務。另外，叢集名稱可以修改成為符合應用程式的名稱。
cd <cassandra-dir>/bin/cqlsh
Connected to Test Cluster at localhost:9042
cqlsh>
此指令表示命令列指定主機名與埠號。
bin/cqlsh localhost 9042
當然也可以使用非指令而是直接設定環境變數及其值的方式來指定主機名與埠號。
$CQLSH_HOST
$CQLSH_PORT
通常遇到無法連線的原因，可能是因為主機名稱和埠號不正確，此值可以利用 ping 來確認; 此外，也請確認是否是防火牆所阻擋。