Scale OUT還是Scale UP？

做web2.0網站，一個普遍的感覺就是計劃不如變化。在吸引風險投資的時候，我們可以做出種種規劃，在某某年吸引多少多少使用者，PV/UV達到多少，我 們都期待使用者量的快速增長，因為互連網的普遍模式還是先圈使用者，但增長還是不增長，增長多少往往是無法事先預計的。在這種情況下，配置多少儲存和運算能 力，在什麼時候增加儲存和運算能力是個考驗人的問題。儲存和運算能力的閑置，浪費金錢，但儲存和運算能力不夠，網站垮掉也是我們所不願意看到的。雲端運算的
概念吹了很久，在中國還是看不到影子。作為技術人員，當然是期望有雲端運算平台的出現（其實很多web2.0網站也沒什麼多麼核心的資料資產那麼令人擔 心），按需購置儲存和計算能力就好，不要老深更半夜的往機房裡面跑。但現實是在中國，我們還需要自己購置存放裝置、伺服器和頻寬，自己去維護。

  從企業IT架構體繫上來看，對於web2.0網站來說，必須考慮的就是可擴充性：隨著使用人數的增多，能夠及時的擴充IT系統的能力。解決這個問題，通常 有兩種解決方式：Scale up和Scale out，兩種擴容的方式分別從兩個維度來解決資料庫壓力。所謂Scale up就是向上擴容，Scale
out就是平面型的擴容。縱向的擴容就是將DB Server的配置提高，增加硬體設定，通過硬體速度提升來解決訪問壓力，橫向擴容就是將應用的資料拆分，將原來集中儲存的資料根據一定的規則分布到不同 的物理資料庫伺服器上。Up模式實施成本較高，大到一定壓力之後，硬體可能無法滿足這類需求。從web2.0網站來看，如果能夠通過疊加相對廉價裝置的方 式實現儲存和計算能力的擴充，是長期可擴充的有效手段，這點是Scale out所帶來的優勢。

  對網路儲存來說，共用儲存是必須的。無論資料區塊或檔案、本地化或遠程，都不希望停留在單處理環境中。資料中心需要全新的服務，不只是關於伺服器、儲存或網 絡產品的，而是關於建立系統的應用和基礎架構資源，企業建立的系統要能夠輕鬆適應未來的需求。目前來看，在儲存領域採用Scale out的方式是一種比較流行的模式，很多公司也推出了相應的產品和服務。在最近IBM公司發布了一款全新的、可高度擴充的磁碟儲存系統，該系統技術來自
IBM公司在今年一月份收購的XiV公司，旨在應對如今的多種複合資訊，這些資訊來自從Web 2.0到金融服務等傳統應用。由XiV公司技術開發而來的這一全新企業級磁碟產品，展現了一種獨特的基於網格的儲存架構，可以更加輕鬆地管理，並可實現更 好的效能擴充，配有自調整/恢複及自動精簡配置功能，能夠協助降低資訊儲存的成本和複雜性，同時支援現在動態工作負載下對資料進行持續快速存取的要求。根 據IBM公司的介紹，XiV系統基於SATA磁碟，運用了一種獨特的並行架構及緩衝演算法，不但消除了熱點，其效能水平也遠遠超出那些基於FC的磁碟系統。
此外，IBM發布的擴充檔案服務(SOFS, scale out file services)能夠協助企業快速實現高度可擴充的全球化叢集NAS系統，從而能夠協助緩解當前的資料存放區挑戰，尤其是當前儲存網路頻寬不足給企業所帶 來的困擾。

  國外很多web2.0的網站通過Scale out的方式，比如Flickr和digg，解決了平穩服務下的計算能力擴充的問題。Flickr網站通過Shards這種模式，利用眾多的價格低廉資料 程式庫伺服器橫向分布資訊，在每天處理億級的事務情況下回應時間還是很快，同時在資訊不斷膨脹的情況下擴充的成本很低，擴充對於網站的影響基本沒有。
Shards含義是片段，在這裡的意思是將應用的資料橫向拆分，也就是說如果有幾千萬的使用者資訊，那麼這些使用者資訊可以被分布在多個資料庫伺服器上，這種 分組分布資料到不同的資料庫伺服器上，橫向切分資料區塊就叫做Shards。Digg的處理方式也蠻有意思，它把主要的使用者訪問量大的資料與其他的使用者訪問 量小的資料做sharding，對於那些訪問量大的“熱”資料用更好的硬體，提供更好的服務體驗，而其他的資料儘管訪問速度稍慢一點，對使用者來說，影響也 很小。

  不過另外一方面，Scale out這種方式策略的制定複雜度以及維護成本要高於Scale up。採用Scale out這種方式，首先需要解決複雜的分散式運算的問題（相對來說Scale Up方案不需要考慮這個問題），這對於很多國內的web2.0網站的技術人員來說，是一個巨大的技術門檻；另外，Scale
Out方案還需要對原先的軟體進行大量的重寫工作，以保證系統能在分布式伺服器上運行（Scale Up方案則對現有軟體幾乎沒有改動要求）；還有就是Scale Out方案始終面臨著資料集中的問題，即拆分過的資料在伺服器邏輯體系中仍然是各自相對集中的而非無限隨意拆分。

  對於分散式運算的技術問題，國外有一些開源的項目，我們可以借鑒，在一定程度上可以去努力解決。與此同時，我們還需要考慮到我們自身網站的資料的特點。像 聯機遊戲、IM、BSP這些資料，通常每個使用者都可以抽象成一個資料對象，可以隔離儲存區 (Isolated Storage)在任何一個地方，資料之間關聯度不大，這種情況比較適合採用
Scale Out的方式。但對於另外一些資料，比如電子商務網站的買賣資訊，它們之間的關聯度大，這時候往往查詢需要耗費很多的資源；還有一些事物型的應用，保證數 據的完整性是更為重要的，在這個時候，採用Scale Out的方式不一定適合。從整體上看，採用Scale out的方式是web2.0網站的主流，適應了網站資料不斷且不太好預計增長的主要需求，而Scale up這種方式更為適合業務資料具有較強關聯性且資料增長可預期的企業。           

原文出處不知道是哪了。