本篇為大家分享GaussDB效能調優的實踐。主要包括三個部分，分別是效能調優的整體介紹，效能調優的關鍵技術，效能調優的應用實踐。
GaussDB效能調優簡介
我們知道資料庫作為系統軟體，在整個計算機體系中起到關鍵的承上啟下作用。可以看到應用程式透過北向介面與資料庫進行互動，資料庫透過南向介面與作業系統和硬體進行互動。對於資料庫系統的效能影響是多方面的，不管是硬體規格、作業系統配置、資料庫系統的設計、應用和客戶端的連線方式，都會對業務最終的效能表現產生很大的影響，所以資料庫的效能表現本質上是整體計算機系統軟硬體協調的結果。
資料庫效能最佳化充滿複雜性和挑戰性，既有主觀的成分，也有複雜的一面。效能問題的主觀性，舉例來說，某個查詢消耗是1s，它的效能是好還是壞，是否脫離業務目標很難講清楚。所以描述效能問題時要目標清晰、描述具體、結果可度量。例如一個問題出現後，需要給出硬體配置、引數資訊、部署形態、業務場景、當前結果、期望目標等資訊。另一個面臨的效能問題是複雜性，透過一個問題表象，很難一眼判斷是哪個模組引起的，需要分析出一個明確的方向，進一步觀察作業在不同模組間資料流動，用全域性視角來分析問題；如果效能問題不是單點的問題，我們需要從中找到引起問題的主要矛盾，然後先解決掉大頭，看看是否滿足業務訴求。
在遇到資料庫效能相關問題時，經常會出現一些行業術語。比如：IOPS通常指資料庫系統資料盤每秒讀寫IO的次數，反映了磁碟IO的讀寫能力；吞吐量，往往指的是資料庫每秒處理事務數TPS或者查詢數QPS，反映整體的負載狀況；響應時間，指的是資料庫中一條查詢從發起到結果返回的時間開銷，用來識別慢SQL；飽和度，指大併發場景下屬於工作佇列的任務數，反映當前系統作業被積壓的情況，以及忙閒程度。
GaussDB資料庫的邏輯架構
分析GaussDB效能問題前，先簡單介紹一下其邏輯架構，主要包括以下元件：
GaussDB資料庫的查詢處理流程
瞭解GaussDB架構後，我們簡單梳理一下查詢處理流程，拆解到每個模組，展開一下每個模組的功能和效能關注點。
GaussDB效能調優關鍵技術
下面介紹一下GaussDB在效能最佳化方面的幾個關鍵技術。
- 計劃快取
計劃快取技術，一般在OLTP的業務負載中，因為涉及的資料量較少，透過索引加速資料訪問路徑後，查詢解析、重寫、最佳化佔比就很高。對於模板行的語句，可以將模板語句的計劃快取起來，那麼同模板不同引數語句執行時，可以直接使用快取計劃，大大提升併發吞吐量。我們設想一下，快取計劃是針對一個session，還是針對整個系統的，由此引申出兩個概念，local plan cache和global plan cache。如果只在session上快取已執行計劃，可能會導致每個session上執行計劃都很多，佔用記憶體資源較高，GPC可以很好解決記憶體佔用問題，但維護代價較大，管理成本高。還有一個問題是，快取計劃可能針對某一類SQL，如果引數變化後，執行計劃不優怎麼辦。GaussDB實現了計劃自適應選擇的能力，可以自動為不同引數配置最佳的快取計劃。
- 智慧基數估計
智慧基數估計主要解決兩個問題：一是什麼時候建立多列統計資訊？二是建立什麼型別的統計模型？當前常見的方案是採用MCV（一種軟體架構模式）和直方圖的統計模型來實現。但這兩個方案在單列場景估計的比較準確，在多列場景中僅支援單表，而且誤差較大，無法應用。GaussDB創新性地設計出基於庫內輕量級貝葉斯網路運算元模型來實現多列場景下的基數估計；基於DB4AI的輕量級運算元，在資料庫內完成訓練和推理，對核心幾乎無影響；在自動analyze收集統計資訊時，自動建立貝葉斯網路模型；最佳化器在進行多列基數估計時，呼叫訓練好的模型，給出準確率的數值。
- 分散式查詢執行
GaussDB分散式資料庫在查詢執行過程中，採用多種技術提升查詢執行的效能。其中分散式執行框架用於實現分散式叢集的多節點並行處理能力，提升叢集整體的效能。在複雜語句查詢時，會將重執行運算元下推到DN節點執行，例如AGG運算元等。在下推運算元執行時，會考慮資料本地性，儘可能在本地計算，減少資料在網路中的傳輸開銷，從而提升資料庫整體的查詢效能。在單節點內，透過SMP並行技術，利用多核CPU的並行加速，結合記憶體管控，提升單節點的效能。
4. GTM Lite
GTM負責全域性事務的一致性。傳統的GTM元件需要維護每一個活躍事務資訊，作業執行時，需要從GTM獲取快照時，拿到的是當前的活躍事務連結串列，如果量特別大，將對網路併發帶來壓力。GaussDB實現GTM lite能力，透過CSN號代替事務連結串列，獲取的快照僅為CSN號，在事務提交時，也只需要原子加CSN號。在可見性判斷時，基於CSN號進行，如果事物結束的CSN比快照中CSN值小，那麼元組可見，否則元組不可見。
5. 日誌並行流水線
資料庫日誌系統非常關鍵，是資料持久化的關鍵保證。因為日誌有順序依賴關係，所以傳統資料庫一般採用序列刷日誌的設計。GaussDB採用log writer日誌寫盤執行緒並行寫機制，充分發揮多通道IO的能力。GaussDB日誌並行流水線主要機制是將一把大鎖，拆分為多個並行的小鎖，部分worker執行緒的事務日誌寫到一個事務日誌共享緩衝區，每個事務結束前保證對應的事務日誌LSN已經刷盤，有全域性LSN原子加保證順序。
6. NUMA Aware
GaussDB在多核ARM架構下，透過NUMA Aware技術解決跨NUMA記憶體訪問延遲問題。我們主要做了以下動作：全域性資料結構NUMA化改造，關鍵資料結構包括CLOG、Wal insertlock、proc array等，降低了資料訪問延遲；將核心工作執行緒與NUMA Node進行繫結，避免跨NUMA排程；利用原子操作指令集LSE，提升計算效能。
GaussDB效能調優應用實踐
最後介紹效能調優的應用實踐。先看看效能調優的思路，遇到效能問題，先確定效能調優的範圍，觀察是否是某個系統資源達到瓶頸，或者是否存在SQL阻塞或慢SQL。如果是系統資源類問題，透過系統調優來進行診斷和最佳化；如果是SQL層面問題，透過SQL調優進行診斷和最佳化，最終看最佳化後效果是否滿足業務需求，如果一次最佳化不能達成預期，則需要多輪迭代，最終達成目標。
資料庫系統整體效能問題的定位思路，先判斷是資料庫層面問題還是其他層面問題，其他層面問題是否是節點上其他程序引起的資料庫效能下降，或者是作業系統引數配置不當引起的。若是資料庫層面問題，需要對資料庫佔用的系統資源資訊、資料庫核心資源、主備狀況等進行綜合分析，最後確認問題根因。
在分析單條SQL語句效能時，可以透過使用檢視statement_history或者statement，查詢語句每個階段執行的時間消耗，確定語句執行的效能瓶頸。statement_history記錄了執行時間超過閾值(log_min_duration_statement，預設3 s)的詳細SQL資訊，包含計劃生成時間、執行時間、鎖等待時間等資訊；statement記錄了SQL按照unique_sql_id歸一化的執行資訊，包括執行次數、總的執行時間、訪問資料量、記憶體使用等資訊。然後透過等待事件檢視，查詢阻塞會話和物件；最後透過執行計劃，獲取更細粒度的運算元執行情況，如是否走索引、走正確的索引、分散式執行運算元stream是否涉及廣播等。
講到GaussDB全量SQL和慢SQL，他們包含哪些內容。GaussDB的多維度指標監控採集粒度不同，對系統效能的影響也不同，主要分為三個級別進行採集。
下面介紹兩個案例。第一個是應用升級後引起了效能劇烈波動，我們先觀察一下例項整體執行的時間，看看在哪一步消耗的比重最高，透過歸一化檢視觀察單個SQL，看每一步的執行消耗，發現是在網路傳送部分引起的，我們把應用側進行替換，應用程式更新後這個問題就解決了。
第二個是叢集整體效能劣化。我們先觀察CN上執行緒等待狀態，發現有些節點等待次數超高；在異常節點上分析等待事件，發現wal sync等待的時間較高，透過對比正常節點，確認該節點上存在wal sync的問題；最後分析出主備間日誌LSN分片差異較大，一直在進行回放，影響系統整體效能。
最後介紹一下GaussDB兩個自調優利器，分別是索引推薦和分佈鍵推薦，主要用於提供高效推薦。比如索引推薦，可以幫助使用者根據業務負載自動推薦合適的索引組合，識別冗餘索引和無效索引；在推薦索引時，同時輸出正向提升SQL資訊和負向提升SQL資訊，幫助使用者來決策是否使用推薦的索引。
本篇分享就到這裡，謝謝大家。
https://support.huaweicloud.com/intl/zh-cn/gaussdb/index.html