資料庫如何處理大資料訪問

當系統要滿足每秒數萬次的讀寫請求的需求時，我們可以用分散式計算、編寫優良的程式程式碼、對海量資料進行分割槽操作、建立廣泛的索引、建立快取機制、加大虛擬記憶體、分批處理、使用資料倉儲和多維資料庫儲存、使用負載均衡技術、將資料庫的讀寫分離等等來解決資料庫大資料訪問的問題。

隨著網際網路應用的廣泛普及，海量資料的儲存和訪問成為了系統設計的瓶頸問題。對於一個大型的網際網路應用，每天百萬級甚至上億的PV無疑對資料庫造成了相當高的負載。對於系統的穩定性和擴充套件性造成了極大的問題。

 

一、那麼資料庫如何處理海量資料呢？

 

1、編寫優良的程式程式碼

處理資料離不開優秀的程式程式碼，尤其在進行復雜資料處理時，必須使用程式。好的程式程式碼對資料的處理至關重要，這不僅僅是資料處理準確度的問題，更是資料處理效率的問題。良好的程式程式碼應該包含好的演算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。
 

2、對海量資料進行分割槽操作

對海量資料進行分割槽操作十分必要，例如針對按年份存取的資料，我們可以按年進行分割槽，不同的資料庫有不同的分割槽方式，不過處理機制大體相同。例如SQL Server的資料庫分割槽是將不同的資料存於不同的檔案組下，而不同的檔案組存於不同的磁碟分割槽下，這樣將資料分散開，減小磁碟I/O，減小了系統負荷，而且還可以將日誌，索引等放於不同的分割槽下。
 

3、建立廣泛的索引

對海量的資料處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等欄位，都要建立相應索引，一般還可以建立複合索引，對 經常插入的表則建立索引時要小心，筆者在處理資料時，曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完畢，建立索引，並實施聚合操作，聚合 完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。

4、加大虛擬記憶體
 

如果系統資源有限，記憶體提示不足，則可以靠增加虛擬記憶體來解決。筆者在實際專案中曾經遇到針對18億條的資料進行處理，記憶體為1GB，1個P4 2.4G的CPU，對這麼大的資料量進行聚合操作是有問題的，提示記憶體不足，那麼採用了加大虛擬記憶體的方法來解決，在6塊磁碟分割槽上分別建立了6個 4096M的磁碟分割槽，用於虛擬記憶體，這樣虛擬的記憶體則增加為 4096*6 + 1024 = 25600 M，解決了資料處理中的記憶體不足問題。
 

5、分批處理
 

海量資料處理難因為資料量大，那麼解決海量資料處理難的問題其中一個技巧是減少資料量。可以對海量資料分批處理，然後處理後的資料再進行合併操作，這樣逐 個擊破，有利於小資料量的處理，不至於面對大資料量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分資料，還需要另想辦法。不過一般的資料按 天、按月、按年等儲存的，都可以採用先分後合的方法，對資料進行分開處理。
 

6、使用資料倉儲和多維資料庫儲存
 

資料量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鐘，因此處理海量資料的利器是OLAP多維分析，即建立資料倉儲，建立多維資料集，基於多維資料集進行報表展現和資料探勘等。

7、使用取樣資料，進行資料探勘
 

基於海量資料的資料探勘正在逐步興起，面對著超海量的資料，一般的挖掘軟體或演算法往往採用資料抽樣的方式進行處理，這樣的誤差不會很高，大大提高了處理效率和處理的成功率。一般取樣時要注意資料的完整性和，防止過大的偏差。筆者曾經對1億2千萬行的表資料進行取樣，抽取出400萬行，經測試軟體測試處理的誤差為千分之五，客戶可以接受。

還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數值型的聚合比對字元型的聚合快得多。類似的情況需要針對不同的需求進行處理。

海量資料是發展趨勢，對資料分析和挖掘也越來越重要，從海量資料中提取有用資訊重要而緊迫，這便要求處理要準確，精度要高，而且處理時間要短，得到有價值資訊要快，所以，對海量資料的研究很有前途，也很值得進行廣泛深入的研究。
 

 

二、下面注意講解下負載均衡技術、資料庫的讀寫分離、資料庫拆分(分散式)

 

