宜信技術：經過自研數據庫畫像工具，支持「去O」評估

「去O」，是近些年來一直很火的一個話題，隨之也產生了各類疑惑，包括現有數據庫評估、技術選型等。去O是項系統工程，須要作好充分的評估。本文經過自研工具，生成數據庫畫像，爲去O評估提供一手數據，但願給你們帶來借鑑。

1、常見疑惑

不少公司在考慮去O的時候，常常面臨這樣的問題—"對本身的數據庫不夠了解"，也難免有這樣一些疑惑：

[管理者]

• 數據庫去O成本高嘛？
• 工做量大不大？
• 工期長嗎？
• 是否存在什麼風險？

[架構師]

• 使用MySQL能承載現有業務規模嘛？
• 是否有什麼技術風險？
• 是否須要引入分庫分表嘛？
• 是否須要引入緩存嘛？
• 研發複雜度高嘛？
• 須要投入多大工期？
• 數據訪問特徵如何？
• 遷移先後對比數據量大嗎？

[開發者]

• 複雜SQL多嘛？
• 改造量是否是很大？
• 是否是使用Oracle方言、專有對象，須要改造？
• 等等

面對上面這些問題，就須要快速瞭解現有Oracle的對象、語句、訪問特徵、性能表現等，並據此評估技術方案、遷移方案以及後續的工做量等。也就是說，須要給咱們的數據庫進行「畫像」。基於上面的數據庫畫像，對去O工做全週期進行指導，包括如下方面都將大有裨益：

• 決策階段：總體難度、成本（人財時）、技術風險
• 架構階段：技術方案、對象結構、性能評估
• 研發階段：兼容性、複雜度、測試
• 遷移階段：結構遷移、數據遷移、數據校驗

正是基於此類需求，有些公司推出評估產品，例如阿里的數據庫和應用遷移服務（簡稱 ADAM），但此類產品每每須要部署agent，上傳分析包等，對於安全比較敏感的企業不太可行。我所在的公司在兩年前啓動去O工做時，也面臨此問題。故特地開發個綠版小程序，可在本地運行，方便評估工做。

地址：https://github.com/bjbean/oracle-estimate-report

2、設計思路

收集並彙總 Oracle 數據庫信息，包含環境、空間、對象、訪問特徵、資源開銷及SQL語句等六方面信息，全面覆蓋數據庫實際運行情況。爲信息收集更有針對性，工具經過參數設置部分閾值。經過運行命令行，收集信息後生產WEB版評估報告，以可視化的方式直觀體現出來。不只可做爲去O評估依據，亦可做爲後續改造的數據參考。

3、畫像解讀

下面針對報告數據進行解讀，並對常見的去O選型-MySQL進行說明。

3.1 概要信息

顯示收集的目標的概要信息，包括IP、實例、用戶等。需注意分析時間，腳本會提取數據庫執行特徵（24小時內），所以建議在業務高峯以後運行。

3.2 空間信息

空間大小是數據庫選型需重點考慮的指標之一，也會影響到後續遷移。如庫規模較大，應考慮作分拆處理。拆分的原則就是儘可能控制單庫規模。通常可遵循以下拆分優先原則：

1）業務層垂直拆分

在應用層面，將數據按照不一樣的業務條線進行拆分。例如電商平臺中按照訂單、用戶、商品、庫存等拆分。各自拆分的部分，業務內聚，無強數據依賴關係。

2）業務層水平拆分

在同一業務內部，對數據創建生命週期管理，進行數據冷熱分層。針對不一樣層的數據訪問特色不一樣，可作進一步拆分。例如電商平臺中，針對訂單可分爲活躍訂單(二週內，可退換貨)、非活躍訂單(二週至半年期，客服可受理)、歷史訂單（半年以上）。

3）應用層分庫分表

若通過上述拆分單個庫的規模仍然較大，可考慮使用分庫分表技術。一般的作法是引入數據庫中間層，邏輯上虛擬出一個數據庫，但物理上劃分爲多個數據庫。這是一種不太「優雅」的方案，由於很難作到應用透明。也就是說，必須在研發方面有所妥協，犧牲一部分數據庫能力。常見技術方案上可分爲：Client、Proxy、SideCar三類，現多推薦使用Proxy模式（容器部署可考慮SideCar模式）。

