Cassandra 概況

如果一個概念一開始不是荒誕不羈的話，那它也沒什麼前途。
                                                                                  ——阿爾伯特 ·愛因斯坦

 

      歡迎閱讀《Cassandra 權威指南》。本書的目標是幫助開發者和資料庫管理員們理解這種重要的新型資料庫，探索它與傳統的關係型資料庫系統有何異同，並幫助你在自己的系統中使用Cassandra。

 

關係型資料庫有什麼問題

如果當初我問人們到底想要什麼的話，他們會說想要快些的馬。
                                                                                     ——亨利 ·福特

 

      請你考慮一種資料模型，它由一個擁有數千名僱員的大公司裡的一個小團隊發明。這個模型可以通過TCP/IP 訪問，並且可以使用包括Java 和Web Service 在內的多種語言訪問。在被廣泛採納之前，這個模型起初若非最頂尖的電腦科學家都很難理解，最終因為用的人越來越多，才被大家認識。要使用這種模型構建出資料庫，就必須學習許多新術語，換一種方式考慮資料儲存。隨著相關的產品層出不窮地出現，很多公司和政府部門開始廣泛地使用它，因為它非常快——可以在一秒鐘內執行上千次操作。這種模型產生了讓人難以置信的收益。
      然後，又一種新的模型出現了。

      這個新模型是一種可怕的異端，主要有兩點原因。首先，它最受非議的地方就在於新模型與舊模型完全不同，它們簡直是格格不入。這很可怕，因為全新且完全不同的東西通常難以理解。隨之而來的爭論更進一步鞏固了人們的看法，而這些看法主要來自人們已有的工作環境和習得的技術。其次，或許是更重要的原因，新模型所面臨的阻礙更多來自商業考慮，它威脅到了在舊模型上的大量投資，這些投資正在帶來大量收入。在這個時候改變似乎是可笑的，也是不可能的。
      當然，我說的是1966 年由IBM 發明的資訊管理系統（IMS）分層資料庫。
      IMS 是為“土星五號”登月火箭而設計的。它的架構師是Vern Watts，他的整個職業生涯都和IMS 聯絡在一起。很多讀者都知道IBM 的DB2 資料庫。而IBM 廣為人知的DB2 資料庫的名字就沿襲自它的前身DB1，DB1 是圍繞著IMS 的資料模型構建的。IMS 於1968 年釋出，之後在使用者資訊控制系統（CICS）和其他應用中取得成功。至今IMS 仍被很多應用使用著。
      但是，在IMS 發明之後的幾年裡就出現了一個嶄新的模型，這個破壞性的、帶來威脅的模型就是關係型資料庫。
      同樣來自IBM 的Edgar F. Codd 博士在他1970 年發表的論文《一種用於大規模共享資料儲存系統的關係型資料模型》中，闡述了他在IBM 聖荷西實驗室的工作中提出的關係資料模型理論。這篇目前仍然可以在http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf 訪問的論文，成為了後來的關係型資料管理系統的奠基性作品。
      Codd 的工作與IMS 的層次化結構完全對立。IMS 的使用者要理解並使用關係型資料庫，就需要學習很多聽起來十分怪異的新名詞。不過，關係型模型與它的前身相比更具優勢，部分因為巨人幾乎總是站在其他巨人的肩膀上。
      關係型資料庫這個概念和它的應用已經演化了四十多年了，毫無疑問，它是軟體應用歷史上最成功的一個。它既可以在個人小公司裡通過微軟Access 資料庫來使用，也可以在大型跨國公司的上百臺經過調優的伺服器上使用，構成儲存數TB 資料的資料倉儲。關係資料模型儲存了賬單、使用者記錄、產品目錄、賬戶明細、使用者鑑權資訊等等，可以說關係型資料庫裡差不多儲存了整個世界。毫無疑問，無論以現代的技術還是商業視角看，關係型資料庫都扮演著關鍵角色，而且，多年後它也會以各種形式一直伴隨我們存在，IMS 也是同樣。關係模型雖然是IMS 的一種替代模型，兩者都各得其所。
      所以，要問關係型資料庫有什麼問題，一言以蔽之，就是“沒有問題”。

      不過，實際上我還想請你考慮一個長一點的答案。這個答案需要從長計議，每個偶然誕生的概念都在點滴改變著世界，孕育著某種革命。而這一次次的革命不過是歷史的重演罷了。從IMS、RDBMS 到NoSQL，一如從馬到汽車再到飛機，每一個都建立在前一個的基礎之上，解決前一個存在的某些問題，每個都有所長，亦有所短。他們彼此共存，直到如今。
      那麼就來看看為什麼現在我們要考慮關係型資料庫的替代產品，正如四十年前Codd 自己面對資訊管理系統（IMS）的思考一樣——或許IMS 不是唯一適合用於組織資訊、處理資料的方法，可能正是因為某些問題使得他必須要考慮一種IMS 的替代品。
      當基於關係型資料庫的應用取得成功，訪問量大幅增加的時候，我們就會遇到可擴充套件性問題。所有具有最基本功能的關係型資料庫都會支援join 操作，不過join 可能會很慢。由於資料庫通常依靠事務來保證一致性，而事務需要鎖住資料庫的一部分，使之不能被其他使用者訪問。因為鎖本身意味著競爭同一資料的使用者會被放入佇列，等待獲得讀寫許可權，這在高負載的情況下可能會成為系統的死穴。

      通常，我們會用下面的一條或幾條方法來解決這些問題，很多時候是下面這個順序。

