本文將超越眾所周知的一些細節,探討與 Cassandra 相關的不太明顯的細節。 您將檢查 Cassandra HTTP://www.aliyun.com/zixun/aggregation/14208.html">資料模型、存儲模式設計、架構,以及與 Cassandra 相關的潛在驚喜。
在資料庫歷史文章 「What Goes Around Comes Around」中,Michal Stonebraker 詳細描述了存儲技術是如何隨著時間的推移而發展的。 實現關係模型之前,開發人員曾嘗試過其他模型,比如層次圖和有向圖。 值得注意的是,基於 SQL 的關係模型(即使到現在也仍然是事實上的標準)已經盛行了大約 30 年。 鑒於電腦科學的短暫歷史及其快速發展的步伐,這是一項非凡的成就。 關係模型建立已久,以至於許多年來,解決方案架構師很容易為應用程式選擇資料存儲。 他們的選擇總是關係資料庫。
諸如增加系統、行動裝置、擴展的使用者線上狀態、雲計算和多核系統的使用者群之類的開發已經導致產生越來越多的大型系統。 Google 和 Amazon 之類的高科技公司都是首批觸及規模問題的公司。 他們很快就發現關係資料庫並不足以支援大型系統。
為了避免這些挑戰,Google 和 Amazon 提出了兩個可供選擇的解決方案:Big Table 和 Dynamo,他們可以由此放鬆關係資料模型提供的保證,從而實現更高的可擴充性。 Eric Brewer 的 「CAP Theorem」後來官方化了這些觀察結果。 它宣稱,對於可擴充性系統,一致性、可用性和分區容錯性都是權衡因素,因為根本不可能構建包含所有這些屬性的系統。 不久之後,根據 Google 和 Amazon 早期的工作,以及所獲得的對可擴充性系統的理解,計畫創建一種新的存儲系統。 這些系統被命名為 「NoSQL」 系統。 該名稱最初的意思是 「如果想縮放就不要使用 SQL」,後來被重新定義為 「不只是 SQL」,意思是說,除了基於 SQL 的解決方案外,還有其他的解決方案。
有許多 NoSQL 系統,而且每一個系統都緩和或改變了關係模型的某些方面。 值得注意的是,沒有一個 NoSQL 解決方案適用于所有的場景。 每一個解決方案都優於關係模型,且針對一些用例子集進行了縮放。 我的早期文章 「在 Data Storage Haystack 中為您的應用程式尋找正確的資料解決方案」 討論了如何使應用程式需求和 NoSQL 解決方案相匹配。
Apache Cassandra是其中一個最早也是最廣泛使用的 NoSQL 解決方案。 本文詳細介紹了 Cassandra,並指出了一些首次使用 Cassandra 時不容易發現的細節和複雜之處。
Apache Cassandra
Cassandra 是一個 NoSQL 列族 (column family) 實現,使用由 Amazon Dynamo 引入的架構方面的特性來支援 Big Table 資料模型。 Cassandra 的一些優勢如下所示:
高度可擴充性和高度可用性,沒有單點故障 NoSQL 列族實現 非常高的寫入輸送量和良好的讀取輸送量 類似 SQL 的查詢語言(從 0.8 起),並通過二級索引支援搜索 可調節的一致性和對複製的支援 靈活的模式
這些優點很容易讓人們推薦使用 Cassandra,但是,對於開發人員來說,至關重要的一點是要深入探究 Cassandra 的細節和複雜之處,從而掌握該程式的複雜性。
Cassandra 根據列族資料模型存儲資料,如 圖 1 所示。
圖 1. Cassandra 資料模型