解DBA之惑：數(shù)據(jù)庫承載能力評估及優(yōu)化手段-創(chuàng)新互聯(lián)

作為DBA，有時會被挑戰(zhàn)類似這樣的問題：

創(chuàng)新互聯(lián)長期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為南岔企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站制作，南岔網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

• 如果現(xiàn)有業(yè)務(wù)規(guī)模增加10倍、100倍，數(shù)據(jù)庫是否能夠支撐？
• 下個月我們搞大促，數(shù)據(jù)庫這邊沒問題吧？
• 計劃進行去O工作，代碼邏輯不變，數(shù)據(jù)庫從Oracle切換到MySQL，MySQL能支撐業(yè)務(wù)嗎？
• 服務(wù)器采購選型，到底哪款服務(wù)器更適合我們呢？

面對諸如上面的這些質(zhì)疑，DBA應(yīng)該如何面對？

身為DBA該如何評估現(xiàn)有資源使用情況？

如果現(xiàn)有數(shù)據(jù)庫資源確實無法支撐，又該本著什么原則進行改造呢？

本文是針對上面問題的一些經(jīng)驗總結(jié)，供大家參考。

一、評估工作

面對這樣的問題，首先要進行評估工作，可遵循下面的步驟：

1、建立性能基線

針對系統(tǒng)運行現(xiàn)狀，建立性能基線。將業(yè)務(wù)指標(biāo)與性能指標(biāo)建立起對應(yīng)關(guān)系。這里所說的性能指標(biāo)包括CPU、MEM、DISK、NET等。在諸多資源中，肯定存在不均衡的情況，短板的資源最有可能成為業(yè)務(wù)增長后的瓶頸。在具體操作上，可首先確定一個業(yè)務(wù)高峰時間段，通過監(jiān)控平臺或監(jiān)控工具收集系統(tǒng)各資源的使用情況。然后依據(jù)收集的信息，分析可能的性能短板在哪里。

對于DBA來說，對自己掌管系統(tǒng)的性能使用情況要了然于胸。通過對業(yè)務(wù)的了解，將業(yè)務(wù)指標(biāo)映射到性能指標(biāo)上，就可以很容易地推斷出現(xiàn)有系統(tǒng)可承載的大業(yè)務(wù)量。此外，對于可能影響承載業(yè)務(wù)增長的短板，也會有比較清晰的認(rèn)識。

一般來說，數(shù)據(jù)庫類的應(yīng)用是重資源消耗類的應(yīng)用。對CPU、MEM、DISK、NET等，均有較大的消耗。但由于不同硬件發(fā)展水平不均衡，各數(shù)據(jù)庫資源消耗特點也不同，因此需要具體問題具體分析。

下面談?wù)勎覍τ布l(fā)展及與數(shù)據(jù)庫關(guān)系的一點個人觀點:

• CPU

相對于其他硬件而言，CPU技術(shù)發(fā)展較快。隨著CPU主頻提高及多核CPU技術(shù)的發(fā)展，CPU提供的計算能力往往不會成為系統(tǒng)的性能瓶頸。但我們需要注意的是，有些數(shù)據(jù)庫是無法完全利用CPU的能力(例如MySQL就是這樣)。此時，為了充分利用CPU的資源，可以考慮諸如"多實例混跑"的方案，提高CPU利用率。

• MEM

隨著內(nèi)存技術(shù)的發(fā)揮，內(nèi)存的價格越來越便宜。現(xiàn)在我們在生產(chǎn)環(huán)境中，可以見到128、256GB，甚至TB級的內(nèi)存也不罕見。一般來說，數(shù)據(jù)庫通常會利用內(nèi)存作為緩沖區(qū)，大內(nèi)存的配置對數(shù)據(jù)庫的性能有著比較明顯的提升。此外，數(shù)據(jù)庫自身技術(shù)也在適應(yīng)著大內(nèi)存的場景，通常采用的策略是劃分子池。將管理的單位進一步細分，例如Oracle中的Sub Pool、MySQL中的多instance buffer pool。

• NET

