2011年12月6日 星期二

網站性能優化 - 資料庫及伺服器架構篇


1Web Server DB Server 分離
小型網站或 B/S 專案,因同時線上人數不多,尚可讓同一台物理主機,既做 Web Server,又做 DB Server。但此二者皆會佔用大量的 CPU、記憶體、磁片 I/O,最好讓二者分別用不同的伺服器主機來提供服務,以分散壓力、提高負載承受能力。此外,二者若在同一網段,應儘量用內網 Private IP 進行訪問,而不要用 Public IP 或主機名稱稱。
基本上跑 Web 上的應用程式,不管用什麼軟、硬體,同時處理多個使用者的 request,通常都比較消耗 CPU;但對資料庫而言,CPU 就不見得會大量消耗,而是記憶體和磁片 I/O 用得比 Web Server 多。因此一般建議 Web Server 用普通的 PC 即可,但要用好一點的 CPU;而 DB Server 就不能草率,應儘量買高級的伺服器,並要有 RAID 5 6 的磁碟陣列 (硬體的 RAID,性能遠比作業系統或軟體做的 RAID 要好),並有 4 GB 以上的記憶體。當然如果作業系統、資料庫都用 64 位版本的最好,例如升級到 64 位的 SQL Server 64 位元的 Windows Server,這樣記憶體都可配置到 64 GB;不過要記得,太舊的 PC,一些周邊硬體的 driver 可能不支援 64 位元的作業系統和軟體。
如果線上人數持續增加,則可增加多台 Web Server DB Server,用「伺服器集群 (cluster)」、「負載均衡 (Load balancing) 集群」、「高可用性集群 High-availability (HA)」、資料庫集群,以實現更大規模的分散式佈署。
Deployment Plan(部署規劃):
http://msdn.microsoft.com/zh-cn/library/ms978676.aspx
Three-Tiered Distribution(三級分佈)(硬體、不同主機的物理級分層)
http://msdn.microsoft.com/zh-cn/library/ms978694.aspx
Three-Layered Services Application(三層服務應用程式)(軟體、代碼上的分層)
http://msdn.microsoft.com/zh-cn/library/ms978689.aspx
Tiered Distribution(分級分佈):
http://msdn.microsoft.com/en-gb/library/ms978701(zh-cn).aspx
-----------------------------------------------------
2、負載均衡 (Load Balance)
負載均衡技術發展了多年,有很多專業的服務提供者和產品可選擇,基本上又可分為「軟體」和「硬體」的解決方案:
(1) 硬體:
硬體的解決方案稱作 Layer 4 Switch ( 4 層交換),可將業務流分配到合適的 AP Server 進行處理,知名產品如 AlteonF5 等。這些硬體產品雖比軟體的解決方案要貴得多,但是物有所值,通常能提供遠比軟體優秀的性能,和方便、易於管理的 UI 介面,供管理人員快速配置。據說 Yahoo 中國當初接近 2000 台伺服器時,只用三台 Alteon 就搞定了 [1]
(2) 軟體:
Apache 這一款眾所皆知的 HTTP Server,其雙向 Proxy / Reverse Proxy 功能,亦可達成 HTTP 負載均衡功能,但其效率算不上特別好。而另一款 HAProxy 就是純粹用來處理負載均衡的,且具有簡單的緩存功能。
以作業系統內置的負載均衡功能來講,Unix Sun Solaris 有支援,Linux 上則有常用的 LVS (Linux Virtual Server),而微軟的 Windows Server 2003 / 2008 則有 NLB (Network LoadBalance)
LVS 是利用 ipvsadm 這一個以 IP 為主的負載均衡程式,來達到讓所有 TCP/IP 的通訊協定都可以進行負載均衡。由於它是 Linux Kernel 所支持,因此效率相當好,佔用的 CPU  資源相當低,但缺點是 ipvsadm 無法針對 Layer 4 以上的網路 packet 資料進行分析。
至於 Windows Server NLB,其原理是不論有多少台伺服器,都全部共用一個「集群的 IP」,如下圖 1 Active Load balancer,和下圖 2 Virtual Server 1 (Web Server),以及 Virtual DB Server,依照負載均衡的類型來做分配 (Active/ActiveActive/Standby...),而用戶在外面只會看到單一個 IP,至於背後有多少台伺服器,使用者並不需要知道 (如同 Cluster 集群和雲計算的概念)

