大型數(shù)據庫系統(tǒng)設計與功效研究

1、 大型數(shù)據庫系統(tǒng)設計與功效研究摘要：影響數(shù)據庫性能是綜合性的。包括dbms本身性能、數(shù)據庫邏輯設計、數(shù)據庫查詢設計及數(shù)據庫運行環(huán)境等。本文分析了數(shù)據庫性能的影響因素并提出解決方案。從而有針對性解決數(shù)據庫性能瓶頸因素。關鍵詞：數(shù)據庫；索引；自定義函數(shù)；tpcc0引言數(shù)據庫特別是大型數(shù)據庫的執(zhí)行效率一直是困擾系統(tǒng)用戶的最大問題。軟件項目在設計時，由于測試用例的數(shù)據量很小，很多有關執(zhí)行效率的問題都反映不出來。但當項目交付使用并運行一段時間后，隨數(shù)據量增大執(zhí)行效率將成為突出問題。開發(fā)者可能由于服務期已過，也沒有精力和興趣去解決這個“軟”性的性能問題。同時執(zhí)行效率和數(shù)據庫系統(tǒng)的硬件參數(shù)配置和網絡參數(shù)配置

2、有很大關系，邏輯設計和各種數(shù)據庫工具的使用將對數(shù)據庫執(zhí)行效率將帶來確定性的影響。數(shù)據庫項目設計技巧也會使系統(tǒng)有效避開數(shù)據流峰值和瓶頸等不利因素。本文將對從數(shù)據庫選型、數(shù)據庫系統(tǒng)硬件配置、數(shù)據庫系統(tǒng)結構設計對執(zhí)行效率的綜合影響及相應的量化方式進行研究和分析。1數(shù)據庫選型面對品種繁多的數(shù)據庫產品，如何才能獨具慧眼，選中適合自己的數(shù)據庫產品呢？正確的評估、選型與數(shù)據庫技術本身同樣重要。通常數(shù)據庫廠商都會在性能清單和技術基準表中盡量展現(xiàn)產品最佳的一面，對產品弱點卻避免提及或進行遮掩。其實在挑選和評估過程中，首要目標是選擇一款能夠滿足甚至超過預定要求的技術或解決方案。選型的正確方法將使用戶在面對眾多產品

3、時，做出最佳選擇。數(shù)據庫選型必須考慮五大因素：開發(fā)要求 、性能/成本、數(shù)據庫運行和管理、可升級性和總體擁有成本。首先，需要清楚自己究竟想使用什么開發(fā)技術。例如，你是要以訪問傳統(tǒng)的關系型數(shù)據庫？還是要以純面向對象技術構建j2ee應用平臺？又或是需要建設xml web services？如果你要實現(xiàn)的是純關系型的開發(fā)典范，那么實際要使用的受支持的標準（和非標準）sql功能有多少？如果你要規(guī)劃的是面向對象開發(fā)策略，那么在原計劃里的數(shù)據庫支持真正的面向對象嗎？它是如何支持的？若有需要,它能同時提供sql的功能嗎？數(shù)據庫支持這個功能嗎？雖然,有些關系型數(shù)據庫聲稱支持對象開發(fā)，但實際上并不是直接支持的。這

4、種非直接的體系結構將導致更多的事務處理故障，以及潛在的可升級性和性能問題。另外，你還需要確定自己的前端技術如何與后端進行“對話”。你的業(yè)務邏輯是放在客戶機一端呢？還是放在服務器一端？你要使用哪些腳本語言？它們與后端服務器的兼容性如何？它們是快速應用開發(fā)（rad）環(huán)境嗎？目前，實現(xiàn)基于關系型數(shù)據庫的應用可以選擇傳統(tǒng)的主流品牌，這些數(shù)據庫產品有著很成熟的關系技術以及廣泛的應用資源。但是,如果實現(xiàn)的是基于面向對象技術的應用、又或是數(shù)據結構更為復雜時，不妨考慮目前一些公司推出的所謂后關系數(shù)據庫。它所代表的正好是關系數(shù)據庫和面向對象技術的融合，以多維數(shù)據引擎作為核心，從根本上支持復雜的對象存儲及主流的二