隨著GigE、10GbE、InfiniBand技術(shù)的飛速發(fā)展，低延遲、高帶寬的服務(wù)品質(zhì)給數(shù)據(jù)庫乃至整個IT系統(tǒng)帶來了很多變化。常見的應(yīng)用領(lǐng)域有：

• 加速分布式數(shù)據(jù)庫，例如Oracle RAC。

• 加速大數(shù)據(jù)處理，例如提升Hadoop MapReduce處理。

• 存儲架構(gòu)的變革，從Scale-Up向Scale-Out演變。

• 容災(zāi)方案，主備策略…

• DISK

相對于其他硬件技術(shù)發(fā)展而言，傳統(tǒng)的機械式磁盤是相對而言發(fā)展最慢的，其往往也是最容易成為數(shù)據(jù)庫的性能瓶頸。隨著閃存技術(shù)的橫空出世，為存儲技術(shù)帶來的一種變革。下面我們來看看主要性能指標(biāo)的對比：

從上述指標(biāo)來看，使用閃存技術(shù)后，存儲能力大大提高，消除了系統(tǒng)大的瓶頸。這也是為什么很多DBA都在不同場合，大力推薦使用閃存，其對于數(shù)據(jù)庫性能的提升會帶來質(zhì)的飛躍。但與此同時，我們也應(yīng)該注意到，傳統(tǒng)關(guān)系型數(shù)據(jù)庫是按照磁盤IO模型設(shè)計的，沒有考慮到閃存技術(shù)，現(xiàn)在屬于軟件落后于硬件的階段；相對而言，閃存技術(shù)對于非關(guān)系型模型更有優(yōu)勢。

很多基于傳統(tǒng)設(shè)計的優(yōu)化理論發(fā)生了變化，例如: 索引聚簇因子的問題。這一點是需要我們在考慮數(shù)據(jù)庫優(yōu)化時，主要注意的。此外，NoSQL的性能優(yōu)勢因為傳統(tǒng)數(shù)據(jù)庫結(jié)合閃存技術(shù)，而變得不明顯。需要在架構(gòu)選擇時加以分析。

2、建立業(yè)務(wù)壓力模型

根據(jù)業(yè)務(wù)特征，建立業(yè)務(wù)壓力模型。簡單理解就是將業(yè)務(wù)模擬抽象出來，便于后面進行壓力放大測試。要做到這一步，需要對業(yè)務(wù)有著充分的了解和評估。

下面通過一個小例子說明一下:

這個表格模擬了某個類電商的業(yè)務(wù)，其包含的主要模塊及模塊中的主要操作。針對不同的操作其交易復(fù)雜度不同 （交易復(fù)雜度可理解為執(zhí)行SQL語句的個數(shù)）。根據(jù)不同的讀寫情況，區(qū)分是數(shù)據(jù)讀還是數(shù)據(jù)寫。在估算了業(yè)務(wù)總量(交易量)的情況下，很容易推算出數(shù)據(jù)操作的量。通過這種方式將業(yè)務(wù)壓力模型轉(zhuǎn)化為數(shù)據(jù)壓力模型。此處的難點在于對業(yè)務(wù)邏輯的抽象能力及對模塊業(yè)務(wù)量的比例評估。

有了上述概覽的表格后，針對每一種業(yè)務(wù)操作，可細化其操作。最終將其抽象成SQL語句及對應(yīng)的訪問特征。其偽代碼可描述為

可依據(jù)上述偽代碼，編制壓力測試代碼。通過一些工具調(diào)用測試代碼，產(chǎn)生模擬測試的壓力。例如我經(jīng)常使用的oradbtest/mydbtest(原阿里樓方鑫的一個測試工具)或sysbench等，都是不錯的壓力測試工具。

建議企業(yè)根據(jù)自身情況，整理出自己的業(yè)務(wù)壓力模型。這在系統(tǒng)改造、升級、擴容評估、新硬件選型等多種場合都很有用處。它要比廠商提供的類似TPCC測試報告，更有意義。據(jù)我了解，很多規(guī)模較大的公司都有比較成熟的壓力模型。

3、模擬壓力測試

