J2EE 與 IBM 對象-關(guān)系數(shù)據(jù)庫系列連載三

2019-11-18 12:28:19

字體：大中小

供稿：網(wǎng)友

　　IBM ORDBMS 數(shù)據(jù)庫提供了大量功能，可以簡化軟件開發(fā)，減少硬件需求，以及加快進(jìn)入市場的步伐。您必須在設(shè)計中善加利用，以便從中受益。IBM ORDBMS 不僅僅是一個持久性存儲器，更是一條提高您生產(chǎn)率和效率的路徑。
　　
　　非同小可的對象危機(jī)
　　
　　理論上，以及在許多實際案例中，對于持久對象的操作需要實例化該對象，對其進(jìn)行操作，以及與持久性存儲器保持同步。這就導(dǎo)致了容器治理的持久性以及獨(dú)立于數(shù)據(jù)庫的思想：“使用容器治理的持久性的好處是，實體 bean 可以在邏輯上獨(dú)立于存儲該實體的數(shù)據(jù)源。…”
　　
　　該規(guī)范還提到數(shù)據(jù)源可以是關(guān)系型的，也可以是非關(guān)系型的，如 IMS。當(dāng)然還可以是面向?qū)ο蟮臄?shù)據(jù)庫。任何修改容器治理 bean 的交互都需要與該數(shù)據(jù)源保持同步，以確保實體 bean 的一致視圖。對 EnterPRise javaBean（EJB）使用 chatty 接口會顯著地增加數(shù)據(jù)庫的交互量，從而可能導(dǎo)致性能問題。
　　
　　“每次實例化一個對象”的中心思想有可能會引起性能和容量問題。該問題不是僅限于容器治理的實體 bean 的使用中，而是普遍存在于面向?qū)ο蠓椒ㄖ小Ｗ屛覀冇靡粋€簡單的示例來加以說明。假設(shè)有一家專門從事貸款發(fā)放的大型銀行。它遍及多個區(qū)域，每個區(qū)域包括幾十甚至上百家支行。
　　　 J2EE 與 IBM 對象-關(guān)系數(shù)據(jù)庫系列連載三（圖一）

J2EE 與 IBM 對象-關(guān)系數(shù)據(jù)庫系列連載三（圖一）