1 分散式用戶 vs 伺服器農場 (Web Server farm)


2 紅色箭頭為 Failover 架構 (HA),其功能與 Load Balance 不同
上圖 2 中,有四台 Real Server (Web Server),以及三台 Real DB Server,形成 Web DB 的伺服器集群 (Cluster)。我們看到最上方的 Virtual Server 1 本身不具備任何的資料服務 (如:.NET 代碼、圖片...),只有一個功能,就是將用戶的連線 request 請求,重新導向下方的四台 Real Server。這種利用重新導向 (director) 的方式,將服務負載分佈給 Real Server 的方式,就稱作 Load Balance
現在似乎還沒有一種做法,能自動計算主機的「負載」情形,例如計算 CPU 已使用多少百分比,以決定要把 request 丟向哪一台 Real Server;現在一般都還是按照輪替 (Round-robin) 的方式,或加上一些權重的設置而已。
若我們在 Server 上設置 Load Balance,且要執行 ASP.NET 程式,就要注意一個問題,就是 Session 的存儲位置是在哪一台 Web Server 的記憶體上,以避免發生有用戶表單填寫得比較久,等到他提交時,已經被 Windows Server NLB 將工作階段切換到另一台 Web Server 主機上了。此時就可考慮將 Session State,改存儲在 SQL Server 裡。
至於用軟體做的 Load Balance 其性能如何呢?基本上用軟體做的,性能一定不會是 1 + 1 = 2,但通常能提高 Availability,亦即常聽到的 HA (高可用性集群 High-availability),即 Failover 方式,如上圖 2 的最上方,紅色箭頭左側的 Virtual Server 2,是能夠偵測 Virtual Server 1 宕機或無法提供服務時,自動將自己的 IP address 取代 Virtual Server1。因此 HA 是指提供「不會中斷的服務」,而本帖討論的 Load Balance 是指提供「能承受高度負載的服務」,兩者指的不是同一件事。MIS 人員應視公司的硬體資源、成本和預算,考量是否兩者都要做。
Server Clustering(伺服器叢集):
http://msdn.microsoft.com/en-gb/library/ms998414(zh-cn).aspx
Installing Network Load Balancing (NLB) on Windows Server 2008
http://blogs.msdn.com/clustering/archive/2008/01/08/7024154.aspx
Linux load balancing support & consulting
http://www.netdigix.com/linux-loadbalancing.php
-----------------------------------------------------

