探討電話銷售系統(tǒng)的特性

前言：本站為你精心整理了探討電話銷售系統(tǒng)的特性范文，希望能為你的創(chuàng)作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

數(shù)據(jù)庫調優(yōu)的常見策略數(shù)據(jù)庫的性能涉及硬件、網(wǎng)絡及應用程序等多個方面。主要包括：1）系統(tǒng)硬件。系統(tǒng)硬件的性能對數(shù)據(jù)庫的表現(xiàn)至關重要，配置合理的服務器及存儲設備能夠最有效的提高整個系統(tǒng)的性能。系統(tǒng)性能主要取決于磁盤、內存、CPU和網(wǎng)絡。磁盤是最容易被忽略的薄弱環(huán)節(jié)，快速的磁盤系統(tǒng)可能節(jié)省十倍甚至百倍的時間。內存越大，則表的部分或全部保存在內存中的機會也越大，可以大大的減少磁盤I/O的次數(shù)，從而極大的提升檢索速度。SqlServer2005可以支持多達32個CPU并行工作，選擇多個高性能的CPU能提高每個任務的處理速度。網(wǎng)絡連接的快慢則決定了數(shù)據(jù)庫服務器與應用服務器之間的數(shù)據(jù)交換能力。硬件系統(tǒng)的價格比較昂貴，如果單純采用升級硬件的方式來提升性能，能夠得到很好的效果，但付出的代價較高。2）數(shù)據(jù)庫的設計。數(shù)據(jù)庫設計同樣能夠極大的影響數(shù)據(jù)庫的性能。數(shù)據(jù)庫設計方面主要考慮如下方面：表的設計、索引的設計和存儲過程的使用。數(shù)據(jù)庫表的設計一般應滿足三范式，消除冗余，避免插入、刪除和修改異常。但適當?shù)姆且?guī)范化處理可以減少頻繁連表和重復計算，和應用程序結合在一起能夠很好的降低對數(shù)據(jù)庫查詢量的需求。表的設計另一方面需考慮盡可能減少可空列，而采用默認值的方法，減少行的大小。索引的設計在提升查詢性能上至關重要，一個有效利用索引的查詢可以迅速的定位記錄，而不需要全表搜索。有效的使用存儲過程，來批量的處理數(shù)據(jù)可以很好的減少連接數(shù)據(jù)庫的次數(shù)。數(shù)據(jù)庫的設計方面的調優(yōu)一部分可以獨立進行，而不影響應用程序和現(xiàn)有系統(tǒng)，沒有額外的投資，但是有些部分則需要應用程序做出相應的調整，有些部分則會帶來負面影響，比如索引，表的索引越多，增加、刪除和修改時的速度越慢。要根據(jù)情況均衡考慮。3）應用程序的設計。主要涉及查詢語句的設計方式、鎖的類型和持續(xù)時間，能不能充分利用索引和存儲過程。除此以外還需要平衡業(yè)務的需求和整個系統(tǒng)的性能。應用程序的設計準則包括：消除過多的網(wǎng)絡流量，使用小結果集；使用存儲過程，避免死鎖等。

在線電銷系統(tǒng)數(shù)據(jù)庫問題的分析我們了解到該企業(yè)的電銷系統(tǒng)數(shù)據(jù)庫的應用程序采用多層架構，有豐富的現(xiàn)場日志，且能夠做到直接修改查詢語句而不需要重新編譯源代碼。首先分析了應用程序保留的卡死那段時間的現(xiàn)場日志。經過對日志的分析發(fā)現(xiàn)了如下問題：1）當時有很多條需要對十多張百萬級數(shù)據(jù)表的聯(lián)結查詢。其中數(shù)十條查詢時長超過1000ms。對這些查詢進一步的分析表明，sql語句中的查詢條件不能有效的利用索引，主要原因有如下幾點:a.有些字段沒有包含在索引之中。b.諸如like‘%xxx%’的模糊查詢。c.諸如in(x,x,x)的查詢。上述情況由于不能利用索引來查詢，導致全表搜索，而全表的數(shù)據(jù)量非常巨大，因此導致查詢時間很長，在并發(fā)數(shù)很大的情況下會導致系統(tǒng)響應很慢。2）某個檢查工作狀態(tài)的查詢語句每10s檢查一次。3）經常查詢的表數(shù)據(jù)量巨大，最多的通話相關的表達500萬條以上，更頻繁操作的客戶表和訂單表也達100萬條，還在持續(xù)增長之中，很多業(yè)務查詢都需要這些大表互相連接或聚合統(tǒng)計分析。其次為了了解當并發(fā)量很大,查詢集中時，整個系統(tǒng)的瓶頸在哪里，決定選擇一個正常的工作周期打開性能監(jiān)視器，了解性能瓶頸所在。我們選擇了正常工作日的一整天24小時。經過檢查發(fā)現(xiàn)磁盤I/O存在較大異常，avg.disk.queue.length的平均值都高達60~80，最大值高達700，而合理值是1~3/每塊磁盤，當前系統(tǒng)包含2塊物理磁盤，那么平均值不應該超過6。因此可以判斷磁盤I/O存在異常。從上述分析可以得出該數(shù)據(jù)庫系統(tǒng)的問題主要有：（1）歷史數(shù)據(jù)過于龐大；（2）表的索引設計存在問題；（3）查詢語句設計存在問題；（4）硬件的性能已經無法應付日益龐大的數(shù)據(jù)量和并發(fā)數(shù)。