4）基礎層分佈式數據庫

較「分庫分表」方式更爲完全的是直接使用分佈式數據庫。它提供了一種可承載更大規模（容量、吞吐量）的解決方案。近些年來，分佈式數據庫已逐漸成熟，推廣落地；並開始在關鍵場景中嘗試使用。

3.3 對象信息

針對Oracle中對象，在改型中各有不一樣的考慮要點。報告中給出彙總數據，也可給出明細數據方便查詢。站羣系統

1）表

表的數量過多，直接影響數據字典大小，進而影響數據庫總體效率。從MySQL來看，還需考慮文件句柄等問題。這一指標沒有必定之規，需根據狀況酌情考慮。這裏更可能是數據架構層面考慮，避免單庫數據表過多。曾經歷過單庫10萬張表，性能低下；優化後整合成2萬張的優化案例。如選擇MySQL，建議單庫不超過5000張表；庫*表的總數不超過20000。

2）表(大表)

控制單表的規模，是設計的要點之一，直接影響到訪問性能。表過大，應考慮採用上面的原則進行拆分。表大小沒有通用原則，這裏可經過參數進行配置。可按照物理大小或記錄數兩個維度設置。這裏的關鍵點在於表的訪問方式，如均爲簡單的kv型訪問，規模大些還好；如訪問比較複雜，則建議閾值設置更低些。如選擇MySQL，大表複雜查詢或多表關聯等均不是其擅長場景，可考慮使用ES、solr+hbase等方式異步處理複雜查詢。

3）表(分區表)

從9i、10g以來，Oracle的分區功能日趨完善、功能加強。能夠說已成爲Oracle應對海量數據的利器。但對於MySQL來講，仍然不太建議使用分區功能。一方面，隨着硬件能力的加強，單表可承載力變大；另外一方面，MySQL使用分區還需面對「DDL放大」、「鎖變化」等問題。若是團隊能夠很好地駕馭數據庫中間層，仍是建議使用複雜度更低的分表技術。這也許會稍許增長研發量，但對運維來講，好處多多。

4）字段(大對象)

在任何數據庫中，都不建議使用大對象。若是你用了，趁着改造工做，趕忙去掉吧。大對象功能對數據庫來講，就是雞肋。數據庫自身的ACID能力，應着力保存更爲重要的數據。

5）索引(B樹)

索引過多會影響DML效率、佔用大量空間。可經過「索引/表」，大體反應出索引數量的合理程度。這裏沒有建議的數值，可根據狀況酌情考慮。對於任何數據庫來講，都有相似的問題，就是如何「構建戰略性索引策略」。這裏可參考下表（選自李華植-《海量數據庫解決方案》一書），梳理索引需求。科學地建立、維護索引。

6）索引(其餘)

Oracle除了一般的B+樹索引外，還支持其餘類型的索引。如選擇其餘數據庫，那麼這些索引都須要改造，經過其餘方式實現。

7）視圖

視圖，做爲SQL語句的邏輯封裝，在某些場景下（如安全）頗有意義。不過它對於優化器有較高要求，Oracle在這方面作了不少工做（可參看做者寫的《SQL優化最佳實踐》一書）。而對於MySQL，則不建議使用，考慮改造。

8）觸發器/存儲過程/函數

對於數據庫來講，承載了計算、存儲兩類能力。做爲整個基礎架構部分最難擴展的組件，儘可能發揮數據庫的核心能力很重要。相較於存儲能力而言，計算能力是可經過應用層解決，而應用層又是每每容易擴展的。此外，考慮到將來的可維護性、可遷移性等因素，這部分考慮在應用端解決吧。

9）序列

Oracle中的序列，可提供遞增的、非連續保障序號服務。在MySQL中有相似的實現，是經過自增屬性來完成。這部分應該能夠作遷移，但若是併發量很是大；亦可考慮使用發號器的解決方案。

10）同義詞

同義詞是數據耦合的表現，不管在什麼數據庫，都應該摒棄掉。應考慮在業務端進行拆分，再也不依賴於這種特性。