• 提升硬體能力來解決問題，如增加內• 存、用更快的處理器以及升級硬碟。這種方法稱為垂直擴充套件，可以解一時之憂。
• 當問題再度出現時，解決方法很類似：既然一臺機器已經不堪重負了，我們就增加新的計算機，構成資料庫叢集。不過，這樣你就會在正常使用及出故障時遇到資料複製與一致性問題了。這些問題之前從未出現過。
• 現在我們需要更新資料庫管理系統的配置。可能是要優化資料庫用來寫底層檔案系統的通道。我們關掉了檔案系統的日誌，當然，這通常是不推薦的（或者說要具體情況具體分析）。
• 在資料庫系統上投入了足夠多的精力之後，我們轉過來審視自己的應用。我們開始優化索引、優化查詢。不過，當我們的應用達到這個規模的時候，恐怕不太會完全沒做過索引和查詢優化，可能已經優化過不少了。那麼，只好重新審視所有資料庫訪問程式碼，想發現零星的可以調優的機會，這是一件相當頭疼的事。優化內容可能包括減少或改寫join 操作，除去比較消耗資源的特徵（如在儲存過程中的XML 處理）等。當然，我們做那些XML 處理本身肯定是有原因的，如果我們不得不做的話，那就得把它挪到應用層去，希望那裡能解決問題，並祈禱我們這麼幹不會同時把什麼其他東西弄壞。
• 我們增加了一個快取層。對於大系統可能會引入分散式快取，如memcached、EHCache、Oracle Coherence 或其他類似產品。現在，我們又需要面臨更新快取和更新資料庫的一致性問題了，對於叢集來說，問題更加嚴重。
• 現在我們把注意力重新轉向資料庫，• 由於應用已經在那裡了，並且我們很瞭解主要的查詢路徑，現在我們複製那些訪問頻率較高的資料，讓它們更接近於查詢想要得到的形式。這個過程稱為反正規化化（denormalization），它與關係模型的關鍵特徵裡的五種形式是對立的，也違反了Codd 對關係型資料模型的12 條建議。我們只能安慰自己說我們是生活在現實世界之中，而非理論世界中，並保證我們所做的都是為了讓應用能夠在可接受的響應時間下完成工作，即使這已經不是“純粹”的關係模型了。

      我相信這一幕對你肯定非常熟悉。在網際網路的規模下，工程師們已經開始考慮這個情況是不是和當年亨利 ·福特的境遇有些相似，你真正需要的已不僅僅是你本來想的一匹快馬了。他們已經做了一些令人稱道而有趣的工作。
      首先我們必須認識到，關係模型只是一種資料模型而已。它是一種看待世界的有效的方法，對某些問題非常有效。但它並沒打算也沒被證明可以一統天下，不留任何餘地終結所有其他表示資料的方法。如果我們回顧一下歷史就會發現，Codd 博士的模型也曾是個破壞性的發明。它是全新的，帶來了很多新詞彙和像“元組”這樣的術語——老詞彙但有新意義。關係模型在當時引發了質疑，甚至受到了強烈的批評。即使是Codd 博士工作的IBM 公司也是反對者之一，因為他們擁有一系列圍繞IMS的富有盈利能力的產品，不需要一個闖入者來分蛋糕。
      不過如今，關係模型已經無可辯駁地坐上了資料世界中的頭把交椅。SQL 獲得了廣泛的支援和很好的理解，大學的入門課程就會講授SQL 與關聯式資料庫。甚至4.95美元1 月就可以租到有免費資料庫的網際網路主機。我們最終使用什麼資料庫通常由組織的架構標準而定。即使沒有這樣的標準，學習一下組織結構已經有了什麼資料庫平臺仍是明智的。我們的開發和架構方面的同事都有相當難得的知識積累。
      僅僅是出於滲透或是慣性，我們多年來都已經習慣了關係型資料庫是一個四海一家的解決之道。
      因此，也許真正的問題不是“關聯式資料庫有什麼問題”，而是“你有什麼問題要解決”。
      也就是說，要確保你的解決方案和你的問題相匹配。關係型資料庫確實在解決很多問題時非常有效。

      如果你並未面對大規模、彈性擴充套件的問題，那麼對於Cassandra 之類的複雜系統的取捨完全沒有考慮的必要。據我所知，沒有任何一位Cassandra 的支持者會要求別人丟掉他們的所有關係型資料庫的知識、放棄他們多年來對於這類系統的難得的經驗，或是破壞他們的員工花費數月時間精心構建起來的系統。
      關係型資料庫長期以來很好地服務於我們這些開發者和DBA。但是由於網際網路，特別是社會化網路的爆炸性發展，相應的必須要處理的資料量也在增長。當TimBerner-Lee 在20 世紀90 年代初構建Web 的時候，只是為了物理實驗室裡的博士們交流科學文件而已。如今，網際網路已經無處不在了，從最初的那些科學家到在網上交流小貓圖片與表情符號的五歲小孩，每個人都在使用網際網路。這意味著網際網路業必然要支援海量的資料，事實上，這也成為了Web 巧奪天工的架構的不朽豐碑。
      不過，有些基礎設施已經開始力不從心了。
      在1966 年，像IBM 這樣的公司可以向世界傳播他們的創新。他們自己有問題，也擁有解決問題的能力。但當我們進入21 世紀第二個十年的時候，我們也開始看到類似的創新了，不過這些創新來自於像Facebook 和Twitter 這樣的年輕公司。
      所以，真正的問題可能也不是“我有什麼需要解決的問題”，而是“如果資料不是問題，那麼應該怎麼來處理這些資料”。如果能夠輕易做到容錯、跨資料中心可用性、可調整的一致性，以及高達上百TB 的超大規模、多種可選擇的客戶端語言，又會怎樣？你可能會說，你不需要那種可用性或是那個水平的可擴充套件性，而且你最清楚你的系統需求。你當然是對的，因為事實上，如果你的資料庫不能滿足當前對資料庫的需求，那麼你的系統是根本無法工作的。
      我無意通過詭辯來說服你採用一個像Apache Cassandra 這樣的非關係型資料庫。我只是想介紹Cassandra 能做什麼、如何做到，這樣你就可以依此來決策，並且如果你發現它可用，就可以開始使用它開展實際工作了。只有你自己知道你的資料需求是什麼。我不需要你重新考慮自己的資料庫，除非你已經被資料庫問題折騰得苦不堪言了，或是你需要擴充套件資料庫卻無能為力，或是你的資料模型無法足夠靈活地匹配你的應用需求。我並不要求你考慮你的資料庫，但請考慮你的組織結構，它未來的目標和它將要面臨的問題。如果你能收集到有關商業目標的更多資料的話，你會收集麼？
      不要問如何讓Cassandra 融入你的現有環境，要問你希望解決什麼資料問題而不是隻關注現在資料存在的問題。要問你希望的新型資料是什麼樣的。如果可能的話，你想要如何去深入理解你的組織？