從myspace數據庫看分佈式系統數據結構變遷
MySpace已經成爲全球衆口皆碑的社區網站之王。儘管一流和營銷和管理經驗自然是每個IT企業取得成功的首要因素，但是我們卻拋棄這一點，而主要着眼於探討在數次面臨系統擴張的緊急關頭MySpace是如何從技術方面採取應對策略的。
MySpace信息系統發展歷程：
第一代架構—添置更多的Web服務器
MySpace最初的系統很小，只有兩臺Web服務器（分擔處理用戶請求的工作量）和一個數據庫服務器（所有數據都存儲在這一個地方）。那時使用的是 Dell雙CPU、4G內存的系統。在早期階段，MySpace基本是通過添置更多Web服務器來對付用戶暴增問題的。但到在2004年早期，在 MySpace用戶數增長到五十萬後，其數據庫服務器已經開始疲於奔命了。
第二代架構—增加數據庫服務器
與增加Web服務器不同，增加數據庫並沒那麼簡單。如果一個站點由多個數據庫支持，設計者必須考慮的是，如何在保證數據一致性的前提下讓多個數據庫分擔壓力。
MySpace運行在三個SQL Server數據庫服務器上—一個爲主，所有的新數據都向它提交，然後由它複製到其它兩個；另兩個數據庫服務器全力向用戶供給數據，用以在博客和個人資料欄顯示。這種方式在一段時間內效果很好——只要增加數據庫服務器，加大硬盤，就可以應對用戶數和訪問量的增加。
這一次的數據庫架構按照垂直分割模式設計，不同的數據庫服務於站點的不同功能，如登錄、用戶資料和博客。垂直分割策略利於多個數據庫分擔訪問壓力，當用戶要求增加新功能時，MySpace只需要投入新的數據庫加以支持。在賬戶到達二百萬後，MySpace還從存儲設備與數據庫服務器直接交互的方式切換到SAN（存儲區域網絡）—用高帶寬、專門設計的網絡將大量磁盤存儲設備連接在一起，而數據庫連接到SAN。這項措施極大提升了系統性能、正常運行時間和可靠性。然而，當用戶繼續增加到三百萬後，垂直分割策略也變得難以維持下去。
第三代架構—轉到分佈式計算架構
幾經折騰，最終，MySpace將目光移到分佈式計算架構——它在物理上分佈的衆多服務器，整體必須邏輯上等同於單臺機器。拿數據庫來說，就不能再像過去那樣將應用拆分，再以不同數據庫分別支持，而必須將整個站點看作一個應用。現在，數據庫模型裏只有一個用戶表，支持博客、個人資料和其他核心功能的數據都存儲在相同數據庫。
既然所有的核心數據邏輯上都組織到一個數據庫，那麼MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數據庫服務器是無能爲力的。這次，不再按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，然後將各組的全部數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約二百萬用戶。據MySpace的技術人員說，以後還可以按照這種模式以更小粒度劃分架構，從而優化負荷分擔。
第四代架構—求助於微軟方案
2005年早期，賬戶達到九百萬，MySpace開始用微軟的C#編寫 ASP.NET程序。在收到一定成效後，MySpace開始大規模遷移到ASP.NET。用戶達到一千萬時，MySpace再次遭遇存儲瓶頸問題。SAN 的引入解決了早期一些性能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量——即它從磁盤存儲系統讀寫數據的極限速度。
第五代架構—增加數據緩存層並轉到支持64位處理器的SQL Server 2005
2005年春天，MySpace賬戶達到一千七百萬，MySpace又啓用了新的策略以減輕存儲系統壓力，即增加數據緩存層——位於Web服務器和數據庫服務器之間，其唯一職能是在內存中建立被頻繁請求數據對象的副本，如此一來，不訪問數據庫也可以向Web應用供給數據。
2005年中期，服務賬戶數達到兩千六百萬時，MySpace因爲我們對內存的渴求而切換到了還處於beta測試的支持64位處理器的SQL Server 2005。升級到SQL Server 2005和64位Windows Server 2003後，MySpace每臺服務器配備了32G內存，後於2006年再次將配置標準提升到64G。
事實上，MySpace的Web服務器和數據庫仍然經常發生超負荷，其用戶頻繁遭遇“意外錯誤”和“站點離線維護”等告示，他們不得不在論壇抱怨不停……
MySpace正是在這樣不斷重構站點軟件、數據庫和存儲系統中，才一步步走到今天。事實上，MySpace已經成功解決了很多系統擴展性問題，其中存在相當的經驗值得我們借鑑。MySpace系統架構到目前爲止保持了相對穩定，但其技術人員仍然在爲SQL Server支持的同時連接數等方面繼續攻堅，儘可能把事情做到最好。
雖然自2005年早期，站點賬戶數超過7百萬後，系統架構到目前爲止保持了相對穩定，但MySpace仍然在爲SQL Server支持的同時連接數等方面繼續攻堅。
里程碑一：50萬賬戶
MySpace最初的系統很小，只有兩臺Web服務器和一個數據庫服務器。那時使用的是Dell雙路CPU、4G內存的系統。
單個數據庫就意味着所有數據都存儲在一個地方，再由兩臺Web服務器分擔處理用戶請求的工作量。但就像MySpace後來的幾次底層系統修訂時的情況一樣，三服務器架構很快不堪重負。此後一個時期內，MySpace基本是通過添置更多Web服務器來對付用戶暴增問題的。
但到在2004年早期，MySpace用戶數增長到50萬後，數據庫服務器也已開始汗流浹背。
但和Web服務器不同，增加數據庫可沒那麼簡單。如果一個站點由多個數據庫支持，設計者必須考慮的是，如何在保證數據一致性的前提下，讓多個數據庫分擔壓力。
在第二代架構中，MySpace運行在3個SQL Server數據庫服務器上——一個爲主，所有的新數據都向它提交，然後由它複製到其他兩個；另兩個全力向用戶供給數據，用以在博客和個人資料欄顯示。這種方式在一段時間內效果很好——只要增加數據庫服務器，加大硬盤，就可以應對用戶數和訪問量的增加。
里程碑二：1-2百萬賬戶
MySpace註冊數到達1百萬至2百萬區間後，數據庫服務器開始受制於I/O容量——即它們存取數據的速度。而當時纔是2004年中，距離上次數據庫系統調整不過數月。用戶的提交請求被阻塞，就像千人樂迷要擠進只能容納幾百人的夜總會，站點開始遭遇"主要矛盾"，Benedetto說，這意味着MySpace永遠都會輕度落後於用戶需求。
有人花5分鐘都無法完成留言，因此用戶總是抱怨說網站已經完蛋了。這一次的數據庫架構按照垂直分割模式設計，不同的數據庫服務於站點的不同功能，如登錄、用戶資料和博客。於是，站點的擴展性問題看似又可以告一段落了，可以歇一陣子。
垂直分割策略利於多個數據庫分擔訪問壓力，當用戶要求增加新功能時，MySpace將投入新的數據庫予以支持它。賬戶到達2百萬後，MySpace還從存儲設備與數據庫服務器直接交互的方式切換到SAN（Storage Area Network，存儲區域網絡）——用高帶寬、專門設計的網絡將大量磁盤存儲設備連接在一起，而數據庫連接到SAN。這項措施極大提升了系統性能、正常運行時間和可靠性。
里程碑三：3百萬賬戶
當用戶繼續增加到3百萬後，垂直分割策略也開始難以爲繼。儘管站點的各個應用被設計得高度獨立，但有些信息必須共享。在這個架構裏，每個數據庫必須有各自的用戶表副本——MySpace授權用戶的電子花名冊。這就意味着一個用戶註冊時，該條賬戶記錄必須在9個不同數據庫上分別創建。但在個別情況下，如果其中某臺數據庫服務器臨時不可到達，對應事務就會失敗，從而造成賬戶非完全創建，最終導致此用戶的該項服務無效。
另外一個問題是，個別應用如博客增長太快，那麼專門爲它服務的數據庫就有巨大壓力。
2004年中，MySpace面臨Web開發者稱之爲"向上擴展"對"向外擴展"（譯者注：Scale Up和Scale Out，也稱硬件擴展和軟件擴展）的抉擇——要麼擴展到更大更強、也更昂貴的服務器上，要麼部署大量相對便宜的服務器來分擔數據庫壓力。一般來說，大型站點傾向於向外擴展，因爲這將讓它們得以保留通過增加服務器以提升系統能力的後路。
但成功地向外擴展架構必須解決複雜的分佈式計算問題，大型站點如Google、Yahoo和Amazon.com，都必須自行研發大量相關技術。以Google爲例，它構建了自己的分佈式文件系統。
另外，向外擴展策略還需要大量重寫原來軟件，以保證系統能在分佈式服務器上運行。"搞不好，開發人員的所有工作都將白費"，Benedetto說。因此，MySpace首先將重點放在了向上擴展上，花費了大約1個半月時間研究升級到32CPU服務器以管理更大數據庫的問題。Benedetto說，"那時候，這個方案看似可能解決一切問題。"如穩定性，更棒的是對現有軟件幾乎沒有改動要求。
糟糕的是，高端服務器極其昂貴，是購置同樣處理能力和內存速度的多臺服務器總和的很多倍。而且，站點架構師預測，從長期來看，即便是巨型數據庫，最後也會不堪重負，Benedetto說，"換句話講，只要增長趨勢存在，我們最後無論如何都要走上向外擴展的道路。"
因此，MySpace最終將目光移到分佈式計算架構——它在物理上分佈的衆多服務器，整體必須邏輯上等同於單臺機器。拿數據庫來說，就不能再像過去那樣將應用拆分，再以不同數據庫分別支持，而必須將整個站點看作一個應用。現在，數據庫模型裏只有一個用戶表，支持博客、個人資料和其他核心功能的數據都存儲在相同數據庫。
既然所有的核心數據邏輯上都組織到一個數據庫，那麼MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數據庫服務器是無能爲力的。這次，不再按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，然後將各組的全部數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約2百萬用戶。Benedetto指出，以後還可以按照這種模式以更小粒度劃分架構，從而優化負荷分擔。
當然，還是有一個特殊數據庫保存了所有賬戶的名稱和密碼。用戶登錄後，保存了他們其他數據的數據庫再接管服務。特殊數據庫的用戶表雖然龐大，但它只負責用戶登錄，功能單一，所以負荷還是比較容易控制的。
里程碑四：9百萬到1千7百萬賬戶
2005年早期，賬戶達到9百萬後，MySpace開始用Microsoft的C#編寫ASP.NET程序。C#是C語言的最新派生語言，吸收了C++ 和Java的優點，依託於Microsoft .NET框架（Microsoft爲軟件組件化和分佈式計算而設計的模型架構）。ASP.NET則由編寫Web站點腳本的ASP技術演化而來，是 Microsoft目前主推的Web站點編程環境。
可以說是立竿見影， MySpace馬上就發現ASP.NET程序運行更有效率，與ColdFusion相比，完成同樣任務需消耗的處理器能力更小。據技術總監 Whitcomb說，新代碼需要150臺服務器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，性能上升的另一個原因可能是在變換軟件平臺，並用新語言重寫代碼的過程中，程序員複審並優化了一些功能流程。
最終，MySpace開始大規模遷移到 ASP.NET。即便剩餘的少部分ColdFusion代碼，也從Cold-Fusion服務器搬到了ASP.NET，因爲他們得到了 BlueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的產品，它能將ColdFusion代碼自動重新編譯到Microsoft平臺）的幫助。
賬戶達到1千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量——即它從磁盤存儲系統讀寫數據的極限速度。
原因之一是每數據庫1百萬賬戶的分割策略，通常情況下的確可以將壓力均分到各臺服務器，但現實並非一成不變。比如第七臺賬戶數據庫上線後，僅僅7天就被塞滿了，主要原因是佛羅里達一個樂隊的歌迷瘋狂註冊。
某個數據庫可能因爲任何原因，在任何時候遭遇主要負荷，這時，SAN中綁定到該數據庫的磁盤存儲設備簇就可能過載。"SAN讓磁盤I/O能力大幅提升了，但將它們綁定到特定數據庫的做法是錯誤的。"Benedetto說。
最初，MySpace通過定期重新分配SAN中數據，以讓其更爲均衡的方法基本解決了這個問題，但這是一個人工過程，"大概需要兩個人全職工作。"Benedetto說。
長期解決方案是遷移到虛擬存儲體系上，這樣，整個SAN被當作一個巨型存儲池，不再要求每個磁盤爲特定應用服務。MySpace目前採用了一種新型SAN設備——來自加利福尼亞州弗裏蒙特的3PARdata。
在3PAR的系統裏，仍能在邏輯上按容量劃分數據存儲，但它不再被綁定到特定磁盤或磁盤簇，而是散佈於大量磁盤。這就使均分數據訪問負荷成爲可能。當數據庫需要寫入一組數據時，任何空閒磁盤都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經過載的磁盤陣列處。而且，因爲多個磁盤都有數據副本，讀取數據時，也不會使SAN的任何組件過載。
當2005年春天賬戶數達到1千7百萬時，MySpace又啓用了新的策略以減輕存儲系統壓力，即增加數據緩存層——位於Web服務器和數據庫服務器之間，其唯一職能是在內存中建立被頻繁請求數據對象的副本，如此一來，不訪問數據庫也可以向Web應用供給數據。換句話說，100個用戶請求同一份資料，以前需要查詢數據庫100次，而現在只需1次，其餘都可從緩存數據中獲得。當然如果頁面變化，緩存的數據必須從內存擦除，然後重新從數據庫獲取——但在此之前，數據庫的壓力已經大大減輕，整個站點的性能得到提升。
緩存區還爲那些不需要記入數據庫的數據提供了驛站，比如爲跟蹤用戶會話而創建的臨時文件——Benedetto坦言他需要在這方面補課，"我是數據庫存儲狂熱分子，因此我總是想着將萬事萬物都存到數據庫。"但將像會話跟蹤這類的數據也存到數據庫，站點將陷入泥沼。
里程碑五：2千6百萬賬戶
2005年中期，服務賬戶數達到2千6百萬時，MySpace切換到了還處於beta測試的SQL Server 2005。轉換何太急？主流看法是2005版支持64位處理器。但Benedetto說，"這不是主要原因，儘管這也很重要；主要還是因爲我們對內存的渴求。"支持64位的數據庫可以管理更多內存。
更多內存就意味着更高的性能和更大的容量。原來運行32位版本的SQL Server服務器，能同時使用的內存最多隻有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQL Server 2005和64位Windows Server 2003後，MySpace每臺服務器配備了32G內存，後於2006年再次將配置標準提升到64G。
意外錯誤促進系統健康成長
如果沒有對系統架構的歷次修改與升級，MySpace根本不可能走到今天。但是，爲什麼系統還經常吃撐着了？很多用戶抱怨的"意外錯誤"是怎麼引起的呢？
原因之一是MySpace對Microsoft的Web技術的應用已經進入連Microsoft自己也纔剛剛開始探索的領域。比如11月，超出SQL Server最大同時連接數，MySpace系統崩潰。Benedetto說，這類可能引發系統崩潰的情況大概三天才會出現一次，但仍然過於頻繁了，以致惹人惱怒。一旦數據庫罷工，"無論這種情況什麼時候發生，未緩存的數據都不能從SQL
Server獲得，那麼你就必然看到一個'意外錯誤'提示。"他解釋說。
去年夏天，MySpace的Windows 2003多次自動停止服務。後來發現是操作系統一個內置功能惹的禍——預防分佈式拒絕服務攻擊（黑客使用很多客戶機向服務器發起大量連接請求，以致服務器癱瘓）。MySpace和其他很多頂級大站點一樣，肯定會經常遭受攻擊，但它應該從網絡級而不是依靠Windows本身的功能來解決問題——否則，大量 MySpace合法用戶連接時也會引起服務器反擊。
"我們花了大約一個月時間尋找Windows 2003服務器自動停止的原因。"Benedetto說。最後，通過Microsoft的幫助，他們才知道該怎麼通知服務器："別開槍，是友軍。"
緊接着是在去年7月某個週日晚上，MySpace總部所在地洛杉磯停電，造成整個系統停運12小時。大型Web站點通常要在地理上分佈配置多個數據中心以預防單點故障。本來，MySpace還有其他兩個數據中心以應對突發事件，但Web服務器都依賴於部署在洛杉磯的SAN。沒有洛杉磯的SAN，Web服務器除了懇求你耐心等待，不能提供任何服務。
Benedetto說，主數據中心的可靠性通過下列措施保證：可接入兩張不同電網，另有後備電源和一臺儲備有30天燃料的發電機。但在這次事故中，不僅兩張電網失效，而且在切換到備份電源的過程中，操作員燒掉了主動力線路。
2007年中，MySpace在另兩個後備站點上也建設了SAN。這對分擔負荷大有幫助——正常情況下，每個SAN都能負擔三分之一的數據訪問量。而在緊急情況下，任何一個站點都可以獨立支撐整個服務，Benedetto說。
MySpace仍然在爲提高穩定性奮鬥，雖然很多用戶表示了足夠信任且能原諒偶現的錯誤頁面。
"作爲開發人員，我憎惡Bug，它太氣人了。"Dan Tanner這個31歲的德克薩斯軟件工程師說，他通過MySpace重新聯繫到了高中和大學同學。"不過，MySpace對我們的用處很大，因此我們可以原諒偶發的故障和錯誤。" Tanner說，如果站點某天出現故障甚至崩潰，恢復以後他還是會繼續使用。
這就是爲什麼Drew 在論壇裏咆哮時，大部分用戶都告訴他應該保持平靜，如果等幾分鐘，問題就會解決的原因。Drew無法平靜，他寫道，"我已經兩次給MySpace發郵件，而它說一小時前還是正常的，現在出了點問題……完全是一堆廢話。"另一個用戶回覆說，"畢竟它是免費的。"Benedetto坦承100%的可靠性不是他的目標。"它不是銀行，而是一個免費的服務。"他說。
換句話說，MySpace的偶發故障可能造成某人最後更新的個人資料丟失，但並不意味着網站弄丟了用戶的錢財。"關鍵是要認識到，與保證站點性能相比，丟失少許數據的故障是可接受的。"Benedetto說。所以，MySpace甘冒丟失2分鐘到2小時內任意點數據的危險，在SQL Server配置裏延長了"checkpoint"操作——它將待更新數據永久記錄到磁盤——的間隔時間，因爲這樣做可以加快數據庫的運行。
Benedetto說，同樣，開發人員還經常在幾個小時內就完成構思、編碼、測試和發佈全過程。這有引入Bug的風險，但這樣做可以更快實現新功能。而且，因爲進行大規模真實測試不具可行性，他們的測試通常是在僅以部分活躍用戶爲對象，且用戶對軟件新功能和改進不知就裏的情況下進行的。因爲事實上不可能做真實的加載測試，他們做的測試通常都是針對站點。
總結一點：從myspace看更加驗證，數據庫是軟件系統的瓶頸，而且最不可伸縮，一旦數據庫成爲系統瓶頸，就得動大手術，實現架構上的變遷，這是傷筋動骨，變遷人員壓力巨大的。另外由於是社區，就是變遷數據丟失也沒什麼大不了，如果是企業那就......
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34551&message=23116484#23116484
我最欣賞Gavin King的這句話，狠狠煽了那些曾經跟隨Gavin King人的耳光：
數據庫成爲了大多數企業應用的主要瓶頸，也成爲了運行環境中最不具伸縮性的層。
PHP/Ruby的用戶會說什麼都不共享（share nothing）的架構照樣具有很好的伸縮性，這些傻瓜真正想的是“除了數據庫以外什麼都不共享(Share nothing except for the database)”的架構
我先來翻譯一下上面這段意思：經過大量實踐證明：數據庫已經成爲企業計算主要性能瓶頸，因爲我們大量業務計算依賴數據庫，雖然，數據庫可以集羣，但是代價昂貴，效率不高，而且最多兩臺或幾臺，因此，數據庫已經成爲運行環境中最不scalable的環節。
所謂伸縮性，就是彈性，整個軟件架構既支持小負載運行，也支持大負載支持，只要增加服務器（PC服務器價格是便宜）即可；沒有伸縮性意思這個軟件小負載可以運行，到大負載，就有天花板了，即使進行數據庫性能調優（這也是不少人覺得數據庫技術很重要的原因），也只是緩口氣，性能調優也有天花板，單臺機器挖潛力總是有限的，向下死挖的概念就造成現在很多人對數據庫調優技術的依賴；其實這些人爲什麼不向上想想，一臺不夠，我再增加一臺，只要配置一下即可，經過權威測試：websphere/weblogic的20臺PC服務器集羣性能不亞於一臺SUN/IBM的中型機，性價比已經一目瞭然了。
跟隨PHP/Ruby的那些傻瓜用戶認識到這點，就開始迴避，宣稱：share nothing，其實這是不可能的，應用中的很多數據都是依靠反覆訪問同一個數據庫來達到共享，所以，實質是：Share nothing except for the database，類似鴕鳥把頭插入沙子，認爲就可以解決問題。
那麼我們看看EJB或分佈式緩存是如何解決這個共享問題：因爲軟件業務邏輯都是基於對象的，而這些對象可以在多臺websphere/weblogic/jboss之間傳輸，通過分佈式緩存就解決了共享問題，應用邏輯不必每次都要通過數據庫來分享數據，應用邏輯之間本身可以直接傳輸業務對象數據，以達到分享。
所以，PHP/Ruby運行環境的架構特點還都是依賴數據庫的，雖然他們打着Evans
DDD口號，並且聲稱Ruby On Rails還是最適合DDD的，到時到最後落實代碼時，就露出馬腳，披着羊皮的狼，批着DDD，實則是以數據庫中心。這也是爲什麼一些程序員既認爲分析設計是要採取DDD，但是數據庫技術依然重要的原因，這些都是不徹底的對象程序員，他們必然遭遇對象/關係數據庫帶來的複雜性，然後他們錯以爲是語言問題，轉而追尋ROR這樣動態語言，希望這個新語言能解救他們，雖然ROR有類似Hibernate之類ActiveRecord等ORM框架，由於運行環境還是依賴不伸縮的數據庫，當系統複雜時，他們又會碰到OO/db的不匹配，真是傻瓜了。
當然，這種畸形也許適合一些中庸的中國程序員(對象和數據庫兩個都要)。不是我在大喊數據庫時代過去時，那麼多人反對，反對弱化數據庫，因爲他們腦子裏數據庫爲王已經根深蒂固，就像一個保皇派，保數據庫這個皇帝，大權不能旁落。
另外：我一直提出的Open Session In View是一個在Spring中無法解決的問題，是一個反模式，這點在Seam中也得到了解決，這說明是一個真理，我喜歡在Jdon說真話，很多言論都可以查詢，2003年至今我沒有發現嚴重的錯誤觀點和預測，唯一沒料到的是：PHP比我想象中頑強。