3.4 訪問特徵

這裏收集了，在過去的24小時內數據庫中DML次數最多的Top20。這直接地反應出當前系統的操做的「熱點」對象。這些對象都須要在選型以後、遷移以前重點評估其性能表現。能考慮分拆、緩存等手段，都可減低這些對象的熱點壓力。不只侷限於這些對象，更建議的是創建「業務壓力模型」。經過對業務充分的瞭解和評估後，將業務邏輯抽象出來，轉化爲數據壓力模型。此處的難點在於對業務邏輯的抽象能力及對模塊業務量的比例評估。

可依據上述僞代碼，編制壓力測試代碼。經過一些工具調用測試代碼，產生模擬測試的壓力。這對於系統改造、升級、擴容評估、新硬件選型等均有意義。在具體去O工做中，新技術方案是否知足須要，可經過此方法進行評估驗證。更多用業務的語言，來對比去O先後的承載力變化。這也是決策技術方案是否可行的考慮因素之一。固然上述信息，只包括了DML，對查詢部分是不包含的，能夠從Oracle AWR中得到這些數據。更爲完整的，能夠考慮結合應用作全鏈路的壓測。

3.5 資源消耗

這裏列出了最近24小時的資源使用狀況。這些數據主要有兩個目的：

1）評估總體負載

由於上述指標是Oracle的度量顯示的，沒法直接類比到其餘數據庫。能夠憑藉專家經驗+歷史數據，評估負載壓力。用於對其餘備選技術方案進行評估的依據之一。這其中的有些指標（例如user calls等），能夠轉化爲量化指標指導後續測試等工做。

2）評估瓶頸點

對於某項指標很是突出的狀況，那說明現有業務也有瓶頸，在遷移至其餘方案時儘可能在設計階段就予以考慮，並在測試環節重點關注，減小可能的技術風險。

3.6 SQL語句

SQL語句的改寫，是整個遷移工做中最爲頭疼的部分。除非是徹底重構，不然是須要關注SQL改寫的工做任務。這裏面涉及到改寫量、複雜度、性能對比等諸多內容，不少仍是須要人工甄別完成。

筆者曾經有過這樣的經驗，項目組花1個月的時間就完成某項目的「結構+SQL」的遷移工做，可是後續又花費了3個月的時間完成語句優化、甚至結構調整。其緣由是遷移上線後語句沒法知足性能需求。而這是在邊上線、邊調整，過程異常痛苦。所以早期查明現有SQL狀況，對於評估工做量、改寫難度、性能評估，有着重要的意義。而上面這部分就是收集了分析用戶在歷史的全部SQL（能夠打開明細開關，顯示全量SQL），其包含了如下這些維度。

1）總SQL數

該指標可近似反映業務繁忙程度。此外，也可用於後續有問題語句的比例分析基礎。

2）超長SQL

這裏列出了超過指定字符數的語句，閥值在可經過參數進行配置。若是是考慮MySQL，建議使用「短小精悍」的SQL，面對複雜SQL則通常表現不佳。那麼對於這些超長的語句，都是值得關注的對象，起碼是容易出現問題的語句。

3）ANTI SQL

反向查詢，數據庫處理上都較爲困難，這部分也比較考驗優化器。雖然在MySQL的較新版本中，對反向查詢有了不錯的優化，但這部分仍然值得關注。

4）Oracle Syntax SQL

有Oracle特徵的寫法，即Oracle的方言（例如特有函數、僞列等），這些都是須要在遷移中進行處理的。固然如今也有的廠商，宣佈其產品是兼容Oracle語法的，但也建議針對這些作專門測試。

5）Join 3+ Table SQL

多表關聯，也是比較考驗優化器。特別是MySQL表間關聯效率偏低，不建議使用超過2個以上表的關聯。這裏列出的是3個及以上的關聯查詢，須要考慮修改。針對特別複雜的查詢，能夠考慮將其卸載到大數據平臺完成。

6）SubQuery SQL

子查詢狀況相似上面，也是MySQL不擅長的。雖然優化器可在必定程度上進行優化，但仍是值得關注。