歡迎您光臨本站 註冊首頁

關於Cassandra的錯誤觀點

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

 正如Apache Cassandra的名稱是來自於著名的物洛伊女巫一樣,在它身上確實存在著各種誤解。和大多數誤解一樣,至少在一開始時它們確實是有那麼一點道理的,但隨著Cassandra不斷地深化與改善,這些誤解的內容已經不復存在了。在本文中,我將針對五個常見的疑惑作出解釋,澄清人們的困惑。

誤解:Cassandra就是一個嵌套的map

隨著使用Cassandra的應用程序變得越來越複雜,以下觀點正在逐漸變得清晰起來:與“任何東西都是一個數組緩衝”或者“任何東西都是一個字元串”這種設計方式相比,schema與數據類型會使大型應用的開發與維護更加簡單,

現如今,理解Cassandra的數據模型的最好方式是將其想像為表與行的組合,並且與關係型數據相似的是,Cassandra的列也是強類型的,並且可以進行索引。

 

你也許還聽到過其它這些說法:

  • “Cassandra是一種列資料庫。”列資料庫會將某個列的全部數據一起保存在磁碟上,這種方式對於數據倉庫的檢索方式是比較適合的,但對於那些需要對特定的行進行快速訪問的應用程序來說就不太適合了。
  • “Cassandra是一種寬行資料庫。”這種說法有一定的道理,因為Cassandra的存儲引擎是由Bigtable所啟發而設計的,而後者可以說是寬行資料庫的祖先了。但寬行資料庫的數據模型與存儲引擎結合得太過緊密,雖然實現起來比較容易,但針對它進行開發就增加了困難,而且它還使許多優化方式變得不可行了。

我們之所以在開始的部分選擇避開“表與行”這種方法,原因之一是因為Cassandra的表與你所熟的關係型資料庫的表的確存在著某些微妙的差別。首先,主鍵的首個元素是分區鍵,在同一個分區中的所有行都會存儲在同一台伺服器上,而分區是分佈在整個集群中的。

其次,Cassandra不支持關聯查詢與子查詢,這是因為在分散式系統中跨越硬體進行關聯查詢的性能很差。Cassandra的做法是鼓勵你採用去正規化(denormalization)的方式,從一個單獨的表中獲取你所需的數據,同時提供集合等工具以簡化操作。

 

舉例來說,考慮一下以下代碼所表示的users表:

  CREATE TABLE users (    user_id uuid PRIMARY KEY,    name text,    state text,    birth_year int  );

目前多數主流服務都會考慮到一個用戶可以擁有多個email地址的情況。在關係型資料庫中,我們必需建立一個多對一的關係,隨後使用關聯查詢將地址與用戶關聯起來,如以下所示:

  CREATE TABLE users_addresses (    user_id uuid REFERENCES users,    email text  );    SELECT *  FROM users NATURAL JOIN users_addresses;

而在Cassandra中,我們會以去正規化的方式將所有email地址直接加入用戶表中,使用一個set集合就可以完美地實現這一點:

  ALTER TABLE users ADD email_addresses set<text>;

隨後我們可以以如下方式為用戶添加多個地址:

  UPDATE users  SET email_addresses = {‘jbe@gmail.com’, ‘jbe@datastax.com’}  WHERE user_id = ‘73844cd1-c16e-11e2-8bbd-7cd1c3f676e3’

關於Cassandra數據模型的更多內容,包括自屆滿數據(self-expiring data)以及分散式計數器,請參考在線文檔,

誤解:Cassandra的讀取速度較慢

Cassandra採用的日誌結構存儲引擎意味著它不會在硬碟中尋找更新,也不會造成固態硬碟的寫入放大,而同時它的讀取速度也很快。

以下圖示是關於隨機訪問讀取、隨機訪問及順序掃描,以及混合讀寫情況下的吞吐數據,它們來自於多倫多大學的NoSQL性能指標分析結果:

來自Endpoint公司的性能指標檢測對Cassandra、HBase與MongoDB進行了比較,也證實了以上結論的正確性。

Cassandra是怎樣實現的呢?從一個較高的層次來看,Cassandra的存儲引擎看起來與Bigtable很像,它們都使用了一些相同的術語。更新內容會添加到某個commitlog中,隨後收集到某個“memtable”里,該表會最終將數據寫入磁碟並進行索引,類似於一個“sstable”:

