Facebook (現為 Meta) 工程師 Avinash Lakshman 和 Prashant Malik 建立 Cassandra,為 Facebook 的收件匣搜尋功能提供技術支援。他們需要一個系統,能夠在多個伺服器上儲存和搜尋大量資料集,而不會降低速度。
為了建構這套系統,該團隊從另外兩個既有的資料庫模型中汲取靈感:結合 Google 2006 年 Bigtable 論文中的寬欄儲存模型,以及 Amazon Dynamo 的分散式環形架構。他們以希臘神話中特洛伊的預言家 Cassandra 為專案命名,藉此致敬那位身負「預言不被世人相信」之詛咒的傳奇人物。
隨著工程社群逐漸瞭解這個專案的潛力,專案也迅速發展:
由於歷史悠久,許多公司都信任它來驅動系統。Cassandra 仍是高可用性系統的可靠選擇,但團隊應評估其設計利弊,判斷自行管理舊版架構是否符合現代應用程式的需求。
Cassandra 通常用於處理穩定的資料串流,例如智慧型 (IoT) 感應器資訊、應用程式記錄和監控管道。此外,這種資料庫也廣泛用於事件追蹤和推薦系統,因為這類系統必須快速儲存及查詢大量資料。
Cassandra 的多資料中心複製和非同步寫入功能,可讓整個資料中心離線,而不會中斷服務或遺失資料,因此無法承受停機時間的系統會使用 Cassandra。許多跨國公司都仰賴這項服務,確保應用程式在不同區域全天候運作。
Cassandra 採用對等式設計,每個節點都相同。這些節點以分散式環狀結構排列,並採用「一致性雜湊」方法來平均分配資料,不僅能有效避免效能瓶頸,並確保沒有單點故障。您也可以選擇資料庫在檢查讀取或寫入是否成功時的嚴格程度,以便根據特定應用程式需求,在速度和擁有最新資料之間做出決定。
這個資料庫採用寬欄儲存模型,可將資料整理成鍵空間、資料列和動態資料欄,類似一般試算表,但更具彈性。這讓您在設計資料架構時保有極大彈性,能隨著應用程式的成長輕鬆調整。
功能 | Apache Cassandra | 傳統 RDBMS |
資料模型 | 去正規化 | 正規化 |
結構定義彈性 | 可在執行期間變更 | 需要停機 |
索引結構 | 記錄結構合併樹狀結構 | B-Tree |
寫入效能最佳化 | 主要 | 次要 |
CAP 定位 (一致性、可用性、分區容錯) | AP (可用性和分區容錯) | CA (一致性和可用性) |
查詢功能 | CQL (無 join) | 具備 JOIN 的完整 SQL |
資料模型
去正規化
正規化
結構定義彈性
可在執行期間變更
需要停機
索引結構
記錄結構合併樹狀結構
B-Tree
寫入效能最佳化
主要
次要
CAP 定位 (一致性、可用性、分區容錯)
AP (可用性和分區容錯)
CA (一致性和可用性)
查詢功能
CQL (無 join)
具備 JOIN 的完整 SQL
Cassandra 的儲存引擎採用記錄結構合併 (LSM) 樹狀結構來處理資料。傳入的寫入作業會先寫入修訂記錄以確保耐用性,並透過 Memtable 暫存在記憶體中。Memtable 填滿後,內容會排清至磁碟,形成不可變的 Sorted String Table (SSTable)。
由於 Cassandra 採用只能附加資料的設計,因此特別適合需要高寫入處理量的應用程式。避免就地更新的設計,讓系統能以遠高於依賴隨機磁碟 I/O 的傳統架構的速度,處理大量傳入資料。
以下是 Cassandra 的常見問題解答。
這是一種分散式資料庫,適用於需要隨時保持連線,並處理大量資料寫入作業的應用程式,例如串流記錄或感應器資料。
Cassandra 是 NoSQL 資料庫,使用類似 SQL 的 CQL 語言,但並不支援所有 SQL 功能,例如複雜的彙整或深度交易安全。
Kafka 用於即時移動資料,Cassandra 則負責安全地儲存資料;兩者通常會搭配使用。
Cassandra 最適合大規模寫入大量資料;而 MongoDB 是文件資料庫,如果您的需求包含搜尋不同類型的資料,且資料結構需要高度彈性,通常會是更合適的選擇。
Cassandra 專為線上交易處理 (OLTP) 而設計,因此非常適合處理簡單、高速的讀取和寫入作業;但不適合用於複雜的分析工作,例如執行大型報表或一次掃描所有資料。
擴充性
您可以新增更多節點來處理更多工作,而不必中斷系統。
沒有單點故障
由於所有節點都相同,因此系統非常穩定。
自動複製資料
系統會自動將資料儲存到多個位置。
快速寫入
儲存空間設計可同時處理大量寫入作業。
可調整的一致性
您可以根據個別查詢需求,控制資料的嚴格程度。選擇「所有」節點可達到最佳準確率,選擇「一個」節點則能達到最快的速度。
不必受制於特定廠商
由於能在標準硬體上執行,因此您不必受限於特定雲端供應商。必要時,您也可以在地端部署設定與不同雲端之間移動資料。
自行執行 Cassandra 系統需要承擔大量作業負擔。您必須規劃所需的空間、設定伺服器、處理維修、確保備份完善,並在系統執行時進行更新。
代管服務能替您處理繁重的工作,徹底改變這種情況。
將這些作業轉移至代管平台後,團隊就不必再擔心資料庫的基礎架構,可以專注為使用者創造價值。
在決定如何執行 Cassandra 工作負載時,您有三種主要做法可選擇。
最適合的路徑取決於團隊的專業能力,以及特定業務需求之間的平衡。請參考這份檢查清單,做出明智的決定:
問題 | 如果可以… | 如果不可以… |
我們有時間修正及調整資料庫嗎? | 如果貴公司有專門負責「資料庫底層維運」的工程師團隊,就可以自行管理叢集。 | 選擇代管服務,避免將工程時間浪費在基礎架構維護上。 |
「保持連線」是否比完美的一致性更重要? | Cassandra 的 AP 模型非常適合高可用性應用程式。 | 不妨考慮 Cloud Spanner,這個分散式系統不僅能擴充,還能嚴格確保資料安全。 |
隨著業務成長,我們需要快速擴充資源嗎? | 使用代管服務或 Bigtable,這類服務提供自動調整資源配置功能,可處理流量尖峰。 | 靜態叢集雖然可行,但在尖峰時段可能會遇到效能瓶頸。 |
代管服務能否提高工作可靠性? | 當然可以,代管服務會自動備份及修補,避免人為錯誤。 | 您正在承擔手動維護的更高風險以及潛在的設定錯誤。 |
我們的目標是實現基礎架構的可攜性嗎? | 自行管理可讓您在雲端之間自由移動,或是在地端部署環境中執行。 | 您願意以較低的營運成本,換取雲端專屬優勢。 |
問題
如果可以…
如果不可以…
我們有時間修正及調整資料庫嗎?
如果貴公司有專門負責「資料庫底層維運」的工程師團隊,就可以自行管理叢集。
選擇代管服務,避免將工程時間浪費在基礎架構維護上。
「保持連線」是否比完美的一致性更重要?
Cassandra 的 AP 模型非常適合高可用性應用程式。
不妨考慮 Cloud Spanner,這個分散式系統不僅能擴充,還能嚴格確保資料安全。
隨著業務成長,我們需要快速擴充資源嗎?
使用代管服務或 Bigtable,這類服務提供自動調整資源配置功能,可處理流量尖峰。
靜態叢集雖然可行,但在尖峰時段可能會遇到效能瓶頸。
代管服務能否提高工作可靠性?
當然可以,代管服務會自動備份及修補,避免人為錯誤。
您正在承擔手動維護的更高風險以及潛在的設定錯誤。
我們的目標是實現基礎架構的可攜性嗎?
自行管理可讓您在雲端之間自由移動,或是在地端部署環境中執行。
您願意以較低的營運成本,換取雲端專屬優勢。
如果您不想再自行管理 Cassandra,Google Cloud 提供兩種實用的解決方案:Bigtable 與 Spanner。
如果您已使用 Cassandra 的寬欄儲存空間和高寫入處理量,Bigtable 可能非常適合您。如要使用這項服務,您可以將現有的 Cassandra 鍵空間和資料表對應至 Bigtable 資料表,並更新應用程式程式碼,以改用 Cloud Bigtable 用戶端程式庫。Bigtable 是全代管服務,會自動處理資料分割和負載平衡,不再需要像 Cassandra 那樣手動調整叢集。
如果 Cassandra 工作負載已成長到需要更強的一致性,或您開始需要 SQL 的關聯式功能,Spanner 也是不錯的選擇。使用這項服務時,您必須以標準 SQL 定義結構定義,這可能需要將部分非正規化的 Cassandra 資料正規化。Spanner 提供與 Cassandra 相同的水平擴充能力,但具備同步一致的全球部署優勢,並完整支援關聯式 SQL。