5、維表，同時也已經配備了功能強大的應用服務引擎，可作對象邏輯操作的平臺。它的出現(xiàn)已經為傳統(tǒng)數(shù)據庫領域帶來了沖擊，而在面向對象數(shù)據庫方面更是廣受歡迎。測量數(shù)據庫性能最常見的方法是tpc基準。tpc明確地定義了數(shù)據庫方案、數(shù)據量以及sql查詢。測量的結果是，在特定的操作系統(tǒng)上配置了特定的數(shù)據庫版本，以及在驚人的硬件條件下每項事務的成本是多少其中的事務可以是tpc測試中定義的任何數(shù)據庫操作。從理論上來講，這類基準旨在提供不同產品間客觀的比較值。但在現(xiàn)實中，這些方案又有多少能準確反映并回答你在挑選技術時所存在的疑惑？其次，所有技術廠商發(fā)布的tpc基準都會超過以前發(fā)布的結果。這樣，tpc基準在更大程度上反

6、映的是為解決問題而投入的內存和cpu量，而不是數(shù)據庫性能的任何真實表現(xiàn)。只有在真實的環(huán)境中進行實際的比較測試才可以推斷出數(shù)據庫的預期性能及評估所需成本。常用的方法包括平衡移植，把原來的數(shù)據轉移到類似硬件上的另一套數(shù)據庫，然后以真實的客戶端連接這套測試對象。又或是以數(shù)據產生針對真實的數(shù)據模型，建立出龐大的數(shù)據量，再以客戶端連接作測試。這種做法跟實驗室中的做法的不同之處有以下幾點：第一，試驗中的硬件構架跟你預期的方案不會有太大的差別；第二，所測試的事務在寬度和深度方面跟未來計劃的也差不太遠；第三，如果是硬件條件一樣，我們可以直接看出測試對象跟原來方案有著多少差異。掌握了以上結論之后，我們應該可以更

7、精明地為所需的性能投入相應的成本。換句話說，我們將能夠更準確地預測各種數(shù)據庫的性能與相應的成本。2數(shù)據庫設計2.1數(shù)據模式設計在數(shù)據庫邏輯設計過程中，為了保證數(shù)據庫的一致性和完整性，數(shù)據庫要按照關系數(shù)據庫的規(guī)范化要求設計。滿足這些范式條件的關系模式可在不同程度上避免冗余、插入和更新異常問題。在基于表驅動的系統(tǒng)中,基本表的設計規(guī)范是第三范式3nf。但是在實際工作中,對于經常需要執(zhí)行查詢、匯總的列,如果按規(guī)范化理論設計肯定會增加表的連接操作而降低系統(tǒng)性能,這時可以降低數(shù)據庫對規(guī)范化理論的要求，以便滿足實際應用操作的需要。所以合理使用冗余會為查詢帶來很大的好處，比如經常被查詢的匯總數(shù)據可以在平時工作

8、中就累加好，不需要到查詢時再使用如sum之類的函數(shù)。2.2索引設計索引即將表數(shù)據按索引要求而產生有序的數(shù)據副本，這樣的查詢可以在有序表中進行，提高查詢數(shù)據的速度, 改善系統(tǒng)性能?？墒鞘褂盟饕矔馁M磁盤空間, 增加開銷, 降低dml (insert、update、delete )操作執(zhí)行的效率。因此設計時應盡量選擇有用的索引,在提高查詢速度和節(jié)省存儲空間之間尋求最佳的平衡點。數(shù)據庫服務器對數(shù)據進行訪問一般采用下面的兩種方式：索引掃描：通過索引訪問數(shù)據；表掃描：讀表中的所有頁。當對一個表進行查詢時，如果返回的行數(shù)占全表總行數(shù)的10%到15%時，使用索引可以極大的優(yōu)化查詢的性能。但是如果查詢涉及到

