搜尋老魚筆摘(本網誌及所屬協作平台)

2010-04-28

[雲端計算] NOSQL 背後的共通原則

同樣的這篇文章, 也是老魚從簡體中文譯者那“借來”的, 除了加工再潤詞成正體中文(當然也用紅筆自行畫了重點~呵), 在文中作者提到了 Google 檔案系統論文中最初的設計基礎, 建立在“硬體與網路的失效(Failure)是必定會發生的!”, 這才是一個真正的世界, 大多的 NOSQL 實作可分為二大觀點, 重視使用硬碟, 抑或盡可能的利用 RAM做為一級存儲, 作者也進行了比較說明, 本文中對於想進入 NOSQL 技術領域者, 可以視為一篇入門文選, 所以老魚在此分享本文給各位.
  1. Wikipedia - NOSQL, http://en.wikipedia.org/wiki/NoSQL
  2. NOSQL Database ORG, http://nosql-database.org/

原文: http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html
Posted by Nati Shalom at 12:01 PM Dec 15, 2009
譯文: 王旭(http://wangxu.me , @gnawux)2009年12月 16/19日
簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master)

幾個星期之前,我寫了一篇文章描述了經常被稱作 NOSQL 這一類新型資料庫的背後需求動機。幾個星期之前,我在 Qcon 上發表了一個演講,其中,我介紹了一個 可伸縮性(scalable)的 Twitter 應用的構建模式,在我們的議論中,一個顯而易見的難題就是資料庫的 規模可伸縮性(scalability)。要解答這個問題,我試圖尋找隱藏在各種 NOSQL 背後的共通模式,並展示他們是如何解決資料庫規模可伸縮性問題的。在本文中,我將盡力勾勒出這些共通的原則。
nosql

實作者們的共通原則

假設失效是必然發生的
Assume that Failure is Inevitable


與我們在此之前認知通過昂貴硬體之類的手段盡力去避免失效的手段不同,NOSQL 實作都建立在硬碟、機器和網路都會失效(Failure)這些假設之上。我們有需要承認,我們不能徹底阻止這些失效,相反,我們需要讓我們的系統能夠在假使非常極端的條件下也能應付這些失效。Amazon S3 就是這種設計的一個好例子。你可以在我最近的文章 Why Existing Databases (RAC) are So Breakable! 中找到進一步描述。在那裡,我介紹了一些來自 Jason McHugh 所講演的以"失效"為導向的架構設計內容(Jason 是在 Amazon 做 S3 相關工作的高階工程師)。

對資料進行分區
Partition the Data

通過對資料進行分區(分割),我們最小化了失效帶來的服務失效影響,也將讀寫操作的負載分佈到了不同的機器上。如果一個節點(Node)失效了,只有該節點上存儲的資料受到影響,而不是全部的資料。

對同一資料保持多個副本
Keep Multiple Replicas of the Same Data
大部分 NOSQL 實作都基於資料副本的熱備份(hot-backup)來保證連續的高可用性(high availability)。某些實作產品提供了 API,可以控制副本的複製,也就是說,當你存儲一個物件的時候,你可以在物件級別指定你希望保存的副本數量。在 GigaSpaces,我們還可以立即複製一個新的副本到其他節點,甚至在必要時啟動一台新機器。這讓我們不必在每個節點上保存太多的資料副本,從而降低總存儲量以節約成本。
你還可以控制副本複製是同步(synchronous)還是異步(非同步, asynchronous)的,或者兩者兼俱。這決定了你的叢集(Cluster)的一致性、可用性與性能[consistency, reliability and performance]三者。對於同步複製,可以犧牲性能保障一致性和可用性(進行寫入作業之後的任意讀取作業都可以保證得到相同版本的資料,即使是發生失效也會如此)。而最為常見的 GigaSpaces 的配置是同步副本到被分界點,異步存儲到後端存儲。

動態伸縮
Dynamic Scaling
要掌控不斷呈線性增長的資料量,大部分 NOSQL 實作提供了不停機或完全重建分區的擴展叢集的方法。一個已知的處理這個問題的演算法稱為一致性雜湊法(consistent hashing)。有很多種不同演算法可以實作一致性雜湊演算。
演算法會在節點加入或失效時 通知某一分區的鄰近節點。僅有這些節點受到這一變化的影響,而不是整個叢集。有一個協議用於掌控需要在原有叢集和新節點之間重新分佈的資料的變換區間。
另一個(簡單很多)的演算法使用邏輯分區。在邏輯分區中,分區的數量是固定的,但分區在機器上的分佈式動態的。於是,例如有兩台機器和 1000 個邏輯分區,那麼每 500 個邏輯分區會放在一台機器上。當我們加入了第三台機器的時候,就成了每 333 個分區放在一台機器上了。因為邏輯分區是輕量級的(基於在記憶體中的雜湊表[hash table]),分散這些邏輯分區非常容易。
第二種方法的優勢在於它是可預測並且一致的,而使用一致性雜湊演算方法,分區之間的重新分佈可能並不平穩,當一個新節點加入網路時可能會消耗更長時間。一個使用 者在這時尋找正在轉移的資料會得到一個異常。邏輯分區方法的缺點是可伸縮性受限於邏輯分區的數量。
更進一步的關於這一問題的討論,建議閱讀 Ricky Ho 的文章 NOSQL Patterns

對查詢式的支持
Query Support