要想考察現(xiàn)有數(shù)據(jù)庫能否承載增長后的業(yè)務(wù)壓力，最好的方式就是模擬壓力測試。觀察在近似真實的壓力下，數(shù)據(jù)庫的表現(xiàn)。重點觀察，數(shù)據(jù)庫的承載力變化、主要性能瓶頸等。通?？梢杂袃煞N方式，一種是從真實環(huán)境導(dǎo)流（并可根據(jù)需要放大流量，可利用類似TCPCOPY等工具）;一種是根據(jù)前面整理的業(yè)務(wù)壓力模型，通過壓力工具模擬壓力。前者適用于已有項目的擴容評估、系統(tǒng)改造評估等，后者適用于新上項目原型方案評估、性能基準(zhǔn)測試等場景。

上述模擬壓力測試結(jié)果中，暴露出的性能瓶頸點，就是我們后面需要著重改進、優(yōu)化的方向。

二、優(yōu)化層次及步驟

針對上面的評估結(jié)果，來確定后面的改進、優(yōu)化方案。可遵循如下一些步驟：

1、分析瓶頸點

根據(jù)上面的評測結(jié)果，分析性能瓶頸點。針對不同瓶頸點，可采取不同的一些策略。有時候性能測試時全流程的，對于一個復(fù)雜系統(tǒng)來說，要明確定位到性能瓶頸點比較困難。此時，可借助一些APM工具，量化整個訪問路徑，協(xié)助找到瓶頸。也可以類似上面的做法，做好抽象工作，只對數(shù)據(jù)庫端施加壓力，觀察數(shù)據(jù)庫行為，判讀數(shù)據(jù)庫是否為瓶頸。如判斷就是數(shù)據(jù)庫的承載能力不夠，可按照不同層次進行考慮。

在整個評估數(shù)據(jù)庫承載能力中，這一步驟是最復(fù)雜的、也是最難的一部分。要區(qū)分清楚是否是數(shù)據(jù)庫承載能力不足，還是其他組件的問題。即使明確是數(shù)據(jù)庫的問題，也要分清楚是整體or局部的問題；是單一業(yè)務(wù)功能慢，還是整體都比較慢；是偶爾會慢，還是一直都很慢等等。這些問題的界定有助于后面明確問題層次，采取不同的策略進行解決。

針對數(shù)據(jù)庫承載能力不足，我將常見出現(xiàn)問題進行了層次劃分，可簡單分為語句級、對象級、數(shù)據(jù)庫級、數(shù)據(jù)庫架構(gòu)級、應(yīng)用架構(gòu)級、業(yè)務(wù)架構(gòu)級。不同層次采取的方式也有所不同，下面分別描述一下。

2、層次-語句級

如性能核心問題，只是某條SQL語句的問題，可有針對性地進行優(yōu)化。這種方式是侵入性比較小的一種優(yōu)化方式，其影響范圍也比較小。下面對比常見的語句級優(yōu)化方法。說明一下，下面方法已經(jīng)排除了諸如統(tǒng)計信息不準(zhǔn)確等其他因素，僅從SQL語句本身優(yōu)化方式考慮。

• 改寫SQL

通過改寫語句，達到調(diào)整執(zhí)行計劃，提高運行效率的目的。這種方式的缺點是需要研發(fā)人員修改原代碼，然后再進行部署上線的過程。此外，有些使用O/R Mapping工具產(chǎn)生的SQL，無法直接修改語句，也無法使用此方法。

• 使用Hint

很多種數(shù)據(jù)庫都提供了提示（Hint）的功能。通過這種方式來指定語句的執(zhí)行過程。這種方式同樣需要修改源代碼，經(jīng)歷部署上線的過程。此外，這種修改方式還存在適應(yīng)性較差的問題。因為其指定了特有的執(zhí)行過程，隨著數(shù)據(jù)規(guī)模、數(shù)據(jù)特征的變化，固化的執(zhí)行過程可能不是最佳方式了。這種方式實際上是放棄了優(yōu)化器可能產(chǎn)生的最優(yōu)路徑。

• 存儲概要、SQL概要、計劃基線

在Oracle中還內(nèi)置了一些功能，它們可以固化某一條語句的執(zhí)行方式，從本質(zhì)上來講，其原理和上面使用Hint差不多。其缺點也類似上面。

