大數(shù)據(jù)的出現(xiàn)加劇了DBA的問題，因為現(xiàn)在多個分布式應(yīng)用需要訪問一個非常龐大的數(shù)據(jù)存儲。那么在DB2的環(huán)境下，有哪些可用調(diào)優(yōu)的方法呢?
DBA必須首先解決常見的應(yīng)用性能瓶頸。如果數(shù)據(jù)可用性或性能已經(jīng)很差，那么面向高性能訪問大數(shù)據(jù)就會出現(xiàn)問題。這里是一份常見的調(diào)優(yōu)問題列表，DBA要確保數(shù)據(jù)庫存在這些流程以減輕這些潛在的問題。
數(shù)據(jù)訪問模式的糟糕設(shè)計
如果表中某個記錄集訪問頻繁，那么它們便可成為一個“熱點”。比如一個按訂單號排序的訂單表。最近的訂單會在它們處理的時候更加活躍。由于多個應(yīng)用程序和工具訪問少量記錄，那么數(shù)據(jù)訪問的影響就會集中在數(shù)據(jù)庫中的一個小范圍內(nèi)。當某些事務(wù)鎖定或聲明數(shù)據(jù)時，而其他應(yīng)用程序或工具試圖對它們進行訪問，這通常就會導(dǎo)致性能問題。
這樣的熱點可以在數(shù)據(jù)庫設(shè)計階段加以預(yù)測。DBA可以在數(shù)據(jù)庫中嵌入空白空間來分散數(shù)據(jù)，這樣就降低了在一個物理點活動的集中程度。其他選項包括分配記錄到整個數(shù)據(jù)庫的方法。在我們以上的訂單表例子中，DBA可能會實現(xiàn)以地理位置進行排序而非按訂單號排序的表。這樣，新訂單就不會彼此相鄰，而是分布于整個物理表。
過度加鎖
在DB2環(huán)境中有兩個流程級別可以“存儲”數(shù)據(jù)：SQL流程和數(shù)據(jù)庫工具。SQL流程包括應(yīng)用程序發(fā)布靜態(tài)SQL語句和動態(tài)發(fā)布的SQL語句。SQL會發(fā)布針對數(shù)據(jù)的鎖，并且這些鎖通常會避免數(shù)據(jù)正在被讀取的時候并發(fā)更新。此外，加鎖會避免諸如Load之類的工具加載數(shù)據(jù)，這會導(dǎo)致取代或是覆蓋正在被讀取的數(shù)據(jù)。工具會發(fā)布針對數(shù)據(jù)的聲明。一條聲明類似于數(shù)據(jù)庫鎖，是因為它可以通過實體來保留數(shù)據(jù)以供訪問并避免某些并發(fā)的SQL訪問。一般來說，加鎖會強制聲明去等待，而聲明會強制SQL操作去等待。這就允許數(shù)據(jù)庫管理系統(tǒng)可以管理多個諸如Load或是Image Copy之類的并發(fā)工具，而不用受到SQL語句的干擾。
最常見的加鎖問題是SQL語句鎖定太多的數(shù)據(jù)。一條SQL語句讀取一條記錄通常會在此SQL語句執(zhí)行期間鎖定多條記錄為只讀。這種行為在多個地方是受控的，包括語法，數(shù)據(jù)庫定義，以及通過應(yīng)用程序提交語句的用法。DBA應(yīng)該審查SQL語句加鎖行為來確保鎖定最小量的數(shù)據(jù)。了解鎖定對象的大小和應(yīng)用是如何訪問數(shù)據(jù)的。
長期運行的應(yīng)用程序可能會長時間鎖定數(shù)據(jù)，從而降低了數(shù)據(jù)可用性�？紤]記錄級別的鎖定來最小化SQL的影響，盡管這可能會導(dǎo)致用于管理加鎖的CPU時間有所上升。應(yīng)用程序提交邏輯同樣應(yīng)該加以審查，提交會釋放鎖定并允許數(shù)據(jù)訪問。此外，DBA應(yīng)該審查應(yīng)用程序和工具的調(diào)度。例如，驗證諸如Image Copy這類工具在應(yīng)用程序做數(shù)據(jù)庫更新的時候沒有在并發(fā)運行。
大數(shù)據(jù)應(yīng)用調(diào)優(yōu)
大數(shù)據(jù)通常意味著一個需要高速數(shù)據(jù)分析軟件的大型數(shù)據(jù)存儲。很多時候這些大數(shù)據(jù)部署與企業(yè)數(shù)據(jù)倉庫共存。這意味著DBA人員必須與數(shù)據(jù)倉庫人員進行協(xié)作以保證良好的性能。下面提到的一些點需要我們充分考慮：
置于一個專門的軟硬件一體化設(shè)備中的大數(shù)據(jù)必須經(jīng)常由數(shù)據(jù)倉庫表同時進行訪問。這通常是利用SQL連接語句加以實現(xiàn)的。DBA必須協(xié)調(diào)大數(shù)據(jù)設(shè)備的加載和數(shù)據(jù)倉庫的ETL流程以確保所有數(shù)據(jù)在查詢階段是可用的。
存儲于非常大的DB2表中的大數(shù)據(jù)可能會有特殊的恢復(fù)需求�？紤]一個要每天進行分析的事務(wù)數(shù)據(jù)的大型存儲。業(yè)務(wù)管理者可能會認為此分析對日常生產(chǎn)至關(guān)重要，從而指定此數(shù)據(jù)為關(guān)鍵任務(wù)。如果發(fā)生故障，這些數(shù)據(jù)要怎樣才能恢復(fù)呢?對于一個數(shù)據(jù)倉庫最佳的做法就是指定數(shù)據(jù)在恢復(fù)上為低優(yōu)先級的。
存儲在DB2表中的大數(shù)據(jù)可能需要DBA去降低或是最小化數(shù)據(jù)上索引的數(shù)量。雖然通常來說可以添加多個索引到一個表來改善查詢性能，而對于非常大的表其索引也會很大。磁盤存儲限制可能會阻止DBA創(chuàng)建某些索引。此外，更多的索引會減緩數(shù)據(jù)插入性能，同樣還會讓任何數(shù)據(jù)庫恢復(fù)過程運行更長的時間。
數(shù)據(jù)倉庫訪問優(yōu)化
數(shù)據(jù)倉庫的ETL流程有其自身獨特的性能問題。數(shù)據(jù)提取流程通常會作為多個并行數(shù)據(jù)查詢流程加以執(zhí)行。數(shù)據(jù)倉庫團隊可能會使用高速網(wǎng)絡(luò)來加速這一流程。由于可操作數(shù)據(jù)可能不是以易于分析的形式呈現(xiàn)的，因此數(shù)據(jù)轉(zhuǎn)換需要編程技能。常見問題有空值，缺失或未知數(shù)據(jù)，甚至是諸如日期值為“99/99/9999”的無效數(shù)據(jù)。加載流程通常包括多個針對倉庫表并發(fā)加載的工具。加載通常是長期運行和資源密集型的。
由于分布式應(yīng)用試圖訪問大數(shù)據(jù)，它們也不可避免的會訪問數(shù)據(jù)倉庫數(shù)據(jù)。再次，DBA必須將此過程與數(shù)據(jù)倉庫ETL過程加以協(xié)調(diào)。常見的方法是架設(shè)有兩個分區(qū)的表，活動和非活動分區(qū)。目標表物理上被分為數(shù)據(jù)集和分區(qū)。一個分區(qū)被指定為活動分區(qū)，而一個控制表或參數(shù)被設(shè)置用來指示哪個分區(qū)是活動的。分布式查詢現(xiàn)在可能訪問活動的數(shù)據(jù)，允許加載流程把數(shù)據(jù)加載到非活動分區(qū)。一旦加載完畢，活動和非活動標記就會切換。
分布式處理和大數(shù)據(jù)
優(yōu)化分布式訪問性能的一個最佳實踐是使用資源約束分析。DBA會在收集性能數(shù)據(jù)的時候監(jiān)視諸如磁盤子系統(tǒng)和CPU之類的資源。甚至查詢和工作運行時間也可以被當做是資源。當DBA發(fā)現(xiàn)某項資源受限時，他們會平衡其他資源以進行彌補。
大數(shù)據(jù)可能意味著大的性能問題，并且通過分布式應(yīng)用程序進行訪問會將這些問題進一步復(fù)雜化。DBA可以通過考慮以下方面來主動了解這些問題：
·數(shù)據(jù)庫設(shè)計選項；
·執(zhí)行資源約束分析；
·利用Explain優(yōu)化分布式查詢；
·協(xié)調(diào)大數(shù)據(jù)訪問和數(shù)據(jù)倉庫訪問；
分布式應(yīng)用程序?qū)τ贒BA來說可能會是個挑戰(zhàn)。通過解決當前以及潛在的數(shù)據(jù)可用性問題作為開始，尤其是那些企業(yè)數(shù)據(jù)倉庫中的問題。一旦這些擔憂得以緩解，那么DBA就可以開始管理對大數(shù)據(jù)的分布式數(shù)據(jù)訪問。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.lukmueng.com/
本文標題：如何進行分布式大數(shù)據(jù)應(yīng)用調(diào)優(yōu)
本文網(wǎng)址：http://www.lukmueng.com/html/consultation/10839712549.html
相關(guān)文章
