“去O”，是近些年來一直很火的一個話題，隨之也產生了各種疑惑，包括現有數據庫評估、技術選型等。去O是項系統工程，需要做好充分的評估。本文通過自研工具，生成數據庫畫像，為去O評估提供一手數據，希望給大家帶來借鑒。

 

一、常見疑惑

 

 

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

[管理者]

• 數據庫去O成本高嘛？ 

• 工作量大不大？ 

• 工期長嗎？ 

• 是否存在什么風險？

[架構師]

• 使用MySQL能承載現有業務規模嘛？ 

• 是否有什么技術風險？ 

• 是否需要引入分庫分表嘛？ 

• 是否需要引入緩存嘛？ 

• 研發復雜度高嘛？ 

• 需要投入多大工期？ 

• 數據訪問特征如何？ 

• 遷移前后對比數據量大嗎？

[開發者]

• 復雜SQL多嘛？ 

• 改造量是不是很大？ 

• 是不是使用Oracle方言、專有對象，需要改造？ 

• 等等

面對上面這些問題，就需要快速了解現有Oracle的對象、語句、訪問特征、性能表現等，并據此評估技術方案、遷移方案以及后續的工作量等。也就是說，需要給我們的數據庫進行“畫像”。基于上面的數據庫畫像，對去O工作全周期進行指導，包括以下方面都將大有裨益：

• 決策階段：整體難度、成本（人財時）、技術風險 

• 架構階段：技術方案、對象結構、性能評估 

• 研發階段：兼容性、復雜度、測試 

• 遷移階段：結構遷移、數據遷移、數據校驗

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

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

 

 

二、設計思路

 

 

收集并匯總 Oracle 數據庫信息，包含環境、空間、對象、訪問特征、資源開銷及SQL語句等六方面信息，全面覆蓋數據庫實際運行狀況。為信息收集更有針對性，工具通過參數設置部分閾值。

 

通過運行命令行，收集信息后生產WEB版評估報告，以可視化的方式直觀體現出來。不僅可作為去O評估依據，亦可作為后續改造的數據參考。

 

 

三、畫像解讀

 

 

下面針對報告數據進行解讀，并對常見的去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不擅長的。雖然優化器可在一定程度上進行優化，但還是值得關注。

【本文是51CTO專欄機構宜信技術學院的原創文章，微信公眾號“宜信技術學院( id: CE_TECH)”】

戳這里，看該作者更多好文