• 調(diào)整參數(shù)

有時也可通過調(diào)整某些參數(shù)，進而改變語句的執(zhí)行計劃。但是這種方式要注意適用范圍，不要在全局使用，避免影響較多的語句。在會話級使用也要控制范圍，避免產(chǎn)生較大影響。

3、層次-對象級

如性能核心問題，在SQL層面無法解決，需要考慮對象層面的調(diào)整。這種情況要比較慎重，需要充分評估可能帶來的風(fēng)險及收益。一個對象的結(jié)構(gòu)修改，可以涉及到數(shù)百條、甚至數(shù)千條和此相關(guān)語句的執(zhí)行計劃變更。如不做充分測試的情況下，很難保證不出問題。如果是Oracle數(shù)據(jù)庫，可考慮使用SPA評估一下。其他數(shù)據(jù)庫的話，可提前手工收集一下相關(guān)語句，模擬修改后重放上述語句，評估性能變化。

1）影響因素

在對象級進行調(diào)整，除了考慮對其他語句的性能影響外，還需要考慮其他因素。常見的以下這些：

• 數(shù)據(jù)庫維護成本

常見的例如索引。通過添加索引，往往可以起到加速查詢的目的；但是增加索引，會導(dǎo)致數(shù)據(jù)DML成本的增加。

• 運維成本

常見的例如全局分區(qū)索引。全局分區(qū)索引在進行分區(qū)維護動作后，會導(dǎo)致索引失效，需要自動或手動進行維護索引動作。

• 存儲成本

常見的索引，索引結(jié)構(gòu)是數(shù)據(jù)庫中真實占據(jù)空間的結(jié)構(gòu)。在以往的一些案例中，甚至出現(xiàn)過索引總大小超過表大小的情況，因此新增時要評估其空間使用。

2）全生命周期管理

這里還有另外一個很重要的概念——“對象全生命周期管理”，簡單來說就是對象的生老病死。在很多系統(tǒng)中，對象從新建開始，數(shù)據(jù)不斷增加、膨脹，當(dāng)數(shù)據(jù)規(guī)模達到一定量級后，各種性能問題就出現(xiàn)了。對一個百萬級的表和億萬級的表，其查詢性能肯定不能同日而語。因此，在對象設(shè)計初期，就要考慮相關(guān)的歸檔、清理、轉(zhuǎn)儲、壓縮策略，將存儲空間的評估與生命周期管理一起考慮。

很多性能問題，在做了數(shù)據(jù)清理后都迎刃而解。但數(shù)據(jù)清理往往是需要代價的，必須在設(shè)計之初就考慮這個問題。在做數(shù)據(jù)庫評審的時候，除了常規(guī)的結(jié)構(gòu)評審、語句評審?fù)?，也要考慮這部分因素。

4、層次-數(shù)據(jù)庫級

到了這個層面，問題往往已經(jīng)比較嚴(yán)重了。一般情況下，數(shù)據(jù)庫的初始配置都是基于其上面運行系統(tǒng)的負載類型進行專門配置的。如果運行一段時間后，出現(xiàn)性能問題，經(jīng)評估是屬于全局性問題的，可以考慮進行數(shù)據(jù)庫級別的調(diào)整。但是這種配置往往代價也比較大，例如需要專門的停機窗口操作等。而且這種操作的風(fēng)險性也比較大，有可能會帶來很多不確定因素，因此要慎而又慎。

5、層次-數(shù)據(jù)庫架構(gòu)級

如性能核心問題，無法在上述層面解決，可能就需要調(diào)整數(shù)據(jù)庫架構(gòu)。常見的例如采取讀寫分離的訪問方式、分庫分表存儲方式等。這種對應(yīng)用的侵入性很強了，有些情況下甚至不亞于重構(gòu)整個系統(tǒng)。

例如，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)的數(shù)據(jù)量或訪問量超出了預(yù)期，通過單一數(shù)據(jù)庫無法滿足空間或性能要求。此時，可能就需要考慮采用一種分庫分表策略，來滿足這部分的需求。但其改造難度，往往比重新開發(fā)一套系統(tǒng)還要大。

