分布式的數據存儲平臺 PNUTS

openkk 12年前發布 | 21K 次閱讀 分布式 分布式/云計算/大數據

Yahoo!的PNUTS是一個分布式的數據存儲平臺，它是 Yahoo!云計算平臺重要的一部分。它的上層產品通常也稱為Sherpa。按照官方的 描述，”PNUTS, a massively parallel and geographically distributed database system for Yahoo!’s web applications.” PNUTS顯然就深諳CAP之道，考慮到大部分web應用對一致性并不要求非常嚴格，在設計上放棄了對強一致性的追求。代替的是追求更高的 availability，容錯，更快速的響應調用請求等。

1. PNUTS簡介及特點

  • 地理分布式，分布在全球多個數據中心。由于大部分Web應用都對響應時間要求高，因此最好服務器部署在離用戶最近的本地機房。
  • 可擴展，記錄數可支持從幾萬條到幾億條。數據容量增加不會影響性能。
  • schema-free，即非固定表結構。實際使用key/value存儲的，一條記錄的多個字段實際是用json方式合并存在value中。因此delete和update必須指定primary key。但也支持批量查詢。
  • 高可用性及容錯。從單個存儲節點到整個數據中心不可用都不會影響前端Web訪問。
  • 適合存相對小型的記錄，不適合存儲大文件，流媒體等。
  • 弱一致性保證。

傳統的數據庫提供強一致性保證, 通常稱為“serialization transaction”，保證調用時序的一致性。但在web應用中不是必須，比如用戶A修改了自己的資料或上傳了圖片，他的好友B短時間不能立即看到并 不是大的問題，通常的Web應用都可以接受。PNUTS像大部分分布式key/value系統類似，提供的是弱一致性的支持，也就是支持“最終一致性 (eventually consistent)”。用戶B最終會看到用戶A的修改信息。

未夠！但最終一致性并非可以適應所有場合，比如用戶A修改了相冊的訪問權限，設置用戶C不能訪問，然后用戶A又上傳了新的圖片，如果用戶C處于另外 一個IDC訪問，如果圖片數據先同步成功，而權限記錄后同步的話，C實際上違反了A設置的權限而看到圖片了。因此對于部分場合最終一致性是不夠的。

2. PNUTS實現

2.1 Record-level mastering 記錄級別主節點

每一條記錄都有一個主記錄。比如一個印度的用戶保存的記錄master在印度機房，通常修改都會調用印度。其他地方如美國用戶看這個用戶的資料調用 的是美國數據中心的資料，有可能取到的是舊版的數據。非master機房也可對記錄進行修改，但需要master來統一管理。每行數據都有自己的版本控 制，如下圖所示。

分布式的數據存儲平臺 PNUTS

2.2 PNUTS的結構

分布式的數據存儲平臺 PNUTS
每個數據中心的PNUTS結構由四部分構成
Storage Units (SU) 存儲單元
物理的存儲服務器，每個存儲服務器上面含有多個tablets，tablets是PNUTS上的基本存儲單元。一 個tablets是一個yahoo內部格式的hash table的文件(hash table)或是一個MySQL innodb表(ordered table)。一個Tablet通常為幾百M。一個SU上通常會存在幾百個tablets。
Routers
每個tablets在哪個SU上是通過查詢router獲得。一個數據中心內router通常可由兩臺雙機備份的單元提供。
Tablet Controller
router的位置只是個內存快照，實際的位置由Tablet Controller單元決定。
Message Broker
與遠程數據的同步是由YMB提供，它是一個pub/sub的異步消息訂閱系統。

2.3 Tablets尋址與切分

