從企業IT架構體系上來看，特別是對於Web2.0網站來說，必須考慮的就是可擴展性：隨著使用人數的增多，能夠及時的擴展IT系統的能力。解決這個問題，通常有兩種解決方式：Scale up和Scale out，兩種擴容的方式分別從兩個維度來解決資料庫壓力。
Scale Out(橫向擴展)：從字面意思來看，Scale Out是使用靠增加處理器來提升運算能力和增加獨立伺服器來增加運算能力。就是指企業可以根據需求增加不同的伺服器和存儲應用，依靠多部伺服器、存儲協同運算，借負載平衡及容錯等功能來提高運算能力及可靠度。
Scale Up(縱向擴展)：指企業後端大型伺服器以增加處理器等運算資源進行升級以獲得對應用性能的要求，但是更大更強的伺服器同時也是更昂貴的，往往成本會大於部署大量相對便宜的伺服器來實現性能的提升，這當中的代表當屬IBM zSeries大型機。而且伺服器性能所能提高的程度也有一定的上限。
Scale Up劣勢漸現
目前來看，一般來講Scale out要比Scale up便宜。各大搜尋引擎普遍採用普通x86伺服器+Linux組成的scale out架構，其它主流web服務也大多採用這種架構，例如Yahoo、Taobao、新浪等，而一些ERP廠商入用友近兩年來也開始大量放棄價格昂貴的RISC架構。
從數據存儲的角度來看，曾經當我們需要構架一個不斷增長的大型數據中心時，Scale up存儲系統幾乎是最好的，唯一的的選擇。但是這也意味著當加入昂貴的存儲設備時，業務需要中斷且更難以管理。當然，Scale up存儲系統前端處理能力和後端的磁碟數量還可以不斷擴展，但總體來說，都是在一個固定的存儲系統架構上去升級擴展，當擴展到一定程度，就很難繼續擴展下去，尤其是前端控制器的數量。也因此導致了當後端磁碟不斷增多，而前端控制器無法擴展的情況下產生的性能瓶頸。
Scale Out將是未來的企業架構
現在，有了scale out存儲系統，一切似乎變得簡單多了。部署工作大大簡化，儲存架構達到上億級。另外Scale up架構每加一個結點進來，性能和容量同時增長，不會影響原有使用。用戶按需採購存儲，一旦容量不夠了，再購置一臺接到原有存儲上就可以了。
所以未來的企業架構應該使用向外擴展（Scale Out）來實現可擴展性，同時可以讓使用者得以保留通過增加伺服器以提升系統能力的後路。
從存儲來看，未來的企業需要的是一個能夠應對非結構化數據激增帶來的巨大挑戰的架構，橫向擴展存儲系統的基礎是NAS空間，可以添加若干並行工作的節點並作為一個節點進行管理，從而實現吞吐量和容量的獨立擴展。在單一系統映像下，這些系統可以擴展到多個PB級存儲，從而使它們成為理想的整合平臺。
同時，橫向擴展存儲池可對底層存儲進行虛擬化，創建可隨業務需求變化而動態調整的資源，帶寬、處理能力和存儲容量可以單獨調整和實時擴展。這種資源創建概念對當前持續不斷增加的企業基礎設施獲得更高的可用性和可靠性至關重要。橫向擴展存儲有利於最大程度地降低管理成本、數據中心空間、電源和冷卻需求。共享資源池可提供更高的利用率，極大地減少浪費。橫向擴展存儲的經濟價值體現在改進擴展能力、加速配置、提升性能和簡化管理、提高存儲利用率等方面。
橫向擴展存儲系統克服了物理機架和模塊的限制，可作為單一系統，通過增加控制器或是容量節點來實現性能和容量的獨立升級，提高IT投入的回報率。同時，線性擴展能力為業務的長期高性價比提供保障。解決了傳統單一系統，模塊化系統需要物理磁碟級別的管理、數據布局和性能調優的弊端。橫向擴展平臺不僅能夠提升性能而且還可以降低操作成本，使單一系統在單一全局域名下，簡單地擴展到若干PB容量範圍，成為管理猛增數據的理想存儲平臺。
2011年，由於企業IT用戶對其存儲系統的擴展性、靈活性和性能需求的增長，橫向擴展的存儲產品和方案不斷湧現。EMC、HDS和NetApp都已經推出擴展性更好的X86的解決方案，如：EMC的VMAX平臺(SAN)和Isilon 產品（多協議）；HDS的USP-V (SAN)、VSP introduction (SAN)和 HNAS (BlueArc-based NAS 系統)；以及NetApp的GX (now ONTAP 8 Cluster Mode) NAS系統；而國內廠商華賽也在去年推出自己的平面擴展產品HS的OceanSpace 5000。同時，IBM的DS8000系列所構成的系統也具有橫向擴展的特徵。
在開源軟體方面，也有許多橫向擴展存儲解決方案，比如Lustre, PVFS2, GlusterFS等集群文件系統，HDFS, KFS, MFS,FastDFS, TaobaoFS等分布式文件系統。
橫向擴展的瓶頸問題
現實的問題，如果要實現Scale out架構必然要面對分布式計算的問題，而目前基於分布式計算的解決方案已經有很多，比如Hadoop、Mapr等等，但問題也在於，基於分布式計算的性能優化一直是企業未能大量採用的瓶頸之一。
其次，Scale Out方案還需要對原先是用的軟體進行大量的重寫工作，以保證系統能在分布式伺服器上運行（Scale Up方案則對現有軟體幾乎沒有改動要求）。這一步往往是每個公司的開發人員的噩夢。
再者，Scale Out方案始終面臨著數據集中的問題，即拆分過的數據在伺服器邏輯體系中仍然是各自相對集中的而非無限隨意拆分。如果大量的邏輯放在傳統的資料庫伺服器一端，資料庫伺服器將會使得系統失去Scale out的能力和可能。因此，要保證Scale out的能力就必須保證資料庫只處理實質性的數據提交和不可避免的數據查詢，這也是以MongoDB、Redis等全新的NoSQL解決方案日漸受到青睞的原因。
對於分布式計算的技術問題，國外有一些開源的項目，我們可以借鑑，在一定程度上可以去努力解決。與此同時，我們還需要考慮到我們自身網站的數據的特點。像聯機遊戲、IM、BSP這些數據，通常每個用戶都可以抽象成一個數據對象，可以獨立存儲在任何一個地方，數據之間關聯度不大，這種情況比較適合採用 Scale Out的方式。但對於另外一些數據，比如電子商務網站的買賣信息，它們之間的關聯度大，這時候往往查詢需要耗費很多的資源；還有一些事物型的應用，保證數據的完整性是更為重要的，在這個時候，採用Scale Out的方式不一定適合。從整體上看，採用Scale out的方式是web2.0網站的主流，適應了網站數據不斷且不太好預計增長的主要需求，而Scale up這種方式更為適合業務數據具有較強關聯性且數據增長可預期的企業。