論分布式數據庫的設計與實現
-MIS系統(tǒng)
[摘要]
分布式數據庫系統(tǒng)把應用所需的數據存放在多個數據庫服務器上,完成某個數據操作要涉及到訪問多個服務器,這適用于某種特定需要的應用。我在主持設計開發(fā)的一個MIS系統(tǒng)中,為了達到了在低速網絡通道下有效提高應用程序性能的目的,使用了 Sybase的分布式數據庫技術。我設計的這個系統(tǒng)是采用典型的C/S結構,但許多客戶端連接服務器的網絡采用電話線撥號,速度有限,傳統(tǒng)Windows界面的客戶端應用程序相應速度比較慢。考慮到B/S
結構也避免不了大量數據從服務器端傳輸到客戶端,我認為WEB界面并不能有效解決這個問題,所以采用了優(yōu)化數據庫結構的方法,把數據分兩部分存放,基礎數據放客戶機,會員資料主要采用鍵碼放服務器,應用程序再現數據時從服務器取鍵碼,到客戶機取対應的解釋,由于鍵碼的數據重少,網絡傳輸便快。在構建這個分布式數據庫系統(tǒng)的過程中,我著重研究并解決了數據同歩和事務協調的問題,取得了良好的應用效果。我認為,分布式數據庫系統(tǒng)的技術在Intenet時代正當其道,大有發(fā)展前景。
[正文]
分布式數據庫系統(tǒng)把數據存放在多個數據庫服務器上,當應用提取所需數據時,要訪問多個服務器,綜合多點數據才能完成。分布式數據庫技術在很多場合得到了應用。譬如某企業(yè)隨著業(yè)務量的擴大,原有數據庫服務器已經達到了容量和性能極限,如果不希望丟棄原有投資,可以建立另外一套新的數據庫,跟原有的系統(tǒng)組成一個分布式數據庫系統(tǒng),給應用提供透明統(tǒng)一的數據訪問.還有,如果某企業(yè)分成多個業(yè)務部門,而且地域分散,可以在某個部門放置單獨的數據庫服務器,用于存放該部門最常用的數據,而部門和部門之間相互引用的數據可以通過分布式數據庫技術來方便地完成。分布式數據庫不是簡單地把集中數據庫分散實現,而是針対某種特定應用需要而誕生,它必然具有自己特有的性質和特征,需要在上面做許多的工作,來滿足應用的要求。
我在設計、開發(fā)一個MIS系統(tǒng)時,針対應用的需要而引入分布式數據庫技術,取得了良好的效果。該系統(tǒng)針対會員資料的管理而設計,用于管理會員入會、繳納會費、申請資助、辦理資助審批、關系轉移、退會和注銷手續(xù)等等業(yè)務流程。分三個級別的應用權限一一基層單位級、總公司級和集團公司級,各個級別只能操作各自范圍內的業(yè)務數據。該系統(tǒng)采用典型的C/S結構,后臺數據庫采用Sybase,前端應用采用FB開發(fā)工具來設計標準的Windows操作界面。
我在其中任系統(tǒng)分析和數據庫設計的角色,擔任了調查業(yè)務需求、業(yè)務建模和數據庫建模、數據庫設計以及指導應用程序測試、優(yōu)化系統(tǒng)和應用的性能等等一系列工作。由于客戶端地域的分散,遍及多個省境內,許多使用該系統(tǒng)的基層單位連接服務器數據庫的網絡采用電話線撥號方式,速度有限,在使用客戶端應用程序時感覺界面速度很慢。經過分析,認識到許多操作都要從服務器中取數據,速度慢就慢在數據訪問上。服務器是沒有性能瓶頸的,問題出在網絡速度上。不可能要求眾多使用客戶改善和升級他們的網絡,只能充分挖掘軟件的潛力,來適應這種低速網絡的使用模式。
經探討,結合關系數據庫的知識,認識到,應用程序的每一次數據庫操作,都要訪問多個相關聯的表,其中,有會員資料表和基礎數據表,會員資料表中存放許多的鍵碼信,在基礎數據表中有鍵碼相應的解釋。鍵碼信的數據量比較少,而基礎數據是靜態(tài)的,幾乎不會更改。如果考慮把會員資料放在服務器上,基礎數據放在客戶端,當應用程序中訪問數據時,總是從服務器上存取會員資料,從客戶端提取會員資料中鍵碼的相應解釋。由于鍵碼的數據
量少,便減少了網絡上傳送的數據量,從而提高了界面的響應速度。
同時考慮到基層單位總是操作自己所屬的部分會員,増刪轉移操作少,會員列表比較固定,而每一項業(yè)務操作都涉及到要從會員列表中查找定位到某個會員,所以會員列表是最常訪問的數據項。把會員列表從會員資料數據中抽取出來,也放置在客戶端,這樣,便進一歩改善了性能。
把數據分散存放只是工作的第一歩,接下來要考慮應用程序怎樣訪問這種分布式數據。開發(fā)應用時,如果每一功能都針対兩個數據庫進行,就帶來了很多麻煩。所以,我們研究了Sybase的分布式數據庫技術,決定采用了 CIS (組件集成服務)部件,來合并兩個數據庫成一個統(tǒng)一的分布式數據庫。應用程序只要連接一個數據庫,就可以透明統(tǒng)一訪問到兩個數據庫中的數據。
該技術具體實施方法是,在客戶端數據庫中建立一個対服務器數據庫的遠程訪問服務名,包含訪問地址、登錄用戶名、登錄密碼等等關鍵的連接信息;并且対服務器中會員資料數據表建立一個本地代理表,結構和服務器中遠程表完全一樣,它是訪問服務器中會員資料的中轉和代理??蛻舳藨贸绦蛟L問本地代理會員資料表時,實際上是通過預定義的遠程訪問服務名中包含的連接信息到服務器中対應的實際會員資料表中訪問數據。這種訪問対于客戶端完全透明,感覺不到是從物理上獨立的兩個服務器中存取數據。所以,這種數據庫結構是典型的分布式數據庫。部署這種分布式數據庫不是難事,只要在客戶端和服務器上安裝12.0版以上的數據庫服務器,在客戶端服務器上建立遠程服務名和代理表即可。由于Sybase數據庫的安裝支持腳本方式,在客戶端應用程序的標準安裝過程中,嵌入Sybase數據庫的安裝和配置腳本,就自動化地完成了所有工作。
在實際使用該分布式數據庫系統(tǒng)的過程中,遇到了幾個問題。第一,數據同歩??蛻舳嘶A數據不是絕対靜態(tài)的,也有變化,因此在服務器端要設置一個統(tǒng)一的基準,稱為主點數據??蛻舳丝偸菑椭剖褂?,稱為復制點數據。如何及時感知到服務器端主點數據的變化,有效率地復制到客戶端,是個難題。Sybase針対這種應用場合,提供了復制服務器技術,但為了避免過于復雜,我們實際采用應用程序來管理同歩。當服務器端主點數據有了更改時,保
存一個相應的標識和時間戳,客戶端應用在登錄服務器時,檢查這種標識,一檢測到了數據有更新,就首先下載,然后再進入系統(tǒng)正常使用。這種方法實現起來,増加了額外的開發(fā)量,
且不能判別繞過應用程序対數據的直接修改,但是,是最簡單和有效的方法。第二個問題是事務協調問題。物理上獨立的兩個數據庫,在協同操作時,如果服務器正好停機或者網絡故障,完整的一個事務沒能完成,就會“事務崩潰雖然Sybase CIS內嵌了兩階段提交技術,能夠自動恢復。但是應用程序在這種情況下,敏感性不夠,操作界面會無端凝固,影響了使用的方便性。我們針対PB対于連接的判斷和感知,用了一個小小編程技巧,使應用程序能夠及時感知到數據庫連接故障,及時停止和恢復事務,使操作界面表現友好靈活。
以上遇到的這些問題,都找到了解決辦法。分布式數據庫技術的應用并不是非常復雜,它往往為解決特定問題、滿足特定需要而被采納,使用得當,會給應用帶來了許多便捷。在當今信息社會里,互聯網絡帶來了相互連通的便捷,而且知識爆炸,數據的分布式訪間是個必然趨勢。潮流興起的XML技術,提供了各種平臺數據庫之間的一個公共數據訪問標準,可能會用來構建更加靈活、適應性更強的分布式數據庫技術。
本文摘自 :https://blog.51cto.com/u