3、展示和功能的分層
大型網站中,常會為了將來的可擴展性、原始程式碼維護方便,而將前臺的展示 (HTMLScript),和後臺的商業邏輯、資料庫訪問 (.NET/C#SQL),切成多層。
根據 Martin Fowler P of EAA 裡的說法:Layer 是指「邏輯」上的分層 (logical separation)Tier 是指「物理」上的分層 (physical separation)。若我們的 ASP.NET 月臺,是用「虛擬」的分層 (N-Layer),來切開 UI - BLL - DAL,通常不會有性能上的問題;但若是用「物理」的分層 (N-Tier),亦即如上圖 2 和下圖 3,可能每一台 AP Server 都負責不同的商業邏輯 (銷售、庫存、物流、製造、會計、...),各自的原始程式碼都存放在不同的物理主機上,且可各自獨立運作,此時就要考慮到每一台 AP Server 在彼此協調合作,以及調用 Web Service (XML 的性能不佳)、執行分散式事務上的性能問題。

网站性能优化 - 数据库及服务器架构篇

作者: WizardWu  来源: 博客园  发布时间: 2009-09-22 10:06  阅读: 2189 次  原文链接   全屏阅读  [收藏]  
1、Web Server 与 DB Server 分离
小型网站或 B/S 项目,因同时在线人数不多,尚可让同一台物理主机,既做 Web Server,又做 DB Server。但此二者皆会占用大量的 CPU、内存、磁盘 I/O,最好让二者分别用不同的服务器主机来提供服务,以分散压力、提高负载承受能力。此外,二者若在同一网段,应尽量用内网 Private IP 进行访问,而不要用 Public IP 或主机名称。
基本上跑 Web 上的应用程序,不管用什么软、硬件,同时处理多个用户的 request,通常都比较消耗 CPU;但对数据库而言,CPU 就不见得会大量消耗,而是内存和磁盘 I/O 用得比 Web Server 多。因此一般建议 Web Server 用普通的 PC 即可,但要用好一点的 CPU;而 DB Server 就不能草率,应尽量买高级的服务器,并要有 RAID 5 或 6 的磁盘阵列 (硬件的 RAID,性能远比操作系统或软件做的 RAID 要好),并有 4 GB 以上的内存。当然如果操作系统、数据库都用 64 位版本的最好,例如升级到 64 位的 SQL Server 和 64 位的 Windows Server,这样内存都可配置到 64 GB;不过要记得,太旧的 PC,一些周边硬件的 driver 可能不支持 64 位的操作系统和软件。
如果在线人数持续增加,则可增加多台 Web Server 和 DB Server,用「服务器集群 (cluster)」、「负载均衡 (Load balancing) 集群」、「高可用性集群 High-availability (HA)」、数据库集群,以实现更大规模的分布式布署。
Deployment Plan(部署规划):
http://msdn.microsoft.com/zh-cn/library/ms978676.aspx
Three-Tiered Distribution(三级分布)(硬件、不同主机的物理级分层):
http://msdn.microsoft.com/zh-cn/library/ms978694.aspx
Three-Layered Services Application(三层服务应用程序)(软件、代码上的分层):
http://msdn.microsoft.com/zh-cn/library/ms978689.aspx
Tiered Distribution(分级分布):
http://msdn.microsoft.com/en-gb/library/ms978701(zh-cn).aspx
Deployment Patterns:
http://msdn.microsoft.com/zh-cn/library/ms998478.aspx
http://msdn.microsoft.com/en-us/library/ms998478.aspx
-----------------------------------------------------
2、负载均衡 (Load Balance)
负载均衡技术发展了多年,有很多专业的服务提供商和产品可选择,基本上又可分为「软件」和「硬件」的解决方案:
(1) 硬件:
硬件的解决方案称作 Layer 4 Switch (第 4 层交换),可将业务流分配到合适的 AP Server 进行处理,知名产品如 Alteon、F5 等。这些硬件产品虽比软件的解决方案要贵得多,但是物有所值,通常能提供远比软件优秀的性能,和方便、易于管理的 UI 界面,供管理人员快速配置。据说 Yahoo 中国当初接近 2000 台服务器时,只用三台 Alteon 就搞定了 [1]。
(2) 软件:Apache 这一款众所皆知的 HTTP Server,其双向 Proxy / Reverse Proxy 功能,亦可达成 HTTP 负载均衡功能,但其效率算不上特别好。而另一款 HAProxy 就是纯粹用来处理负载均衡的,且具有简单的缓存功能。
以操作系统内置的负载均衡功能来讲,Unix 如 Sun 的 Solaris 有支持,Linux 上则有常用的 LVS (Linux Virtual Server),而微软的 Windows Server 2003 / 2008 则有 NLB (Network LoadBalance)。
LVS 是利用 ipvsadm 这一个以 IP 为主的负载均衡程序,来达到让所有 TCP/IP 的通讯协议都可以进行负载均衡。由于它是 Linux Kernel 所支持,因此效率相当好,占用的 CPU  资源相当低,但缺点是 ipvsadm 无法针对 Layer 4 以上的网络 packet 数据进行分析。
至于 Windows Server 的 NLB,其原理是不论有多少台服务器,都全部共用一个「集群的 IP」,如下图 1 的 Active Load balancer,和下图 2 的 Virtual Server 1 (Web Server),以及 Virtual DB Server,依照负载均衡的类型来做分配 (Active/Active、Active/Standby、...),而用户在外面只会看到单一个 IP,至于背后有多少台服务器,用户并不需要知道 (如同 Cluster 集群和云计算的概念)。

图 1 分布式用户 vs 服务器农场 (Web Server farm)


图 2 红色箭头为 Failover 架构 (HA),其功能与 Load Balance 不同
上图 2 中,有四台 Real Server (Web Server),以及三台 Real DB Server,形成 Web 及 DB 的服务器集群 (Cluster)。我们看到最上方的 Virtual Server 1 本身不具备任何的数据服务 (如:.NET 代码、图片...等),只有一个功能,就是将用户的连线 request 请求,重新导向下方的四台 Real Server。这种利用重新导向 (director) 的方式,将服务负载分布给 Real Server 的方式,就称作 Load Balance。
现在似乎还没有一种做法,能自动计算主机的「负载」情形,例如计算 CPU 已使用多少百分比,以决定要把 request 丢向哪一台 Real Server;现在一般都还是按照轮替 (Round-robin) 的方式,或加上一些权重的设置而已。
若我们在 Server 上设置 Load Balance,且要执行 ASP.NET 程序,就要注意一个问题,就是 Session 的存储位置是在哪一台 Web Server 的内存上,以避免发生有用户表单填写得比较久,等到他提交时,已经被 Windows Server 的 NLB 将工作阶段切换到另一台 Web Server 主机上了。此时就可考虑将 Session State,改存储在 SQL Server 里。
至于用软件做的 Load Balance 其性能如何呢?基本上用软件做的,性能一定不会是 1 + 1 = 2,但通常能提高 Availability,亦即常听到的 HA (高可用性集群 High-availability),即 Failover 方式,如上图 2 的最上方,红色箭头左侧的 Virtual Server 2,是能够侦测 Virtual Server 1 宕机或无法提供服务时,自动将自己的 IP address 取代 Virtual Server1。因此 HA 是指提供「不会中断的服务」,而本帖讨论的 Load Balance 是指提供「能承受高度负载的服务」,两者指的不是同一件事。MIS 人员应视公司的硬件资源、成本和预算,考量是否两者都要做。

Load-Balanced Cluster(负载平衡群集):
http://msdn.microsoft.com/zh-cn/library/ms978730.aspx
http://msdn.microsoft.com/en-us/library/ms978730.aspx
Server Clustering(服务器群集):
http://msdn.microsoft.com/en-gb/library/ms998414(zh-cn).aspx
Installing Network Load Balancing (NLB) on Windows Server 2008:
http://blogs.msdn.com/clustering/archive/2008/01/08/7024154.aspx
Linux load balancing support & consulting:
http://www.netdigix.com/linux-loadbalancing.php
Load Balancing (WCF, 与本文无直接关系):
http://msdn.microsoft.com/zh-cn/library/ms730128.aspx
http://msdn.microsoft.com/en-us/library/ms730128.aspx
-----------------------------------------------------

3、展示和功能的分层
大型网站中,常会为了将来的可扩展性、源代码维护方便,而将前台的展示 (HTML、Script),和后台的商业逻辑、数据库访问 (.NET/C#、SQL),切成多层。
根据 Martin FowlerP of EAA 里的說法:Layer 是指「逻辑」上的分层 (logical separation),Tier 是指「物理」上的分层 (physical separation)。若我们的 ASP.NET 站台,是用「虚拟」的分层 (N-Layer),来切开 UI - BLL - DAL,通常不会有性能上的问题;但若是用「物理」的分层 (N-Tier),亦即如上图 2 和下图 3,可能每一台 AP Server 都负责不同的商业逻辑 (销售、库存、物流、制造、会计、...),各自的源代码都存放在不同的物理主机上,且可各自独立运作,此时就要考虑到每一台 AP Server 在彼此协调合作,以及调用 Web Service (XML 的性能不佳)、执行分布式事务上的性能问题。
3 「物理」上的分層,各種商業邏輯可能存在多台物理主機上
談到「物理」分層上的分散式事務 (Distributed Transaction),微軟的 Enterprise ServicesCOM+WCFWF 用到作業系統上的 MS DTC 來協調事務,由於 MS DTC 和這些應用程式各自處於不同的 Process,在溝通上會遇到序列化、反序列化的動作,還要整合事務中所有的 AppDomain 和不同主機上的資源,無可避免地一定會拖累性能。
-----------------------------------------------------

4、數據大表拆分
對比較大的資料表,或歷史資料比較多的資料表,可根據一定的邏輯進行拆分。若每天的資料量非常大,則可採用按日存放,再用一個「匯總表」來記錄當天的一個匯總值;也可先將比較大的表拆分成多個表,再通過「索引表」進行關聯處理,以避免查詢大表造成的性能問題 [1]
另也可用「表分區」的方式,將資料存儲在不同的檔上,然後再部署到獨立的物理伺服器,以增加 I/O 吞吐,改善讀寫的性能。
此外,在本文的系列作「30 分鐘快快樂樂學 SQL Performance Tuning」 曾提過,若一個資料表的欄位過多 (與剛才提的記錄量過多不同),應垂直切割成兩個以上的資料表,並可用同名的 Primary Key 一對多連結起來,如:Northwind OrdersOrder Details 資料表。以避免在訪問資料時,以「集簇引 (clustered index)」掃描時會載入過多的資料,或修改資料時造成互相鎖定或鎖定過久。
-----------------------------------------------------

5、圖片伺服器分離
對於 Web Server 來說,使用者對圖片的請求是最消耗系統資源的,因此可視網站的規模和專案的特性,部署獨立的圖片伺服器,甚至多台圖片伺服器。
-----------------------------------------------------

6、讀寫分離
同時對資料庫進行「讀」和「寫」的操作,是非常沒效率的一種訪問方式。比較好的做法,是根據讀、寫的壓力和需求,分別建立兩台結構完全相同的資料庫伺服器,將負責「寫」的那台伺服器的資料,定時複製給負責「讀」的伺服器。 
-----------------------------------------------------

7、擴容性應對突增流量
大型網站在設計架構的時候,必須考慮到以後的容量擴充 [1]。對於活動類的網站來說,不定時的突增流量是巨大的。在網站主存儲伺服器上,採用設定檔形式,指定每一個存儲盤櫃上存儲的資料檔案的 ID 範圍。當前台伺服器需要讀取一個資料的時候,首先通過詢問主存儲伺服器上的介面,獲得該資料所在的盤櫃及目錄位址,然後再去該盤櫃讀取實際的資料檔案。如 果需要增加盤櫃,則只要修改設定檔即可,前景程式完全不受影響。
-----------------------------------------------------

8、緩存
緩存 (Cache) 是資料庫或物件在記憶體中的臨時容器,使用緩存可大幅減少資料庫的讀取,改由記憶體來提供資料。例如我們可以在 Web ServerDB Server 之間增加一層「資料緩存層」,在記憶體中建立被頻繁請求物件的副本,如此一來,不訪問資料庫也可供給資料。例如,有 100 個使用者請求同一份資料,以前需要查詢資料庫 100 次,現在則只需要 1 次,其餘都可從緩存資料中獲得,而且讀取速度、網頁反應速度會大幅提升。
提供緩存的產品有很多種,還可分為用硬體或軟體所做的緩存,如:ASP.NET 內置的緩存功能、協力廠商廠商的緩存套件、Hibernate NHibernate 裡也有 Session SessionFactory 的緩存機制、Oracle cache group 技術,還有我先前在「用 IIS 7、ARR 與 Velocity 建設高性能的大型網站」這篇文章介紹的,微軟官方新一代的分散式緩存技術 Velocity,另外像 Proxy Server (代理伺服器) 也可以作為網頁的緩存:
用戶端 <---->  代理伺服器  <---->  目的伺服器

.NET 的類庫中,有提供 CacheDependency AggregateCacheDependency 這兩個類,可用來將 ASP.NET 中緩存的對象 (如:DataSet),和一或多個物理檔 (如:XML ) 或資料庫中的表,去建立一種關聯。當其中任一個 XML 檔被修改或移除時,與其關聯的 DataSet 也會一併從記憶體裡移除;當然,也可透過您程式中設定的時間自動移除。
ASP.NET 2.0 以後的緩存,最大的改變在於 CacheDependency 類已經被微軟重新改寫過,我們也可透過自訂類去繼承它後再改寫,以達成以下功能:
Active Directory 中的請求,讓緩存失效 (緩存被自動移除)
MSMQ MQSeries 中的請求,讓緩存失效
Web Service 中的請求,讓緩存失效
創建用於 Oracle CacheDependency
其他

此外,SQL Server 中還有一種 SqlCacheDependency (緩存相依性),可監聽資料表中的資料是否曾經改變,亦即避免用戶在緩存期間查到的資料是舊的,達到如果資料不變化,使用者就一直從緩存中取得資料;一旦數 據有變化,就自動更新緩存中的資料。啟用 SqlCacheDependency 的方式,只要透過 aspnet_regsql.exe 這個工具,搭配參數輸入命令,就會在 SQL Server 中產生一個新的 AspNet_SqlCacheTablesForChangeNotification 表,如下圖 4 所示,這張表的的每一條記錄,都代表您要監聽的其中一個表;最右側的 changeId 欄位,其值為供系統判斷,使用者對 ASP.NET 中的請求,應由記憶體中的緩存來提供,抑或要至資料庫重新做查詢。

4 啟用 SqlCacheDependency 後,自動添加用來監聽的表

另外再談到,我在「網站性能越來越差怎麼辦?」這篇文章,也有提過下面的內容:
(4) 用程式或軟體做緩存
用程式做緩存,如 ASP.NET 1.x 時代,就已內建的 Cache (緩存) 機制;或用一些協力廠商的輔助軟體、Framework

(5)
用硬體做快取或緩衝、砸錢加裝 AP Server
他還在原本的網頁伺服器,與資料庫伺服器的架構中,加入一組應用程式伺服器,作為網頁伺服器 cache 資料的來源。
改版之後的新網站,搜尋速度提升許多,先前每日的統計資料中,處理速度超過 3 秒的資料超過 50 萬筆;而改版後,每星期超過 3 秒的查詢不到 10 筆。
(6) 用硬體做緩存 (cache)
全盛時期,來自美國 blog 的流量每天達 80 萬次。這個數位其實不高,對程式高手來說是小菜一碟,但筆者是半吊子工程師,知識有限也因此可能程式寫得不好,頻頻被主機供應商發信警告,要求改善網站系 統性能。最後,我決定開發 cache systemcache system 緩存系統上線後,將資料庫讀寫,從每天 80 萬次降低到每天 16 萬次。
回復:
Peter.z.lu      
中介軟體可以有很多選擇:
Ncache, Coherence, Velocity, MemCache...

另外,還有像是 MemcachedCacheman 這種分散式緩存的系統。前者可基於 Linux Win32 平臺使用,通過在記憶體裡維護一個巨大的 hash 表,可存儲圖像、視頻、檔及資料庫檢索的結果,並且支持多伺服器,可解決 ASP.NET 內置的緩存機制僅適用於單獨的伺服器;後者據說是微軟旗下 Popfly 專案組成員 Sriram Krishnan 的作品,將來也有可能成為微軟的正式產品。
-----------------------------------------------------

9、分散式系統資料結構 - MySpace 為例
在網路上流傳一篇很火紅的文章「從 MySpace 資料庫看分散式系統資料結構變遷」,內容提到 MySpace 這個大型的社區網站,使用微軟平臺的 Windows ServerSQL ServerASP.NET 技術,如今每個月的用戶訪問量高達 500 億,且已有 2 億個以上的用戶註冊。以下僅節錄該文的重點:
  • 第一代架構 - 添置更多的 Web 伺服器
    MySpace 50 萬個註冊用戶的時候,網站只用了兩台 Dell CPU4 GB 記憶體的 Web Server (分散使用者的請求)、一台 DB Server (所有資料都存儲在這)
  • 第二代架構 - 增加資料庫伺服器
    運行在三台資料庫伺服器上,一台用於更新資料 (由它複製到其他兩個)、另兩台用於讀取資料,因為看網頁的人多,而需要寫入的人少。等到用戶數和訪問量增加了,就再加裝硬碟。
    後來資料庫伺服器的 I/O 成了瓶頸,就按照垂直分割模式設計,把網站裡的不同功能,如:登錄、使用者資料和博客,搬移到不同的資料庫伺服器中,以分擔訪問壓力;若要增加新功能,就再投入新的資料庫伺服器。
    當 註冊用戶達到 200 萬後,還從存放裝置與資料庫伺服器直接交互的方式,切換到 SAN (存儲區域網路),一種高頻寬、專門設計的網路系統,可將大量磁片存放裝置連接在一起。MySpace 讓資料庫連接到 SAN。但是當用戶增加到 300 萬人後,垂直分割策略也變得難以維持下去,後來架構師後來將主機升級成 34 CPU 的昂貴伺服器,卻也無法負荷。
  • 第三代架構 - 轉到分散式運算架構
    架構師將 MySpace 移到分散式運算架構,它在物理上分佈的眾多伺服器,整體必須邏輯上等同于單台機器。拿資料庫來說,就不能再像過去那樣將應用拆分,再以不同資料庫分別支 持,而必須將整個網站看作一個應用。這次,不再按網站功能和應用分割資料庫,MySpace 開始將它的用戶按每 100 萬一組分割,然後將各組的全部資料分別存入獨立的 SQL Server 實例。後來 MySpace 的每台資料庫伺服器實際運行兩個 SQL Server 實例,也就是說每台伺服器會服務大約 200 萬用戶。
  • 第四代架構 - 增加資料緩存層
    當用戶達到 900-1000 萬時,MySpace再次遭遇存儲瓶頸問題,後來引用了新的 SAN 產品,但網站目前的要求,已經超越 SAN I/O 磁片存儲系統、及其讀寫資料的極限速度。
    當 用戶達到 1700 萬時,增加了一個資料緩存層,其位於 Web 伺服器和資料庫伺服器之間,其唯一職能是在記憶體中建立被頻繁請求資料物件的副本。以前每一位元使用者查詢一個資訊,就請求一次資料庫;現在當任一個用戶請求數 據庫後,緩存層就會保留一個副本,當其他用戶再訪問時就不需要再請求資料庫了,如此一來,不訪問資料庫也可以供給資料。
  • 第五代架構 - 轉到支援 64 位元處理器的作業系統和資料庫軟體
    當 用戶數達到 2600 萬時,轉到了還處於 Beta 版、但支持 64 位處理器的 SQL Server 2005。在升級到 64 位的 SQL Server 2005 Windows Server 2003 後,MySpace 每台伺服器配備了 32 GB 記憶體,後來又提升到了 64 GB

沒有留言: