溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作為DBA，有時會被挑戰類似這樣的問題：
面對諸如上面的這些質疑，DBA應該如何面對？
身為DBA該如何評估現有資源使用情況？
如果現有數據庫資源確實無法支撐，又該本著什么原則進行改造呢？
本文是針對上面問題的一些經驗總結，供大家參考。
面對這樣的問題，首先要進行評估工作，可遵循下面的步驟：
針對系統運行現狀，建立性能基線。將業務指標與性能指標建立起對應關系。這里所說的性能指標包括CPU、MEM、DISK、NET等。在諸多資源中，肯定存在不均衡的情況，短板的資源最有可能成為業務增長后的瓶頸。在具體操作上，可首先確定一個業務高峰時間段，通過監控平臺或監控工具收集系統各資源的使用情況。然后依據收集的信息，分析可能的性能短板在哪里。
對于DBA來說，對自己掌管系統的性能使用情況要了然于胸。通過對業務的了解，將業務指標映射到性能指標上，就可以很容易地推斷出現有系統可承載的最大業務量。此外，對于可能影響承載業務增長的短板，也會有比較清晰的認識。
一般來說，數據庫類的應用是重資源消耗類的應用。對CPU、MEM、DISK、NET等，均有較大的消耗。但由于不同硬件發展水平不均衡，各數據庫資源消耗特點也不同，因此需要具體問題具體分析。
下面談談我對硬件發展及與數據庫關系的一點個人觀點:
相對于其他硬件而言，CPU技術發展較快。隨著CPU主頻提高及多核CPU技術的發展，CPU提供的計算能力往往不會成為系統的性能瓶頸。但我們需要注意的是，有些數據庫是無法完全利用CPU的能力(例如MySQL就是這樣)。此時，為了充分利用CPU的資源，可以考慮諸如"多實例混跑"的方案，提高CPU利用率。
隨著內存技術的發揮，內存的價格越來越便宜。現在我們在生產環境中，可以見到128、256GB，甚至TB級的內存也不罕見。一般來說，數據庫通常會利用內存作為緩沖區，大內存的配置對數據庫的性能有著比較明顯的提升。此外，數據庫自身技術也在適應著大內存的場景，通常采用的策略是劃分子池。將管理的單位進一步細分，例如Oracle中的Sub Pool、MySQL中的多instance buffer pool。
隨著GigE、10GbE、InfiniBand技術的飛速發展，低延遲、高帶寬的服務品質給數據庫乃至整個IT系統帶來了很多變化。常見的應用領域有：
加速分布式數據庫，例如Oracle RAC。
加速大數據處理，例如提升Hadoop MapReduce處理。
存儲架構的變革，從Scale-Up向Scale-Out演變。
相對于其他硬件技術發展而言，傳統的機械式磁盤是相對而言發展最慢的，其往往也是最容易成為數據庫的性能瓶頸。隨著閃存技術的橫空出世，為存儲技術帶來的一種變革。下面我們來看看主要性能指標的對比：
從上述指標來看，使用閃存技術后，存儲能力大大提高，消除了系統最大的瓶頸。這也是為什么很多DBA都在不同場合，大力推薦使用閃存，其對于數據庫性能的提升會帶來質的飛躍。但與此同時，我們也應該注意到，傳統關系型數據庫是按照磁盤IO模型設計的，沒有考慮到閃存技術，現在屬于軟件落后于硬件的階段；相對而言，閃存技術對于非關系型模型更有優勢。
很多基于傳統設計的優化理論發生了變化，例如: 索引聚簇因子的問題。這一點是需要我們在考慮數據庫優化時，主要注意的。此外，NoSQL的性能優勢因為傳統數據庫結合閃存技術，而變得不明顯。需要在架構選擇時加以分析。
根據業務特征，建立業務壓力模型。簡單理解就是將業務模擬抽象出來，便于后面進行壓力放大測試。要做到這一步，需要對業務有著充分的了解和評估。
下面通過一個小例子說明一下:
這個表格模擬了某個類電商的業務，其包含的主要模塊及模塊中的主要操作。針對不同的操作其交易復雜度不同 （交易復雜度可理解為執行SQL語句的個數）。根據不同的讀寫情況，區分是數據讀還是數據寫。在估算了業務總量(交易量)的情況下，很容易推算出數據操作的量。通過這種方式將業務壓力模型轉化為數據壓力模型。此處的難點在于對業務邏輯的抽象能力及對模塊業務量的比例評估。
有了上述概覽的表格后，針對每一種業務操作，可細化其操作。最終將其抽象成SQL語句及對應的訪問特征。其偽代碼可描述為
可依據上述偽代碼，編制壓力測試代碼。通過一些工具調用測試代碼，產生模擬測試的壓力。例如我經常使用的oradbtest/mydbtest(原阿里樓方鑫的一個測試工具)或sysbench等，都是不錯的壓力測試工具。
建議企業根據自身情況，整理出自己的業務壓力模型。這在系統改造、升級、擴容評估、新硬件選型等多種場合都很有用處。它要比廠商提供的類似TPCC測試報告，更有意義。據我了解，很多規模較大的公司都有比較成熟的壓力模型。
要想考察現有數據庫能否承載增長后的業務壓力，最好的方式就是模擬壓力測試。觀察在近似真實的壓力下，數據庫的表現。重點觀察，數據庫的承載力變化、主要性能瓶頸等。通常可以有兩種方式，一種是從真實環境導流（并可根據需要放大流量，可利用類似TCPCOPY等工具）;一種是根據前面整理的業務壓力模型，通過壓力工具模擬壓力。前者適用于已有項目的擴容評估、系統改造評估等，后者適用于新上項目原型方案評估、性能基準測試等場景。
上述模擬壓力測試結果中，暴露出的性能瓶頸點，就是我們后面需要著重改進、優化的方向。
針對上面的評估結果，來確定后面的改進、優化方案。可遵循如下一些步驟：
根據上面的評測結果，分析性能瓶頸點。針對不同瓶頸點，可采取不同的一些策略。有時候性能測試時全流程的，對于一個復雜系統來說，要明確定位到性能瓶頸點比較困難。此時，可借助一些APM工具，量化整個訪問路徑，協助找到瓶頸。也可以類似上面的做法，做好抽象工作，只對數據庫端施加壓力，觀察數據庫行為，判讀數據庫是否為瓶頸。如判斷就是數據庫的承載能力不夠，可按照不同層次進行考慮。
在整個評估數據庫承載能力中，這一步驟是最復雜的、也是最難的一部分。要區分清楚是否是數據庫承載能力不足，還是其他組件的問題。即使明確是數據庫的問題，也要分清楚是整體or局部的問題；是單一業務功能慢，還是整體都比較慢；是偶爾會慢，還是一直都很慢等等。這些問題的界定有助于后面明確問題層次，采取不同的策略進行解決。
針對數據庫承載能力不足，我將常見出現問題進行了層次劃分，可簡單分為語句級、對象級、數據庫級、數據庫架構級、應用架構級、業務架構級。不同層次采取的方式也有所不同，下面分別描述一下。
如性能核心問題，只是某條SQL語句的問題，可有針對性地進行優化。這種方式是侵入性比較小的一種優化方式，其影響范圍也比較小。下面對比常見的語句級優化方法。說明一下，下面方法已經排除了諸如統計信息不準確等其他因素，僅從SQL語句本身優化方式考慮。
通過改寫語句，達到調整執行計劃，提高運行效率的目的。這種方式的缺點是需要研發人員修改原代碼，然后再進行部署上線的過程。此外，有些使用O/R Mapping工具產生的SQL，無法直接修改語句，也無法使用此方法。
很多種數據庫都提供了提示（Hint）的功能。通過這種方式來指定語句的執行過程。這種方式同樣需要修改源代碼，經歷部署上線的過程。此外，這種修改方式還存在適應性較差的問題。因為其指定了特有的執行過程，隨著數據規模、數據特征的變化，固化的執行過程可能不是最佳方式了。這種方式實際上是放棄了優化器可能產生的最優路徑。
在Oracle中還內置了一些功能，它們可以固化某一條語句的執行方式，從本質上來講，其原理和上面使用Hint差不多。其缺點也類似上面。
有時也可通過調整某些參數，進而改變語句的執行計劃。但是這種方式要注意適用范圍，不要在全局使用，避免影響較多的語句。在會話級使用也要控制范圍，避免產生較大影響。
如性能核心問題，在SQL層面無法解決，需要考慮對象層面的調整。這種情況要比較慎重，需要充分評估可能帶來的風險及收益。一個對象的結構修改，可以涉及到數百條、甚至數千條和此相關語句的執行計劃變更。如不做充分測試的情況下，很難保證不出問題。如果是Oracle數據庫，可考慮使用SPA評估一下。其他數據庫的話，可提前手工收集一下相關語句，模擬修改后重放上述語句，評估性能變化。
1）影響因素
在對象級進行調整，除了考慮對其他語句的性能影響外，還需要考慮其他因素。常見的以下這些：
常見的例如索引。通過添加索引，往往可以起到加速查詢的目的；但是增加索引，會導致數據DML成本的增加。
常見的例如全局分區索引。全局分區索引在進行分區維護動作后，會導致索引失效，需要自動或手動進行維護索引動作。
常見的索引，索引結構是數據庫中真實占據空間的結構。在以往的一些案例中，甚至出現過索引總大小超過表大小的情況，因此新增時要評估其空間使用。
2）全生命周期管理
這里還有另外一個很重要的概念——“對象全生命周期管理”，簡單來說就是對象的生老病死。在很多系統中，對象從新建開始，數據不斷增加、膨脹，當數據規模達到一定量級后，各種性能問題就出現了。對一個百萬級的表和億萬級的表，其查詢性能肯定不能同日而語。因此，在對象設計初期，就要考慮相關的歸檔、清理、轉儲、壓縮策略，將存儲空間的評估與生命周期管理一起考慮。
很多性能問題，在做了數據清理后都迎刃而解。但數據清理往往是需要代價的，必須在設計之初就考慮這個問題。在做數據庫評審的時候，除了常規的結構評審、語句評審外，也要考慮這部分因素。
到了這個層面，問題往往已經比較嚴重了。一般情況下，數據庫的初始配置都是基于其上面運行系統的負載類型進行專門配置的。如果運行一段時間后，出現性能問題，經評估是屬于全局性問題的，可以考慮進行數據庫級別的調整。但是這種配置往往代價也比較大，例如需要專門的停機窗口操作等。而且這種操作的風險性也比較大，有可能會帶來很多不確定因素，因此要慎而又慎。
如性能核心問題，無法在上述層面解決，可能就需要調整數據庫架構。常見的例如采取讀寫分離的訪問方式、分庫分表存儲方式等。這種對應用的侵入性很強了，有些情況下甚至不亞于重構整個系統。
例如，隨著業務的發展，系統的數據量或訪問量超出了預期，通過單一數據庫無法滿足空間或性能要求。此時，可能就需要考慮采用一種分庫分表策略，來滿足這部分的需求。但其改造難度，往往比重新開發一套系統還要大。
比如，我們可能需要一個數據中間層，來屏蔽后面的分庫分表細節。這個中間層可能需要完成語句解析、訪問路由、數據聚合、事務處理等一系列功能。即使使用了中間層產品，對于應用來說，數據庫的功能也會相對“弱化”，應用級代碼不得不進行很多的調整來適應這種變化。此外，如何把一個線上正在運行的系統，順利平穩地遷移到新的結構下，這無疑又是一個給飛馳的跑車換輪胎的問題等等。
如果項目在運行中，出現了數據庫架構級的調整，很有可能說明在前期項目設計規劃階段出現了失誤，或者對項目的業務預期出現了偏差。因此，這兩點一定在初始階段進行充分的評估，并在設計上保留有充分的“彈性”。
有些情況下，單純依靠數據庫是無法解決的，需要綜合考慮整個應用架構。在整個系統架構中，數據庫往往處于系統的最末端，其擴展性是最差的。因此，在應用架構設計初期，就應該本著盡量不要對數據庫產生壓力的原則進行設計。或者即使有大的壓力，系統可以采取自動降級等方式保證數據庫的平穩運行。
常見的例如增加緩存、通過MQ實現削峰填谷等。通過增加緩存，可以大幅度減少對數據庫的訪問壓力，提高整體系統的吞吐能力。引入MQ，則可以將對數據庫的壓力以“穩態”的形式，向數據庫持續施壓，而不至于被某個異常高峰壓死。
最后一種情況是從業務角度進行一些調整。這往往是一種妥協，通過做適當的減法保證系統的整體運行。甚至不排除犧牲一部分用戶體驗等方式，來滿足大部分用戶的可用性。這就需要我們的架構師對系統能提供的能力要很清楚，對業務也要有充分的了解。對于承載什么樣的業務，及為了承載業務所需要花費的代價成本有充分的認知，才可以做出一些取舍。
這里要避免一些誤區，認為技術是“萬能”的。技術可以解決一定的問題，但不能解決所有問題，或者解決所有問題的成本代價是難以接受的。這個時候，從業務角度稍作調整，就可以達到“退一步海闊天空”的結果。
拓展閱讀：自制小工具大大加速MySQL SQL語句優化(附源碼)
全面解析Oracle等待事件的分類、發現及優化
循序漸進解讀Oracle AWR性能分析報告
SQL優化：一篇文章說清楚Oracle Hint的正確使用姿勢
性能優化利器：數據庫審核平臺Themis的選型與實踐
作者：韓鋒
來源：宜信技術學院
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
