Cassandra原理 | Apache Cassandra簡介

• 2019 年 10 月 7 日
• 筆記

Apache Cassandra 是一個開源的、分散式、無中心、彈性可擴展、高可用、容錯、一致性可調、面向行的資料庫，它基於 Amazon Dynamo 的分散式設計和 Google Bigtable 的數據模型，由 Facebook 創建，在一些最流行的網站中得到應用。

為什麼會誕生 Apache Cassandra

2007 年 Facebook 為了解決消息收件箱搜索問題（ Inbox Search problem）而開始設計 Cassandra 項目。當時 Facebook 遇到了傳統的方法難以解決的超大數據量存儲可擴展性問題。具體來說，項目團隊需要處理大量的消息副本、消息的反向索引等不同形式的數據，需要處理很多隨機讀和並發隨機寫操作。

該團隊由 Jeff Hammerbacher 領導，核心工程師包括 Avinash Lakshman，Karthik Ranganathan 和搜索團隊的 Prashant Malik 。2008年7月 Cassandra 的程式碼被作為開源項目發布到 Google Code。雖然程式碼在2008年作為 Google Code 的一個項目，但是這段時間基本上只有 Facebook 工程師來更新程式碼，基本上沒有形成社區。所以在2009年3月，Cassandra 被轉移到 Apache 孵化器項目，並在2010年2月17日，它被投票成為一個頂級項目。在 Apache Cassandra Wiki 上，您可以找到 committers 列表，其中許多人自 2010/2011 年以來就一直參與該項目。committers 主要來自 Twitter，LinkedIn，Apple，其中還包括了許多獨立開發者。

Cassandra 的設計很大程度受 Amazon Dynamo 的影響，具體可參見《Dynamo: Amazon's Highly Available Key-value Store》。2010年由 Facebook 的 Lakshman 和 Malik 在 ACM 首次發表了 Cassandra 的論文 《Cassandra: a decentralized structured storage system》，向全世界介紹了 Cassandra。

隨著商界對 Cassandra 的興趣增加，對 Cassandra 的生產支援變得越來越明顯。2010年4月 Cassandra 的 Apache 項目主席 Jonathan Ellis 和其同事 Matt Pfeil 成立了一家名為 DataStax 公司（最初名為 Riptano）。DataStax 僱傭了多名 Cassandra Committer，為 Cassandra 項目提供了相關支援，並引領其發展。

Cassandra 的名字由來 在希臘神話里，Cassandra 是特洛伊國王 Priam 和 Hecuba 王后的女兒。Cassandra 非常美麗，以至於阿波羅給了她預見未來的能力。但當她拒絕阿波羅的愛慕的時候，遭到他的詛咒。從此，她依然可以精確地預知未來，但是不會有任何人相信她。Cassandra 預知了她的特洛伊城終將覆滅，但卻無力阻止這一悲劇。Cassandra 分散式資料庫就據此命名。

Apache Cassandra 特性

分散式和去中心化（Distributed and Decentralized）

Cassandra 是分散式的，這意味著它可以運行在多台機器上，並呈現給用戶一個一致的整體。事實上，在一個節點上運行 Cassandra 是沒啥用的，雖然我們可以這麼做，並且這可以幫助我們了解它的工作機制，但是你很快就會意識到，需要多個節點才能真正了解 Cassandra 的強大之處。它的很多設計和實現讓系統不僅可以在多個節點上運行，更為多機架部署進行了優化，甚至一個 Cassandra 集群可以運行在分散於世界各地的數據中心上。你可以放心地將數據寫到集群的任意一台機器上，Cassandra 都會收到數據。

對於很多存儲系統（比如 MySQL, Bigtable），一旦你開始擴展它，就需要把某些節點設為主節點，其他則作為從節點。但 Cassandra 是無中心的，也就是說每個節點都是一樣的。與主從結構相反，Cassandra 的協議是 P2P 的，並使用 gossip 來維護存活或死亡節點的列表。關於 gossip 可以參見《分散式原理：一文了解 Gossip 協議》。

去中心化這一事實意味著 Cassandra 不會存在單點失效。Cassandra 集群中的所有節點的功能都完全一樣， 所以不存在一個特殊的主機作為主節點來承擔協調任務。有時這被叫做伺服器對稱（server symmetry）。

綜上所述，Cassandra 是分散式、無中心的，它不會有單點失效，所以支援高可用性。

彈性可擴展（Elastic Scalability）

可擴展性是指系統架構可以讓系統提供更多的服務而不降低使用性能的特性。僅僅通過給現有的機器增加硬體的容量、記憶體進行垂直擴展，是最簡單的達到可擴展性的手段。而水平擴展則需要增加更多機器，每台機器提供全部或部分數據，這樣所有主機都不必負擔全部業務請求。但軟體自己需要有內部機制來保證集群中節點間的數據同步。

