對于一個具有海量數(shù)據(jù)的系統(tǒng)來說，性能的瓶頸最終就只能落在數(shù)據(jù)庫身上了，這時候硬件升級和程序優(yōu)化已經(jīng)是無能為力，一個簡單的查詢也有可能給數(shù)據(jù)庫帶來沉重的負擔。網(wǎng)格計算可把把一個需要巨大的計算能力才能解決的問題分割成許多小部分，然后把這些小部分分配給許多計算機進行處理，最后把這些計算結(jié)果綜合起來得到最終結(jié)果。對數(shù)據(jù)庫進行網(wǎng)絡(luò)計算的架構(gòu)設(shè)計，無疑可能解決上述的性能問題。

　　那么怎么把一個巨大的數(shù)據(jù)庫分割成許多小的數(shù)據(jù)庫呢？現(xiàn)階段比較行之有效的方法是對數(shù)據(jù)庫進行分區(qū)處理。對于一個巨大容量的數(shù)據(jù)表，可不可以按日期，或者按類型，或者按區(qū)域，或者按ID號進行分割呢？答案是肯定的，這種分區(qū)方法也就是所謂的水平分區(qū)方法。另一方面，對于不同類型的數(shù)據(jù)，比如一個電子商務(wù)系統(tǒng)中的用戶數(shù)據(jù)、商品數(shù)據(jù)、交易數(shù)據(jù)等，它們之間的聯(lián)系不是很緊密，可以存放在不同的數(shù)據(jù)庫中，這樣就可實現(xiàn)了垂直分區(qū)。

　　經(jīng)過分區(qū)處理，一個大的數(shù)據(jù)庫，可以分成許多小的數(shù)據(jù)庫。但是這樣一來，對于這些小數(shù)據(jù)庫的訪問，和怎么進行綜合處理，就引發(fā)出新的問題出來了。

　　在一個系統(tǒng)中，對這些數(shù)據(jù)庫進行訪問不是沒有可能，使用多個連接，多重處理，無論在哪種框架中都很容易實現(xiàn)。問題是，在一個系統(tǒng)中分別對這些數(shù)據(jù)庫進行訪問，其程序的復(fù)雜度和處理效率，有可能會產(chǎn)生出另一個瓶頸，這就不是我們需要的結(jié)果了。當然也可以使用負載均衡設(shè)計，但是其程序的復(fù)雜度還是不可避免。

　　這里，再引進另一個概念：SOA架構(gòu)，即面向服務(wù)的體系結(jié)構(gòu)。SOA可以通過服務(wù)生產(chǎn)者/服務(wù)消費者的方式，或訂閱/發(fā)布的方式等提供松散耦合的分布式服務(wù)體系。那么，對于各個不同區(qū)域的數(shù)據(jù)庫，就可以按照SOA架構(gòu)做成不同的服務(wù)中心，對外提供數(shù)據(jù)庫訪問接口。SOA可以使用CORBA、Web Service等方式予以實現(xiàn)。

　　這樣一來，數(shù)據(jù)庫服務(wù)器的壓力分散了，程序計算的壓力也分散了，不管數(shù)據(jù)庫的數(shù)據(jù)量有多大，程序計算有多復(fù)雜，系統(tǒng)的性能都能得到最大限度的提升。

　　最后，大家可能會說，如果有一個網(wǎng)格數(shù)據(jù)庫系統(tǒng)就好了，應(yīng)用系統(tǒng)的設(shè)計就不用那么復(fù)雜了。是的，現(xiàn)在的數(shù)據(jù)庫系統(tǒng)也有向這一方向設(shè)計的趨勢，只是技術(shù)還沒有成熟。相信在不久的將來，應(yīng)該可以用到網(wǎng)格數(shù)據(jù)庫。

　　參考：

　　網(wǎng)格計算：http://baike.baidu.com/view/20049.htm

　　SOA：http://baike.baidu.com/view/21305.htm?fr=ala0_1_1

it知識庫：網(wǎng)格數(shù)據(jù)庫架構(gòu)設(shè)計構(gòu)想，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。