針對性調優(yōu)策略的選取由于該企業(yè)的數(shù)據(jù)庫系統(tǒng)是始終運行之中，很多優(yōu)化措施在應用程序和數(shù)據(jù)庫的設計和開發(fā)階段是比較容易解決的問題，現(xiàn)在卻變得不可實現(xiàn)，比如對應用程序的修改，雖然該應用程序可以方便的修改查詢語句，但是對于數(shù)據(jù)的處理方式將很難修改。而且一個表會涉及到多處使用，因此數(shù)據(jù)庫設計方面的缺陷所能做的優(yōu)化也幾乎不可能。因此需要針對數(shù)據(jù)庫系統(tǒng)存在的4類問題進行分析處理。這4類問題中，其中最容易處理的是（2），因為僅需要對數(shù)據(jù)庫進行操作即可。其次為（3），需要對查詢語句進行修改，本來是比較復雜的工作，由于該企業(yè)的應用程序是多層架構，查詢語句可以方便的修改而不需要重新編譯源代碼。再然后是（1），歷史數(shù)據(jù)中有很多類型，有些是基本不會被查詢的可以移除，有些是核心數(shù)據(jù)如客戶數(shù)據(jù)和訂單數(shù)據(jù)，這些對公司的業(yè)務有著巨大的價值，不可能被轉移。對于（4）則更加麻煩，這不僅僅涉及到公司資金的投入，還涉及到如何擴展或更新硬件而不影響現(xiàn)有業(yè)務的進行，如何應對擴展或更新過程中所遇到的風險。因此我們的解決方案是：首先解決（2）、（3），然后是（1）。

經過觀察后，如有必要再考慮對硬件的升級。具體來說，采用了如下步驟：1）從日志中選出所有耗時巨大的查詢語句，逐一分析，分別處以如下操作：(1)對于經常需要進行的操作，盡可能去除模糊查詢(like和in)。如果業(yè)務需要，確實在某些情況下需要模糊查詢，則提供2個版本供選擇：可以模糊查詢和不可以模糊查詢的版本。并控制模糊查詢的使用(2)對于所有耗時巨大的且不是因為模糊查詢的語句，運用數(shù)據(jù)庫引擎優(yōu)化顧問來優(yōu)化，根據(jù)建議來重新建立表的索引，確保查詢能充分利用索引，減少查詢時間經過步驟（1）的處理后，系統(tǒng)的壓力得到了緩解，但是仍然反映很慢。2）鑒于數(shù)據(jù)量正在日新月異的增加。沉重的歷史數(shù)據(jù)始終是系統(tǒng)的包袱。因此需要向業(yè)務部門提出建議，每種數(shù)據(jù)確定需要保留的時間。并據(jù)此寫出清理數(shù)據(jù)的存儲過程，每周進行一次清理，將超過半年、一年以上的數(shù)據(jù)(根據(jù)業(yè)務的需求保留時長不等)轉移到其他備份數(shù)據(jù)庫中，并在原數(shù)據(jù)庫中清理掉。經過步驟（2）的處理之后，以及進一步的性能監(jiān)視之后，發(fā)現(xiàn)，磁盤I/O的avg.disk.queue.length的最大值仍然在200以上。雖然對比最初已經有了很好的降低，仍然遠遠超出建議的值。3）仔細分析了系統(tǒng)硬件之后發(fā)現(xiàn)，當前的數(shù)據(jù)庫文件的大小已達20G，而內存大小僅為4G，顯然如果涉及大數(shù)據(jù)量的查詢時，數(shù)據(jù)庫的大部分都在磁盤而非內存中，需要多次磁盤I/O來應對，從而導致磁盤I/O成為瓶頸所在。鑒于這樣的原因，建議升級內存到32G。升級后發(fā)現(xiàn)，磁盤I/O迅速的下降為2~4之間。坐席終端也反映系統(tǒng)使用比較流暢。整個系統(tǒng)運行多日未出現(xiàn)卡死現(xiàn)象。至此本次優(yōu)化取得了很好的效果。

經過本次數(shù)據(jù)庫系統(tǒng)系統(tǒng)終端的設計會優(yōu)化，可以發(fā)現(xiàn)聯(lián)機數(shù)據(jù)庫調優(yōu)涉及很多方面，絕不僅僅是數(shù)據(jù)庫本身的知識。還涉及業(yè)務需求、查詢語句和應用程序的架構以及硬件的性能。每個方面都對數(shù)據(jù)庫的性能有重大影響。從業(yè)務的角度，如何在有限的系統(tǒng)資源中，確保核心業(yè)務的進行；如何在業(yè)務的便利性和系統(tǒng)資源的消耗之間找到平衡。從應用程序結構的角度，不僅需要考慮實現(xiàn)用戶提出的功能，還要預見到在大數(shù)據(jù)量和高并發(fā)情況下，系統(tǒng)性能的影響。如果在設計時就考慮到這一點，就能有更多的優(yōu)化策略可以采用，比如數(shù)據(jù)的劃分，將同一種數(shù)據(jù)分在不同表中，從而縮小每個人需要查詢的總范圍，且減少讀寫鎖的爭用。

作者：翁英萍單位：南京工業(yè)職業(yè)技術學院計算機與軟件學院