　　圖 5. 銀行貸款機(jī)構(gòu)
　　
　　圖 5 說明該銀行對應(yīng)多個區(qū)域，每個區(qū)域都有多個支行，而每個支行又進(jìn)行多項貸款。它還顯示我們可以獲得不同種類的貸款。
　　
　　假如該銀行需要獲得一份清單，列出那些在貸款中承擔(dān)了過高風(fēng)險的支行，它就會按區(qū)域來收集該清單。每個區(qū)域?qū)⑺阉髌渲校业侥切╋L(fēng)險過高的。而支行本身必須查詢每一項貸款的風(fēng)險和貸款額，用以計算該支行的平均風(fēng)險。
　　
　　以下是一種適宜的對象方式：每個對象封裝自身的信息和處理。支行要獲得貸款風(fēng)險的惟一方法就是向該貸款查詢這一信息。該方式比較合理，因為它消除了對象類型之間的緊密耦合。對象間的通信取決于定義良好的接口。只要該接口保持不變，就可以修改其實現(xiàn)，且不影響整個系統(tǒng)。
　　
　　本例中，假如我們考慮：該銀行遍及 10 個區(qū)域，每個區(qū)域有 100 家支行，而每家支行又有 10,000 份貸款，我們總共創(chuàng)建了 1000 萬多個對象來響應(yīng)該查詢。要求每份貸款返回兩個值：風(fēng)險級別和貸款額。在區(qū)域和支行之間的通信中，這會在兩個對象之間傳遞超過 2000 萬條消息。最后從內(nèi)存中刪除這些對象需要進(jìn)行額外處理。
　　
　　所使用的數(shù)目（10/100/10,000）絲毫不過分，我們絕對可以想像將生成更大數(shù)量級對象的系統(tǒng)。這很輕易成為一個性能以及容量（例如內(nèi)存）問題。若通過給應(yīng)用程序服務(wù)器增加節(jié)點來解決該問題，非但解決不了，反而會增加復(fù)雜性。
　　
　　通過利用 DB2 和 IDS 等對象-關(guān)系數(shù)據(jù)庫的優(yōu)點，即使無法消除該問題，也可以有所緩解。請記住，大多數(shù)面向?qū)ο笕藛T僅僅將數(shù)據(jù)庫看作持久性存儲器。他們習(xí)慣于將所有處理放在對象的代碼中完成，事后才添加數(shù)據(jù)庫。
　　
　　假如考慮面向?qū)ο笫呛螘r成為主流的，我們就可以設(shè)想，現(xiàn)在絕大多數(shù) 30 出頭或更年輕的程序員已經(jīng)被練習(xí)成以這種方式來思考了。由于數(shù)據(jù)庫僅僅用于“持久保存”對象以及檢索它，所以系統(tǒng)開銷最小的數(shù)據(jù)庫在該模型中就占有優(yōu)勢。這會有利于層次、網(wǎng)絡(luò)和對象數(shù)據(jù)庫。而對象-關(guān)系型的數(shù)據(jù)庫可以完成比持久保存對象多得多的功能，卻成為永遠(yuǎn)不被啟動的大引擎。這就好比是在一場用賽車對抗自行車的比賽中，卻不答應(yīng)您發(fā)動引擎一樣。
　　
　　讓我們來解釋一下：面向?qū)ο蠓椒ㄊ莾?yōu)秀的。問題在于許多架構(gòu)師和開發(fā)人員視野過于狹隘，不知道可以選擇將處理置于何處。這一選擇結(jié)果會影響設(shè)計，并且可以帶來重大性能影響。利用 ORDBMS 的優(yōu)點可以簡化設(shè)計，以及極大地提高結(jié)果系統(tǒng)的性能。這相當(dāng)于加快進(jìn)入市場的步伐，以及降低開發(fā)和維護(hù)的成本。更快的結(jié)果還可以帶來重要的商業(yè)優(yōu)勢。
　　
　　數(shù)據(jù)庫獨(dú)立性
　　
　　我在前面已提到 J2EE 通過促進(jìn)數(shù)據(jù)庫獨(dú)立性來提高應(yīng)用程序的可移植性。并且還進(jìn)一步提到可以是任何類型的數(shù)據(jù)庫：關(guān)系（對象-關(guān)系）或非關(guān)系的。這是整個 J2EE 體系結(jié)構(gòu)的一個美好目標(biāo)，但在構(gòu)建商業(yè)應(yīng)用程序中卻是一種十分危險的方法。
　　
　　商業(yè)應(yīng)用程序的目標(biāo)應(yīng)該是提供對抗競爭者的商業(yè)優(yōu)勢，而非可移植性。可移植性是一個次要目標(biāo)。假如需要進(jìn)行移植，可以將不可移植的部分隔離起來，以便限制所需的工作。我們需要以盡可能最低的成本獲得盡可能快的響應(yīng)。假如您針對移植性進(jìn)行設(shè)計，就要設(shè)計最底層的功能，從而放棄所有優(yōu)勢。這就像雇主拒絕雇用一個高度稱職的人，因為怕他某一天離開，而下一任雇員的能力可能遠(yuǎn)遠(yuǎn)不及。按照該邏輯，我們應(yīng)該雇用最無能的人。否則的話，我們應(yīng)該確保限制雇員對公司的貢獻(xiàn)，這樣，假如我們哪天必須用一個遜色一些的人來接替他時，就不會感到失望。期望越多，您將得到越多。而期望越少，您得到的也會隨著時間越來越少。
　　
　　這同樣也適用于企業(yè)應(yīng)用程序。您應(yīng)該權(quán)衡您的數(shù)據(jù)庫系統(tǒng)的所有功能，并且對于能夠帶來商業(yè)優(yōu)勢的功能善加利用。您可以在設(shè)計中隔離數(shù)據(jù)庫的交互，以便當(dāng)您偶然必須遷移到另一數(shù)據(jù)庫時，就只需要完成有限的移植工作。由于數(shù)據(jù)庫的競爭十分激烈，所以，很可能您現(xiàn)在計劃使用的獨(dú)特的新功能將來會出現(xiàn)在某個競爭對手的數(shù)據(jù)庫中。或者，在數(shù)據(jù)庫供給商為爭取您的業(yè)務(wù)，協(xié)商將如何補(bǔ)償其缺點時，這可能成為其中的一個缺點。因此，設(shè)計要謹(jǐn)慎，但也要贏得成功。
　　
　　J2EE 復(fù)雜性
　　
　　J2EE 具有許多好處，有助于商業(yè)應(yīng)用程序的開發(fā)。它們包括平臺獨(dú)立性、組件架構(gòu)、多層應(yīng)用程序模型、統(tǒng)一的安全模式以及一個豐富的標(biāo)準(zhǔn)集合，這些標(biāo)準(zhǔn)涉及事務(wù)控制、數(shù)據(jù)庫訪問和消息傳遞等領(lǐng)域。實際上，J2EE 在一個架構(gòu)下集成了過去 50 年左右軟件中所取得的進(jìn)展。這也付出了一定的代價：復(fù)雜性。
　　
　　盡管 WebSphere Studio application Developer 等工具明顯地簡化了開發(fā)，而且 WebSphere Studio Application Developer 治理控制臺提供了控制，在啟動大型項目之前，我們還是必須確保已經(jīng)具備了適當(dāng)?shù)膶I(yè)知識。最有效的方法就是培訓(xùn)與聘請專家顧問相結(jié)合。
　　
　　同樣重要的是，要具有一支包括了各個領(lǐng)域?qū)＜业木C合隊伍。在項目啟動之前，要將這支隊伍聚集在一起。例如，數(shù)據(jù)庫治理員（DBA）和 SQL 專家應(yīng)該從一開始就一起討論將如何使用不同的對象。讓我們用一個示例來加以說明。
　　
　　從 DICOM 對象之間的關(guān)系。我們看到，每一種類型的 DICOMData 都可以包含許多其他的 DICOMData 對象。我們可以通過標(biāo)準(zhǔn)的關(guān)系方法或使用新的數(shù)據(jù)類型，在數(shù)據(jù)庫中表示該層次結(jié)構(gòu)關(guān)系。一個數(shù)據(jù)元素是由一個標(biāo)簽（tag）和一個值表示。存在不同類型的值，如字符串、日期（date）、小數(shù)（decimal）等一個值還可以具有重復(fù)字段。一個 DICOMData 對象有可能包含幾百種不同的數(shù)據(jù)元素。但實際上，數(shù)目要少得多。
　　
　　將一個 DICOMData 對象表示為一大行幾乎為空的數(shù)據(jù)元素既不實際，也不可能。那么，我們可以將 DICOMData 對象表示為 DICOM 對象本身與數(shù)據(jù)元素之間的關(guān)系。第一種方法是為每一種類型的數(shù)據(jù)元素預(yù)備一個數(shù)據(jù)元素表。這會產(chǎn)生 23 個表，而且檢索一個 DICOMData 對象要連接 24 個表。其他的方法可能答應(yīng)我們將 23 個表縮減為一個。即便如此，通過關(guān)系型數(shù)據(jù)庫來存儲和檢索 DICOMData 對象也要付出昂貴的代價。
　　
　　假如數(shù)據(jù)庫專家恰好從一開始就參與進(jìn)來了，那么就可以討論這些問題，并可以揭示那些使實現(xiàn)更加輕易的新信息。結(jié)果顯示每種類型的 DICOMData 對象中只有少數(shù)元素將用于搜索。這就答應(yīng)我們表示 DICOMData 對象中的少量值，并且將所有其他的數(shù)據(jù)元素組合成一個大型對象列。在存儲和檢索 DICOMData 對象時，這帶來了顯著的性能提高。
　　
　　在前一小節(jié)中，我們討論了通過向每個支行查詢貸款上所承擔(dān)的平均風(fēng)險度導(dǎo)致的對象爆炸（見圖 5）。DB2 UDB 和 IDS 的對象-關(guān)系功能答應(yīng)我們擴(kuò)展數(shù)據(jù)庫功能，以便在數(shù)據(jù)庫中包含風(fēng)險計算函數(shù)。那么，我們可以使用存儲過程或用戶定義的聚集來計算每個支行的平均風(fēng)險。我們甚至可以添加條件，其中定義了不能接受的風(fēng)險級別，并且規(guī)定只檢索處于過高風(fēng)險中的支行清單。結(jié)果帶來了顯著的性能增長，因為我們不必實例化一百萬個對象，并且避免了對象之間的多數(shù)消息傳遞。在對象人員看到了許多對象創(chuàng)建和通信的地方，數(shù)據(jù)庫人員可以找到直接提供對策的辦法。在恰當(dāng)?shù)牡胤竭M(jìn)行處理將提供更簡單、更高效的解決方案。
　　
　　J2EE 的其他方面也增加了它的復(fù)雜性。這包括牽涉共享 EJB 的多線程環(huán)境。您如何共享 EJB 呢？在一次更新中又如何協(xié)調(diào)多個 EJB 呢？您的代碼是可重入的，還是設(shè)置必須鎖定的臨界區(qū)呢？這將導(dǎo)致許多問題，如數(shù)據(jù)完整性、鎖定策略以及數(shù)據(jù)庫人員所熟知的一些問題。
　　
　　那么，存在 EJB 訪問的性能問題，您需要以怎樣的粒度進(jìn)行才能獲得高性能。您還必須確定如何監(jiān)控應(yīng)用程序以找到性能瓶頸。
　　
　　J2EE 環(huán)境在開發(fā)和運(yùn)行企業(yè)應(yīng)用程序中表現(xiàn)極佳。但由于其復(fù)雜性，不宜濫用。假如希望項目取得成功，您就要在初期組織好一支合適的專家隊伍來共同完成。
　　
　　尋求解決方案本文前面所提出的問題沒有理想的解決方案。要從正確的培訓(xùn)抓起，這樣您才能充分使用解決方案的所有組件。其中可能包括在 Web 瀏覽器中使用 applet、中間件當(dāng)中的合理設(shè)計、以及利用數(shù)據(jù)庫系統(tǒng)的優(yōu)點。
　　 J2EE 與 IBM 對象-關(guān)系數(shù)據(jù)庫系列連載三（圖二）