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

一、常見疑惑

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

[管理者]

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

[架構師]

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

[開發者]

• 複雜SQL多嘛？
• 改造量是不是很大？
• 是不是使用Oracle方言、專有物件，需要改造？
• 等等

面對上面這些問題，就需要快速瞭解現有Oracle的物件、語句、訪問特徵、效能表現等，並據此評估技術方案、遷移方案以及後續的工作量等。也就是說，需要給我們的資料庫進行“畫像”。基於上面的資料庫畫像，對去O工作全週期進行指導，包括以下方面都將大有裨益：

• 決策階段：整體難度、成本（人財時）、技術風險
• 架構階段：技術方案、物件結構、效能評估
• 研發階段：相容性、複雜度、測試
• 遷移階段：結構遷移、資料遷移、資料校驗

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

地址：

二、設計思路

收集並彙總 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不擅長的。雖然最佳化器可在一定程度上進行最佳化，但還是值得關注。

作者：韓鋒

原文首發於公眾號《韓鋒頻道》，歡迎關注。

來源：宜信技術學院