在這個方面,不同的實作有著本質上相當的區別。不同實作的一個共通性在於雜湊表中的 key/value 匹配。有些實作提供了更高階的查詢式支持,例如文檔導向(document-oriented)的方 法,其中資料以 blob 的方式存儲,關聯一個鍵值對屬性列表(List)。這種模型是一種無預定義結構的(schema-less)存儲,對一個文檔增加或刪除屬性是非常容易 地,無需考慮文檔結構的演變。而 GigaSpaces 支持很多 SQL 操作。假如 SQL 查詢沒有指出特定的鍵值(key),那麼這個查詢就會被平行地(parallel query) map 到所有的節點去,由客戶端完成結果的聚合(aggregated)。所有這些都是發生在系統後端的,使用者程式碼無需關注這些。

使用 Map/Reduce 處理聚合
Use Map/Reduce to Handle Aggregation

Map/Reduce 是一個經常被用來進行複雜分析的模型,經常會和 Hadoop 聯繫在一起。 map/reduce 常常被看作是平行聚合查詢(parallel aggregated queries)的一種模式。大部分 NOSQL 實作並不提供 map/reduce 的內建支持,需要一個外部的框架來處理這些查詢。對於 GigaSpaces 來說,我們在 SQL 查詢中隱含了對 map/reduce 的支持,同時也顯式地提供了一個稱為 executors 的 API 來支持 map/reduce。在這模型中,你可以將程式碼發送到資料所在地地方,並在該節點上直接運行複雜的查詢。這方面的更多細節,建議閱讀 Ricky Ho 的文章 Query Processing for NOSQL DB

磁碟基礎 vs. 內部記憶體的實作
Disk-Based vs. In-Memory Implementation

NOSQL 實作分為基於檔案的方法和在記憶體(RAM)中的方法。有些實作提供了混合模型,將RAM和磁碟結合使用。兩類方法的最主要區別在於每 GB 成本和讀寫(R/W)性能。
最近,Stanford University 斯坦福的一項稱為「The Case for RAMCloud」的調查,對磁碟和 RAM 兩種方法給出了一些性能和成本方面的有趣比較。總體上說,成本也是性能的一個函數。對於較低性能的實作,磁碟方案的成本遠低於基於 RAM 的方法,而對於高性能需求的場合,RAM 方案則更加廉價。
記憶體型態雲端系統 (RAMClouds)最顯而易見的缺點就是單位容量的高成本和高電能耗損。對於這些指標,RAMClouds 會比純粹的磁碟系統差 50到 100倍,比使用快閃記憶體(flash memory)的系統差5-10倍(典型配置情況和指標參見參考文獻[1])。RAMClouds 同時還比基於磁碟和快閃記憶體的系統需要更多的機房面積。這樣,如果一個應用需要存儲大量的廉價資料,不需要高速存取,那麼,快閃記憶體將不是最佳選擇。
然而,對於要求高吞吐量需求的應用,RAMClouds 將更有競爭力。當使用每次操作的 成本和電能耗損作為衡量因素的時候,RAMClouds 的效率是傳統硬碟系統的 100 到 1000 倍,是快閃憶記體系統的 5-10 倍。因此,對於高吞吐量需求的系統來說,RAMClouds不僅提供了高性能,也提供了更高的效率。同時,如果使用 DRAM 動態記憶體晶片組提供的低功耗模式,也可以降低 RAMClouds 的電能功耗,特別是在系統閒置的時候。此外,RAMClouds 還有一些缺點,一些 RAMClouds 無法支持需要將資料在多個資料中心之間進行資料複製。對於這些環境,更新的時間延遲將主要取決於資料中心間資料傳輸的時間消耗,這就喪失了 RAMClouds 的時延方面的優勢。此外,跨資料中心的資料複製會讓 RAMClouds 資料一致性更能難保證。不過,RAMClouds 仍然可以在跨資料中心的情況下提供低時延的讀寫存取。
僅僅是炒作?
近來我見到的最多的 問題就是 「NOSQL 是不是就是炒作?」 或 「NOSQL 會不會取代現在的資料庫?」
我的回答是——NOSQL 並非始於今日。很多 NOSQL 實作都已經存在了十多年了,有很多成功案例。我相信有很多原因讓它們在如今比以往更受歡迎了。首 先是由於社交性網路(social networking)雲端計算(cloud computing)的發展,一些原先只有很高端的組織才會面臨的問題,如今已經成為普遍問題了。 其次,已有的方法已經被發現無法跟隨需求一起擴展了。並且,成本的壓力讓很多組織需要去尋找更高性能的成本效益的價比方案,並且研究證實基於普通廉價硬體的分散式存儲解決方案,  甚至比現在的高端且高貴的關聯式資料庫系統(RDBMS)更加可靠。進一步閱讀)所有這些導致了對這類「可伸縮性優先資料庫」的需求。這裡,我引用 AWS團隊的接觸工程師、VP, James Hamilton 在他的文章 One Size Does Not Fit All 中的一段話:
規模可伸縮性優先考慮是那些必須具備無限可伸縮性的應用,能夠不受限制的擴展比更豐富的功能更加重要。這些應用包括很多需要高可伸縮性的網站,如 Facebook, MySpace, Gmail, Yahoo 以及 Amazon.com。有些網站實際上使用了關聯型資料庫系統(RDBMS),而大部分實際上均並未採用之。這些服務的共通性在於對規模可伸縮性的需求比功能更重要,他們無法將應用泡製在一個單一 RDBMS 上。」
總結一下——我認為,現有的 SQL 資料庫可能不會很快淡出歷史舞台,但同時它們也不能解決世上的所有問題。NOSQL 這個名詞現在也變成了 Not Only SQL,這個變化表達了我的觀點。

參考

2 則留言:

  1. 好文!
    Not Only SQL,真是比AntiSQL 或No SQL有創意多了!

    回覆刪除

熱門文章

大智若魚::人生處處是道場-站內SEO參考標籤雲