1、負載均衡技術

負載均衡叢集是由一組相互獨立的計算機系統構成，通過常規網路或專用網路進行連線，由路由器銜接在一起，各節點相互協作、共同負載、均衡壓力，對客戶端來說，整個群集可以視為一臺具有超高效能的獨立伺服器。

實現原理

實現資料庫的負載均衡技術，首先要有一個可以控制連線資料庫的控制端。在這裡，它截斷了資料庫和程式的直接連線，由所有的程式來訪問這個中間層，然後再由中間層來訪問資料庫。這樣，我們就可以具體控制訪問某個資料庫了，然後還可以根據資料庫的當前負載採取有效的均衡策略，來調整每次連線到哪個資料庫。

實現多據庫資料同步

對於負載均衡，最重要的就是所有伺服器的資料都是實時同步的。這是一個叢集所必需的，因為，如果數不據實時、不同步，那麼使用者從一臺伺服器讀出的資料，就有別於從另一臺伺服器讀出的資料，這是不能允許的。所以必須實現資料庫的資料同步。這樣，在查詢的時候就可以有多個資源，實現均衡。比較常用的方法是Moebius for SQL Server叢集，Moebius for SQL Server叢集採用將核心程式駐留在每個機器的資料庫中的辦法，這個核心程式稱為Moebius for SQL Server 中介軟體，主要作用是監測資料庫內資料的變化並將變化的資料同步到其他資料庫中。資料同步完成後客戶端才會得到響應，同步過程是併發完成的，所以同步到多個資料庫和同步到一個資料庫的時間基本相等；另外同步的過程是在事務的環境下完成的，保證了多份資料在任何時刻資料的一致性。正因為Moebius 中介軟體宿主在資料庫中的創新，讓中介軟體不但能知道資料的變化，而且知道引起資料變化的SQL語句，根據SQL語句的型別智慧的採取不同的資料同步的策略以保證資料同步成本的最小化。

資料條數很少，資料內容也不大，則直接同步資料

資料條數很少，但是裡面包含大資料型別，比如文字，二進位制資料等，則先對資料進行壓縮然後再同步，從而減少網路頻寬的佔用和傳輸所用的時間。

資料條數很多，此時中介軟體會拿到造成資料變化的SQL語句， 然後對SQL語句進行解析，分析其執行計劃和執行成本，並選擇是同步資料還是同步SQL語句到其他的資料庫中。此種情況應用在對錶結構進行調整或者批量更改資料的時候非常有用。

優缺點

(1) 擴充套件性強：當系統要更高資料庫處理速度時，只要簡單地增加資料庫伺服器就 可以得到擴充套件。

(2) 可維護性：當某節點發生故障時，系統會自動檢測故障並轉移故障節點的應用，保證資料庫的持續工作。

(3) 安全性：因為資料會同步的多臺伺服器上，可以實現資料集的冗餘，通過多份資料來保證安全性。另外它成功地將資料庫放到了內網之中，更好地保護了資料庫的安全性。

(4) 易用性：對應用來說完全透明，叢集暴露出來的就是一個IP

 

2、資料庫的讀寫分離

 

實現原理

讀寫分離簡單的說是把對資料庫讀和寫的操作分開對應不同的資料庫伺服器，這樣能有效地減輕資料庫壓力，也能減輕io壓力。主資料庫提供寫操作，從資料庫提供讀操作，其實在很多系統中，主要是讀的操作。當主資料庫進行寫操作時，資料要同步到從的資料庫，這樣才能有效保證資料庫完整性。

　　(ebay的讀寫比率是260:1,ebay的讀寫分離)

　　(微軟資料庫分發)

　　

實現方法

在MS Sql server中可以使用釋出定義的方式實現資料庫複製，實現讀寫分離，複製是將一組資料從一個資料來源拷貝到多個資料來源的技術，是將一份資料釋出到多個儲存站點上的有效方式。使用複製技術，使用者可以將一份資料釋出到多臺伺服器上。複製技術可以確保分佈在不同地點的資料自動同步更新，從而保證資料的一致性。SQL SERVER複製技術型別有三種，分別是：快照複製、事務複製、合併複製。SQL SERVER 主要採用出版物、訂閱的方式來處理複製。源資料所在的伺服器是出版伺服器，負責發表資料。出版伺服器把要發表的資料的所有改變情況的拷貝複製到分發伺服器，分發伺服器包含有一個分發資料庫，可接收資料的所有改變，並儲存這些改變，再把這些改變分發給訂閱伺服器。

