解DBA之惑：數(shù)據(jù)庫承載能力評估及優(yōu)化手段

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

如果現(xiàn)有業(yè)務規(guī)模增加10倍、100倍，數(shù)據(jù)庫是否能夠支撐？

下個月我們搞大促，數(shù)據(jù)庫這邊沒問題吧？

計劃進行去O工作，代碼邏輯不變，數(shù)據(jù)庫從Oracle切換到MySQL，MySQL能支撐業(yè)務嗎？

服務器采購選型，到底哪款服務器更適合我們呢？

面對諸如上面的這些質疑，DBA應該如何面對？

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

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

本文是針對上面問題的一些經驗總結，供大家參考。

一、評估工作

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

1、建立性能基線

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

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

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

下面談談我對硬件發(fā)展及與數(shù)據(jù)庫關系的一點個人觀點:

CPU

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

MEM

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

NET

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

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

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

存儲架構的變革，從Scale-Up向Scale-Out演變。

容災方案，主備策略…

DISK

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

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

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

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

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

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

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

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

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

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

3、模擬壓力測試

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

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

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

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

1、分析瓶頸點

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

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

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

2、層次-語句級

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

改寫SQL

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

使用Hint

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

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

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

調整參數(shù)

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

3、層次-對象級

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

1）影響因素

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

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

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

運維成本

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

存儲成本

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

2）全生命周期管理

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

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

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

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

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

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

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

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

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

6、層次-應用架構級

有些情況下，單純依靠數(shù)據(jù)庫是無法解決的，需要綜合考慮整個應用架構。在整個系統(tǒng)架構中，數(shù)據(jù)庫往往處于系統(tǒng)的最末端，其擴展性是最差的。因此，在應用架構設計初期，就應該本著盡量不要對數(shù)據(jù)庫產生壓力的原則進行設計?；蛘呒词褂写蟮膲毫Γ到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è)務架構級

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

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

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

來源：宜信技術學院

本文轉載自異步社區(qū)。

數(shù)據(jù)庫 SQL

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。