彈性可擴展是指水平擴展的特性，意即你的集群可以不間斷的情況下，方便擴展或縮減服務的規模。這樣，你就不需要重新啟動進程，不必修改應用的查詢，也無需自己手工重新均衡數據分布。在 Cassandra 里，你只要加入新的電腦，Cassandra 就會自動地發現它並讓它開始工作。

高可用和容錯（High Availability and Fault Tolerance）

從一般架構的角度來看，系統的可用性是由滿足請求的能力來量度的。但電腦可能會有各種各樣的故障，從硬體器件故障到網路中斷都有可能。如何電腦都可能發生這些情況，所以它們一般都有硬體冗餘，並在發生故障事件的情況下會自動響應並進行熱切換。對一個需要高可用的系統，它必須由多台聯網的電腦構成，並且運行於其上的軟體也必須能夠在集群條件下工作，有設備能夠識別節點故障，並將發生故障的中端的功能在剩餘系統上進行恢復。

Cassandra 就是高可用的。你可以在不中斷系統的情況下替換故障節點，還可以把數據分布到多個數據中心裡，從而提供更好的本地訪問性能，並且在某一數據中心發生火災、洪水等不可抗災難的時候防止系統徹底癱瘓。

可調節的一致性（Tuneable Consistency）

2000年，加州大學伯克利分校的 Eric Brewer 在 ACM 分散式計算原理會議提出了著名的 CAP 定律。CAP 定律表明，對於任意給定的系統，只能在一致性（Consistency）、可用性（Availability）以及分區容錯性（Partition Tolerance）之間選擇兩個。關於 CAP 定律的詳細介紹可參見《分散式系統一致性問題、CAP定律以及 BASE 理論》以及《一篇文章搞清楚什麼是分散式系統 CAP 定理》。所以 Cassandra 在設計的時候也不得不考慮這些問題，因為分區容錯性這個是每個分散式系統必須考慮的，所以只能在一致性和可用性之間做選擇，而 Cassandra 的應用場景更多的是為了滿足可用性，所以我們只能犧牲一致性了。但是根據 BASE 理論，我們其實可以通過犧牲強一致性獲得可用性。

Cassandra 提供了可調節的一致性，允許我們選定需要的一致性水平與可用性水平，在二者間找到平衡點。因為客戶端可以控制在更新到達多少個副本之前，必須阻塞系統。這是通過設置副本因子（replication factor）來調節與之相對的一致性級別。

通過副本因子（replication factor），你可以決定準備犧牲多少性能來換取一致性。副本因子是你要求更新在集群中傳播到的節點數（注意，更新包括所有增加、刪除和更新操作）。

客戶端每次操作還必須設置一個一致性級別（consistency level）參數，這個參數決定了多少個副本寫入成功才可以認定寫操作是成功的，或者讀取過程中讀到多少個副本正確就可以認定是讀成功的。這裡 Cassandra 把決定一致性程度的權利留給了客戶自己。

所以，如果需要的話，你可以設定一致性級別和副本因子相等，從而達到一個較高的一致性水平，不過這樣就必須付出同步阻塞操作的代價，只有所有節點都被更新完成才能成功返回一次更新。而實際上，Cassandra 一般都不會這麼來用，原因顯而易見（這樣就喪失了可用性目標，影響性能，而且這不是你選擇 Cassandra 的初衷）。而如果一個客戶端設置一致性級別低於副本因子的話，即使有節點宕機了，仍然可以寫成功。

總體來說，Cassandra 更傾向於 CP，雖然它也可以通過調節一致性水平達到 AP；但是不推薦你這麼設置。

面向行（Row-Oriented）

Cassandra 經常被看做是一種面向列（Column-Oriented）的資料庫，這也並不算錯。它的數據結構不是關係型的，而是一個多維稀疏哈希表。稀疏（Sparse）意味著任何一行都可能會有一列或者幾列，但每行都不一定（像關係模型那樣）和其他行有一樣的列。每行都有一個唯一的鍵值，用於進行數據訪問。所以，更確切地說，應該把 Cassandra 看做是一個有索引的、面向行的存儲系統。

Cassandra 的數據存儲結構基本可以看做是一個多維哈希表。這意味著你不必事先精確地決定你的具體數據結構或是你的記錄應該包含哪些具體欄位。這特別適合處於草創階段，還在不斷增加或修改服務特性的應用。而且也特別適合應用在敏捷開發項目中，不必進行長達數月的預先分析。對於使用 Cassandra 的應用，如果業務發生變化了，只需要在運行中增加或刪除某些欄位就行了，不會造成服務中斷。

當然， 這不是說你不需要考慮數據。相反，Cassandra 需要你換個角度看數據。在 RDBMS 里， 你得首先設計一個完整的數據模型， 然後考慮查詢方式， 而在 Cassandra 里，你可以首先思考如何查詢數據，然後提供這些數據就可以了。

靈活的模式（Flexible Schema）

Cassandra 的早期版本支援無模式（schema-free）數據模型，可以動態定義新的列。無模式資料庫（如 Bigtable 和 MongoDB）在訪問大量數據時具有高度可擴展性和高性能的優勢。無模式資料庫的主要缺點是難以確定數據的含義和格式，這限制了執行複雜查詢的能力。