原生的日誌結構存儲系統確實會傾向於在讀取時稍慢,而由於同樣的原因,它們在寫入時會比較快:因為新的數據不會替換每一行中的原始數據,而是在後台壓縮后再進行合併。因此在最壞的情況下,為了獲取某個“碎片化”的行中的每一列的值,你將不得不檢查多個sstable。

為了達到更好的讀取性能,Cassandra對此基本設計方式進行了一些改善:

  • 壓縮策略是以插件形式提供的。例如LeveledCompactionStrategy會通過更為激進的方式組合重疊的sstable,以實現對讀取的優化。
  • Cassandra以時間倒序對sstable進行檢查,如果你要求Cassandra執行SELECT x, y FROM foo WHERE key = 42語句,當Cassandra找到x和y對應的某個最新寫入的數據時,它就不會再去檢查時間更早的sstable。同樣的原則也可以應用在對某個範圍內的掃描上,雖然稍有些麻煩,但並非不可能實現。
  • 在必須要從多個sstable中進行讀取的情況下,我們將會在讀取時將去碎片化的結果重新寫入,這樣之後的讀取操作就只需要訪問一個單獨的表了。
  • 當某個分區被訪問時,它的索引就會被緩存起來,因此只需(每個sstable)一次查找就可以訪問分區中的所有行了。
  • 存儲引擎的元數據中會從堆中被剔除出去,這樣就避免了垃圾回收帶來的影響問題。

誤解:Cassandra的運行很麻煩

比起在一台獨立的機器上運行資料庫,在一個分散式系統上運行會在以下三個方面遇到更多的困難:

  1. 初始化時的部署與配置
  2. 日常維護工作,例如升級、添加新節點、或者替換故障節點
  3. 故障檢測

Cassandra是一個完整的分散式系統:因為Cassandra集群中的每一台機器都具有相同的角色,不存在專門的元數據伺服器以調整內存中的各種信息,也不存在專門的配置伺服器以進行分發,同樣也不存在主伺服器或者是故障轉移伺服器。這種特性使運行Cassandra從各方面而言都要比其它的一些替代產品來得更簡單。這也意味著可以很方便地搭建一個單節點的集群以進行開發與測試任務,而它的功能表現與在一個包含大量節點的完整集群中的表現完全一樣。

從某種意義上說,初始化時的部署工作其實是一項最不重要的任務,因為如果其它方面的表現相同,那麼即使是初始化時的安裝稍為複雜一些,隨著系統生命周期的推移,這一點麻煩也不是很大的問題,並且自動化的安裝工具能夠為你隱藏大多數頭疼的細節問題。但是!如果你因為對某個系統的了解太小而選擇放棄手動安裝,那麼當你需要對某個問題進行故障診斷時就會遇到麻煩,因為解決問題需要你完全掌握系統中的各個部分是怎樣在一起動作的。

因此我的建議是,如果你打算利用某些工具來進行安裝,例如Windows MSI安裝文件、Oracle的Ops Center Provisioning、或是自配置的AMI,請確保你已經深刻理解了安裝過程中的細節。你可以研究一下這個搭建Cassandra集群的兩分鐘示例。

Cassandra的日常維護工作很簡單。任一時刻都可以在某台節點上進行升級工作,而當某個節點停機時,其它節點會保留本應應用在該節點上的升級內容,並在該節點恢復后將升級內容重新發送給它。此外,添加新節點的操作可以在整個集群中并行進行,在操作完成後也無需重新進行平衡。

即使是對那些時間較長的、計劃之外的停機狀態進行處理也非常方便。Cassandra可在運行時進行修復,如同其它資料庫中的rsync一樣,它只需傳輸丟失的數據即可,這就將網路數據傳輸降至最低。如果你沒有特別留意的話,也許根本不會意識到它的發生。

Cassandra在對多數據中心的支持方面在整個業界都處於領先地位,即使是整個AWS區域掛掉,甚至是整個數據中心在颶風中被摧毀這些極端情況下,也可以順利地進行恢復。