優缺點

(1)資料的實時性差:資料不是實時同步到自讀伺服器上的，當資料寫入主伺服器後，要在下次同步後才能查詢到。

(2)資料量大時同步效率差：單表資料量過大時插入和更新因索引,磁碟IO等問題，效能會變的很差。

(3)同時連線多個（至少兩個）資料庫：至少要連線到兩個資料資料庫，實際的讀寫操作是在程式程式碼中完成的，容易引起混亂

(4)讀具有高效能高可靠性和可伸縮:只讀伺服器，因為沒有寫操作，會大大減輕磁碟IO等效能問題，大大提高效率；只讀伺服器可以採用負載均衡，主資料庫釋出到多個只讀伺服器上實現讀操作的可伸縮性。

 

3、資料庫拆分(分散式)

通過某種特定的條件，將存放在同一個資料庫中的資料分散存放到多個資料庫上，實現分佈儲存，通過路由規則路由訪問特定的資料庫，這樣一來每次訪問面對的就不是單臺伺服器了，而是N臺伺服器，這樣就可以降低單臺機器的負載壓力。

垂直(縱向)拆分：是指按功能模組拆分，比如分為訂單庫、商品庫、使用者庫...這種方式多個資料庫之間的表結構不同。

水平(橫向)拆分：將同一個表的資料進行分塊儲存到不同的資料庫中，這些資料庫中的表結構完全相同。

　　（縱向拆分）

　　（橫向拆分）

實現原理

使用垂直拆分，主要要看應用型別是否合適這種拆分方式，如系統可以分為，訂單系統，商品管理系統，使用者管理系統業務系統比較明的，垂直拆分能很好的起到分散資料庫壓力的作用。業務模組不明晰，耦合（表關聯）度比較高的系統不適合使用這種拆分方式。但是垂直拆分方式並不能徹底解決所有壓力問題，例如 有一個5000w的訂單表，操作起來訂單庫的壓力仍然很大，如我們需要在這個表中增加（insert）一條新的資料，insert完畢後，資料庫會針對這張表重新建立索引，5000w行資料建立索引的系統開銷還是不容忽視的，反過來，假如我們將這個表分成100個table呢，從table_001一直到table_100，5000w行資料平均下來，每個子表裡邊就只有50萬行資料，這時候我們向一張只有50w行資料的table中insert資料後建立索引的時間就會呈數量級的下降，極大了提高了DB的執行時效率，提高了DB的併發量，這種拆分就是橫向拆分

 

實現方法

垂直拆分，拆分方式實現起來比較簡單，根據表名訪問不同的資料庫就可以了。橫向拆分的規則很多，這裡總結前人的幾點，

(1)順序拆分

如可以按訂單的日前按年份才分，2003年的放在db1中，2004年的db2,以此類推。當然也可以按主鍵標準拆分。

優點：可部分遷移

缺點：資料分佈不均，可能2003年的訂單有100W，2008年的有500W。

 

(2)hash取模分

對user_id進行hash（或者如果user_id是數值型的話直接使用user_id的值也可），然後用一個特定的數字，比如應用中需要將一個資料庫切分成4個資料庫的話，我們就用4這個數字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結果為1的時候對應DB1；結果為2的時候對應DB2；結果為3的時候對應DB3；結果為0的時候對應DB4，這樣一來就非常均勻的將資料分配到4個DB中。
優點：資料分佈均勻
缺點：資料遷移的時候麻煩；不能按照機器效能分攤資料 。

 

(3)在認證庫中儲存資料庫配置

就是建立一個DB，這個DB單獨儲存user_id到DB的對映關係，每次訪問資料庫的時候都要先查詢一次這個資料庫，以得到具體的DB資訊，然後才能進行我們需要的查詢操作。
優點：靈活性強，一對一關係
缺點：每次查詢之前都要多一次查詢，會造成一定的效能損失。

原文:http://www.studyofnet.com/news/379.html