為了解決這些問題，Cassandra 引入了 Cassandra Query Language（CQL），它提供了一種通過類似於結構化查詢語言（SQL）的語法來定義模式。最初，CQL 是作為 Cassandra 的另一個介面，並且基於 Apache Thrift 項目提供無模式的介面。在這個過渡階段，術語「模式可選」（Schema-optional）用於描述數據模型，我們可以使用 CQL 的模式來定義。並且可以通過 Thrift API 實現動態擴展以此添加新的列。在此期間，基礎數據存儲模型是基於 Bigtable 的。

從 3.0 版本開始，不推薦使用基於 Thrift API 的動態列創建的 API，並且 Cassandra 底層存儲已經重新實現了，以更緊密地與 CQL 保持一致。Cassandra 並沒有完全限制動態擴展架構的能力，但它的工作方式卻截然不同。CQL 集合（比如 list、set、尤其是 map）提供了在無結構化的格式裡面添加內容的能力，從而能擴展現有的模式。CQL 還提供了改變列的類型的能力，以支援 JSON 格式的文本的存儲。

因此，描述 Cassandra 當前狀態的最佳方式可能是它支援靈活的模式。

高性能（High Performance）

Cassandra 在設計之初就特別考慮了要充分利用多處理器和多核電腦的性能，並考慮在分布於多個數據中心的大量這類伺服器上運行。它可以一致而且無縫地擴展到數百台機器，存儲數 TB 的數據。Cassandra 已經顯示出了高負載下的良好表現，在一個非常普通的工作站上，Cassandra 也可以提供非常高的寫吞吐量。而如果你增加更多的伺服器，你還可以繼續保持 Cassandra 所有的特性而無需犧牲性能。

Cassandra 的應用場景

我們已經介紹了 Cassandra 的主要特點，對 Cassandra 的長處有了一定的理解。儘管 Cassandra 設計精巧，功能出色，但也不能勝任所有的工作。所以我們來介紹一下 Cassandra 最適合的場景。

大規模部署

你可能不會開著一輛輕型的小卡車去取乾洗的衣服，小卡車顯然不適合這種工作。Cassandra 的很多精巧設計都專註於高可用、可調一致性、P2P 協議、無縫擴展等，這些都是 Cassandra 的賣點。這些特性在單節點工作時都是沒有意義的，更無法實現它的全部能力。

但是，單節點關係資料庫在很多情況下可能正是我們需要的。所以你需要做一些評估。考慮你的期望的流量、吞吐需求以及 SAL 等。關於評估沒有什麼硬性的指標和要求。但如果你認為有幾種關係型資料庫可以很好地應付你的流量，提供不錯的性能，那可能選關係型資料庫更好。簡單地說，這是因為 RDBMS 更易於在單機上運行，對你來說也更熟悉。

但是，如果你認為需要至少幾個節點才能支撐你的業務，那 Cassandra 就是個不錯的選擇。如果你的應用可能需要數十個節點，那 Cassandra 可能就是個很棒的選擇了。

寫密集、統計和分析型工作

考慮一下你的應用的讀寫比例，Cassandra 是為優異的寫吞吐量而特別優化的。

許多早期使用 Cassandra 的產品都用於存儲用戶狀態更新、社交網路、建議/評價以及應用統計等。這些都是 Cassandra 很好的應用場景，因為這些應用大都是寫多於讀的，並且更新可能隨時發生並伴有突發的峰值。事實上，支撐應用負載需要很高的多客戶執行緒並發寫性能，這正是 Cassandra 的主要特性。

根據項目的 wiki，Cassandra 已經被用於開發了多種不同的應用，包括窗口化的時間序列資料庫，用於文檔搜索的反向索引，以及分散式任務優先順序隊列。

地區分布

Cassandra 直接支援多地分布的數據存儲，Cassandra 可以很容易配置成將數據分布到多個數據中心的存儲方式。如果你有一個全球部署的應用，那麼讓數據貼近用戶會獲得不錯的性能收益，Cassandra 正適合這種應用場合。

變化的應用

如果你正在「初創階段」，業務會不斷改進，Cassandra 這種靈活的模式的數據模型可能更適合你。這讓你的資料庫能更快地跟上業務改進的步伐。

誰在使用 Cassandra

Cassandra 在全世界有多達 1500 家公司使用：

• 蘋果的 Cassandra 集群達到 75,000 節點，存儲了 10PB 的數據；
• Netflix 的 Cassandra 集群達到 2,500 個節點，存儲了多達 420TB 的數據；
• 宜搜的 Cassandra 集群達到 270 個節點，存儲多達 300TB 的數據；
• eBay 的 Cassandra 集群達到 100 個節點，存儲多達 250TB 的數據；
• 360 的 Cassandra 集群達到 1500 個節點；
• 餓了么的 Cassandra 集群達到 100 個節點。