比如，我們可能需要一個數(shù)據(jù)中間層，來屏蔽后面的分庫分表細節(jié)。這個中間層可能需要完成語句解析、訪問路由、數(shù)據(jù)聚合、事務(wù)處理等一系列功能。即使使用了中間層產(chǎn)品，對于應(yīng)用來說，數(shù)據(jù)庫的功能也會相對“弱化”，應(yīng)用級代碼不得不進行很多的調(diào)整來適應(yīng)這種變化。此外，如何把一個線上正在運行的系統(tǒng)，順利平穩(wěn)地遷移到新的結(jié)構(gòu)下，這無疑又是一個給飛馳的跑車換輪胎的問題等等。

如果項目在運行中，出現(xiàn)了數(shù)據(jù)庫架構(gòu)級的調(diào)整，很有可能說明在前期項目設(shè)計規(guī)劃階段出現(xiàn)了失誤，或者對項目的業(yè)務(wù)預(yù)期出現(xiàn)了偏差。因此，這兩點一定在初始階段進行充分的評估，并在設(shè)計上保留有充分的“彈性”。

6、層次-應(yīng)用架構(gòu)級

有些情況下，單純依靠數(shù)據(jù)庫是無法解決的，需要綜合考慮整個應(yīng)用架構(gòu)。在整個系統(tǒng)架構(gòu)中，數(shù)據(jù)庫往往處于系統(tǒng)的最末端，其擴展性是最差的。因此，在應(yīng)用架構(gòu)設(shè)計初期，就應(yīng)該本著盡量不要對數(shù)據(jù)庫產(chǎn)生壓力的原則進行設(shè)計?；蛘呒词褂写蟮膲毫Γ到y(tǒng)可以采取自動降級等方式保證數(shù)據(jù)庫的平穩(wěn)運行。

常見的例如增加緩存、通過MQ實現(xiàn)削峰填谷等。通過增加緩存，可以大幅度減少對數(shù)據(jù)庫的訪問壓力，提高整體系統(tǒng)的吞吐能力。引入MQ，則可以將對數(shù)據(jù)庫的壓力以“穩(wěn)態(tài)”的形式，向數(shù)據(jù)庫持續(xù)施壓，而不至于被某個異常高峰壓死。

7、層次-業(yè)務(wù)架構(gòu)級

最后一種情況是從業(yè)務(wù)角度進行一些調(diào)整。這往往是一種妥協(xié)，通過做適當(dāng)?shù)臏p法保證系統(tǒng)的整體運行。甚至不排除犧牲一部分用戶體驗等方式，來滿足大部分用戶的可用性。這就需要我們的架構(gòu)師對系統(tǒng)能提供的能力要很清楚，對業(yè)務(wù)也要有充分的了解。對于承載什么樣的業(yè)務(wù)，及為了承載業(yè)務(wù)所需要花費的代價成本有充分的認(rèn)知，才可以做出一些取舍。

這里要避免一些誤區(qū)，認(rèn)為技術(shù)是“萬能”的。技術(shù)可以解決一定的問題，但不能解決所有問題，或者解決所有問題的成本代價是難以接受的。這個時候，從業(yè)務(wù)角度稍作調(diào)整，就可以達到“退一步海闊天空”的結(jié)果。

拓展閱讀：自制小工具大大加速MySQL SQL語句優(yōu)化(附源碼)

全面解析Oracle等待事件的分類、發(fā)現(xiàn)及優(yōu)化

循序漸進解讀Oracle AWR性能分析報告

SQL優(yōu)化：一篇文章說清楚Oracle Hint的正確使用姿勢

性能優(yōu)化利器：數(shù)據(jù)庫審核平臺Themis的選型與實踐

作者：韓鋒

來源：宜信技術(shù)學(xué)院

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：解DBA之惑：數(shù)據(jù)庫承載能力評估及優(yōu)化手段-創(chuàng)新互聯(lián)
文章地址：http://bm7419.com/article14/cedhde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、商城網(wǎng)站、動態(tài)網(wǎng)站、用戶體驗、搜索引擎優(yōu)化、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)