9、全表40%以上的行時，表掃描的效率比使用索引掃描的效率高。在具體使用的過程中，要結合實際的數(shù)據庫和用戶的需求來確定要不要索引以及在什么字段上建立什么樣的索引。下面給出一些通用的規(guī)則：在經常用作過濾器或者查詢頻率較高字段上建立索引；在sql語句中經常進行group by、order by的字段上建立索引；在不同值較少的字段上不必要建立索引，如性別字段；對于經常存取的列應避免建立索引；用于聯(lián)接的列（主健/外健）建立索引；在經常存取的多個列上建立聯(lián)合索引，但要注意聯(lián)合索引的建立順序要按照使用的頻度來確定。聚集索引是指行的物理順序與行的索引順序相同的索引。一個表只能有一個聚集索引。非聚集索引是指定表的

10、邏輯順序索引，行的物理順序與索引順序不盡相同，每個表可以有多個非聚集索引。缺省情況下建立的是非聚集索引，但是在一些特定的情況下建立非聚集索引會極大的縮短查詢的時間。有大量重復值、且經常有范圍查詢（between，>，=，<=）和order by、group by發(fā)生的列，可考慮建立聚集索引，而對于頻繁修改的列、或者返回小數(shù)目的不同值的這些情況應該避免建立聚集索引。使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢范圍，避免全表掃描。比如要返回2009年10月1日到2010年10月1日之間的數(shù)據，如果在日期的字段建立了聚集索引，那么數(shù)據本來就是按照日期的順序排列的，只要找到開始

11、和結尾日期的數(shù)據就可以了，可以極大的節(jié)省時間。而如果使用非聚集索引，必須查到這個時間段中每個日期對應的位置，然后在根據位置存取數(shù)據，明顯效率很低。顯而易見，使用聚集索引的優(yōu)勢很明顯。一個表只能按照一個固定的順序來存儲數(shù)據。因此，在建立聚集索引的時候一定要和實際查詢相結合，看哪個字段對于查詢貢獻大，而且操作不是很頻繁。索引有助于提高檢索性能，但過多或不當?shù)乃饕矔е孪到y(tǒng)低效。因為用戶在表中每添加一個索引，數(shù)據庫就要做更多的工作。過多的索引甚至會導致索引碎片。所以說，我們要合理使用索引體系，特別是對索引的創(chuàng)建，更應精益求精，使數(shù)據庫的性能得到更好的發(fā)揮。創(chuàng)建索引可以根據查詢業(yè)務的不同分為兩種:單

12、一列索引和聯(lián)合索引。單一列索引就是指在表的某一列上創(chuàng)建索引，聯(lián)合索引是在多個列上聯(lián)合創(chuàng)建索引。兩種索引比較結果如下：索引所占用空間:單一列索引相對要小；索引創(chuàng)建時間:單一列索引相對短；索引對insert，update，delete的影響程序:單一列索引要相對低；在多條件查詢時，聯(lián)合索引效率要高。索引的使用范圍:單一列索引可以出現(xiàn)在where 條件中的任何位置，而聯(lián)合索引需要按一定的順序來寫。最后要注意，對數(shù)據量大及使用頻繁的數(shù)據庫需要是要用索引優(yōu)化器來優(yōu)化索引。2.3查詢設計從大多數(shù)系統(tǒng)的應用實例來看, 查詢操作在各種數(shù)據庫操作中所占據的比重最大。許多程序員在開發(fā)數(shù)據庫應用程序時,只注重用戶界

