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來統一管理。每行資料都有自己的版本控 制，如下圖所示。
2.2 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。
以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調用示意圖
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/