存儲分hash和ordered data store。
分布式的數據存儲平臺 PNUTS
以hash為例介紹，先對所有的tablets按hash值分片，比如1-10,000屬于tablets 1, 10,000到20,000屬于tablets 2，依此類推分配完所有的hash范圍。一個大型的IDC通常會存在100萬以下的tablets, 1,000臺左右的SU。tablets屬于哪個SU由routers全部加載到內存里面，因此router訪問速度極快，通常不會成為瓶頸。按照官方的 說法，系統的瓶頸只存在磁盤文件hash file訪問上。
當某個SU訪問量過大，則可將SU中部分tablets移到相對空閑的SU，并修改tablet controller的偏移記錄。router定位tablet失效之后會自動通過tablet controller重新加載到內存。所以切分也相對容易實現。
Tim也曾經用MySQL實現過類似大規模存儲的系統，當時的做法是把每條記錄的key屬于哪個SU的信息保存到 一個字典里面，好處是切分可以獲得更大的靈活性，可以動態增加新的tablets,而不需要切分舊的tablets。但缺點就是字典沒法像router這 樣，可以高效的全部加載到內存中。所以比較而言，在實際的應用中，按段分片會更簡單，且已經足夠使用。

2.4 API訪問

支持多種級別的數據訪問API:
  • Read-any 讀取的版本有可能是舊的，返回本地IDC的數據，不檢查最新版本，性能最好。
  • Read-critical(required_version) 讀取指定版本，用戶修改資料之后調用返回比當前版本更新的版本，以保證當前用戶看到的不是修改前的記錄。
  • Read-latest 強制讀取最新，可能需要執行遠程IDC調用。比如上面例子介紹的讀取權限列表的調用。
  • Write 比如更新用戶資料
  • Test-and-set-write(required version) 只有當記錄屬于指定的版本才執行write，比如更新用戶積分等業務，這個調用有點類似以前介紹的atom操作。

Write調用示意圖分布式的數據存儲平臺 PNUTS

3. PNUTS疑問

記錄級別master的問題，比如master選取如何達到效率最佳，如何面對2個修改合并沖突?合并沖突據說是需要client自行來處理，

這篇Details on Yahoo’s distributed database提 到的平均調用latency 100ms的問題。web應用通常對每次數據的訪問最好在10ms之內完成，因為每個web頁面實際上不止一個數據訪問的調用，經常調用10次以上db的 訪問的頁面并不少見，因此如果平均latency在100ms以上那勢必影響頁面加載速度。不過yahoo!的開發人員回復paper中的數據實際是一個 老版本的測試，目前的版本，在實際生產環境的pnuts的latency會在10ms以下。

另外PNUTS為什么要用消息系統代替replication/undo log？有何優點？

4. PNUTS感悟

Web應用使用通用的存儲服務是大勢所趨，類似BigTable, Amazon Dynamo/SimpleDB這樣的方案，但是目前除非使用Amazon提供的商用SimpleDB之外幾乎沒有通用的解決方案，每個公司甚至每個項目 需要面對及考慮數據規模增大的問題。比如初步統計下國內研究可擴展數據存儲及訪問的項目就有

  • 手機之家的數據訪問層封裝DAL 2.0
  • 盛大陳思儒寫的開源項目Amoeba，類似MySQL proxy
  • 國內的Erlang geek @litaocheng 曾經對Dynamo paper深有研究，正在開發開源的erlang Dynamo實現e2dynoma
  • 豆瓣的doubanDB，也是類Dynamo實現

當然上面幾個只是冰山一角，大部分互聯網公司都有自己的數據層分布及訪問實現，只不過沒有對外公開而已。架構師、DBA、程序員具備這方面的實踐經 驗及技能當然是好事，但是如果業界能夠有通用穩定的解決方案來解決大家的重復工作則對整個業界更佳。PNUTS雖然聲稱會開源，但是一直沒有進一步消息。 而且即使開源是是開放核心代碼還是全部可用于部署的程序(比如YMB等)這也是一個問題。

介紹內容來自：http://timyang.net/architecture/yahoo-pnuts/


項目主頁：http://www.baiduhome.net/lib/view/home/1331131018312

 本文由用戶 openkk 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！