13、面的華麗,并不重視查詢語句的效率問題,導致所開發(fā)出來的應用系統(tǒng)效率低下。因此,如何設計高效合理的查詢語句就顯得非常重要。(1)正確地使用索引正確使用索引可以大大提高查詢效率, 在條件子句中應盡量考慮有用索引的使用。例如,在學生登記表中,如果創(chuàng)建學號為單列索引, 那么查詢語句的where 子句中應使用學號這個索引,使之成為有用索引。(2)模糊匹配的避免like關鍵字支持通配符匹配，技術上稱為正則表達式。但這種匹配特別耗費時間，盡量避免使用模糊匹配。(3)子查詢合并子查詢合并是將某些特定的子查詢重寫為等價的多個表的連接操作。子查詢合并的作用在于能使查詢語句的層次盡可能地減少,從而可提高查詢的效率。

14、子查詢合并的一般規(guī)則為:如果外層查詢的結果沒有重復,即select子句中包含主碼,則可以合并其子查詢,并且合并后的select 子句前應加上distinct 標志；如果外層查詢的select 子句中有distinct標志,那么可以直接進行子查詢合并；如果內部子查詢結果沒有重復元組,則可以合并。(4)使用臨時表優(yōu)化查詢在涉及相關查詢的某些情形中， 構造臨時關系可以提高查詢效率。3數(shù)據庫系統(tǒng)配置3.1硬件系統(tǒng)配置數(shù)據庫服務器中最重要的配置參數(shù)有內存、cpu和網卡。目前影響最大的是內存。盡可能把數(shù)據放入內存，比臨時從硬盤中調入內存來的要快的多。如果內存太小，小會造成數(shù)據在內存與硬盤之間的頻繁調入調出

15、，如果內存的占用率超過50%,那就要考慮是否要擴大它。在內存足夠大時，系統(tǒng)可以考慮在每天的初始運行時，將數(shù)據預裝入內存也是一種行之有效的好方法。3.2功能模塊配置系統(tǒng)無論是c/s架構還是b/s架構。數(shù)據信息的系統(tǒng)處理時間都是由三部分組成：數(shù)據庫服務器處理時間；網絡傳輸時間；客戶端處理時間。所以解決系統(tǒng)性能的關鍵點就在于如何使得這三個時間的總和最小。在系統(tǒng)中數(shù)據庫服務器的配置和性能往往是最高。但它的工作也最繁重，要同時應對若干用戶的操作請求。同時我們注意到有些系統(tǒng)工作可以放在客戶端處理，也可以由數(shù)據庫服務器處理，但怎樣安排才好呢？這要具體看系統(tǒng)各組成部分的性能。(1)如客戶端功能弱而數(shù)據庫服務器

16、能力強，那么有些問題就可以用觸發(fā)器、自定義函數(shù)和視圖等形式交給數(shù)據庫服務器去處理。這樣不僅可以減輕客戶端壓力還帶來系統(tǒng)可維護性好的益處。(2)反之，如客戶端處理能力較強，而數(shù)據庫服務器壓力過大的話，有些諸如觸發(fā)器要完成的工作可以有客戶端來完成，如數(shù)據驗證、自動編號生成、數(shù)據統(tǒng)計等這樣一些工作可以交與客戶端來完成。(3)充分兼顧網絡傳輸時間。目前的網絡特別是互聯(lián)網絡，其流量壓力越來越大,峰值越來越頻繁。為平衡客戶端與數(shù)據庫服務器的工作，有時會將一些半加工的數(shù)據在網絡上傳輸，這些數(shù)據往往數(shù)據量就很大，給網絡環(huán)節(jié)帶來壓力就大。如果只能傳輸處理結果而不傳輸中間數(shù)據，這樣數(shù)據傳輸時間就最少，但這樣平衡客戶端和數(shù)據庫服務器的工作又比較難。所以要具體情況具體分析，充分兼顧網絡傳輸時間對系統(tǒng)的影響。4數(shù)據庫性能測試目前常用的數(shù)據庫基準性能測試工具是tpcc。關于它的運用方法這里不再贅述。當系統(tǒng)的性能下降以后，我們要分析下降的現(xiàn)象及產生原因