最後,DataStax OpsCenter能夠讓你隨時看到集群的各種重要系統指標,這樣就可以方便地將歷史活動數據與造成服務性能下降的事故相關聯起來,以達到簡化故障檢測的目的。Cassandra的DataStax社區版本自帶了一個“輕量級”版本的OpsCenter,可以在生產環境中免費使用。而DataStax企業版則包括了備份與恢復的調度,可配置的系統警告以及其它各種特性。

誤解:在Cassandra上進行開發非常困難

早先的Cassandra Thrift API的目標是盡量減少用戶開發一個跨平台的應用所付出的精力,而它也達到了這一目標,但現在業界已公認這套API是難以使用的。隨後Cassandra推出了一套自己的SQL語言:CQL。它提供了一套更易於使用的介面,學習曲線更為平滑,同時還推出了一套非同步協議,因此取代了Thrift API的使用。

CQL的早期使用者在兩年前就可以使用0.8版本了,而今年1月份發布的1.2版本終於使CQL成為一個可用於生產環境的產品了。新版本包含了多種驅動程序,性能也比Thrift更好。DataStax也為最流行的各種CQL驅動程序提供了官方支持,從此就可以不必再依賴來自社區的Thrift驅動程序的支持了,有時這種支持真的很差。

除了在線文檔中所介紹的CQL基礎知識外,Patrick McFadin的演講“Next Top Data Model”(第1部分、第2部分)也是一個很好的CQL介紹。

誤解:Cassandra依然是一種無人問津的邊緣產品

從開源的角度來說,Apache Cassandra已有5年的歷史,並且已經發布了多個版本,最新的版本2.0還是在今年七月剛剛發布的。而從企業的角度來說,DataStax提供了DataStax企業版,其中包含了一個經過認證的Cassandra版本,該版本經過了特定的測試、性能指標衡量、並且得到認可在生產環境中進行使用。

各個商業機構都看到了Cassandra為他們的組織所帶來的價值,財富榜上的百強內有20個機構都依賴於Cassandra為他們的關鍵應用程序提供服務,這些機構來自幾乎每個行業,包括金融、醫療、零售、娛樂、在線廣告與市場。

將應用遷移至Cassandra平台上的最常見原因之一,是現有技術的伸縮性已經不足以滿足現代化大數據應用程序的需求了。全球最大的雲應用Netflix已經將其95%的數據從Oracle遷移至Cassandra,而Barracuda Networks也用Cassandra取代了MySQL,因為MySQL已經不能夠應對巨量的垃圾請求了。而Ooyala每天都要進行20億次數據處理,它所使用的Cassandra已有超過兩個PB的數據量了。

對於那些管理和維護成本過高的陳舊的關係型資料庫,Cassandra也在逐步取而代之。Constant Contact的首個基於Cassandra的項目開發了三個月,成本為25萬美元,而他們之前基於關係型資料庫的方案則開發了九個月,花費了250萬美元。如今,他們已經搭建了6個集群,共有超過100TB的數據存放於Cassandra中。

在DataStax的案例學習頁面,以及Planet Cassandra的用戶訪問頁面上還可以找到許多其它案例。

這一條並非誤解:關於在舊金山舉辦的2013 Cassandra Summit大會

我們剛剛結束了本次會議,這可以說是學習更多Cassandra知識的最好機會了。本次會議有超過1100名與會者和65場演講,主講者分別來自Accenture、Barracuda Networks、Blue Mountain Capital、Comcast、Constant Contact、eBay、Fusion-io、Intuit、Netflix、Sony、Splunk、Spotify、Walmart和其它一些公司。演講的幻燈片已上傳,而演講視頻也即將開放下載,具體時間請密切關注Planet Cassandra的公告。

關於作者

Jonathan Ellis是DataStax公司的CTO兼聯合創始人。在創辦DataStax之前,他在受雇於Rackspace公司時在工作中大量使用了Apache Cassandra。而在Rackspace之前,他基於Reed-Solomon編碼技術,為內容備份提供商Mozy編寫了一個可容納多個PB、伸縮性良好的存儲系統。

 

查看英文原文:Cassandra Mythology



[火星人 ] 關於Cassandra的錯誤觀點已經有1219次圍觀

http://coctec.com/docs/linux/show-post-74009.html