通過自研數(shù)據(jù)庫畫像工具支持“去O”數(shù)據(jù)庫評估

“去O”，是近些年來一直很火的一個話題，隨之也產(chǎn)生了各種疑惑，包括現(xiàn)有數(shù)據(jù)庫評估、技術(shù)選型等。去O是項系統(tǒng)工程，需要做好充分的評估。本文通過自研工具，生成數(shù)據(jù)庫畫像，為去O評估提供一手數(shù)據(jù)，希望給大家?guī)斫梃b。

一、常見疑惑

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

[管理者]

• 數(shù)據(jù)庫去O成本高嘛？

• 工作量大不大？

• 工期長嗎？

• 是否存在什么風(fēng)險？

[架構(gòu)師]

• 使用MySQL能承載現(xiàn)有業(yè)務(wù)規(guī)模嘛？

• 是否有什么技術(shù)風(fēng)險？

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

• 是否需要引入緩存嘛？

• 研發(fā)復(fù)雜度高嘛？

• 需要投入多大工期？

• 數(shù)據(jù)訪問特征如何？

• 遷移前后對比數(shù)據(jù)量大嗎？

[開發(fā)者]

• 復(fù)雜SQL多嘛？

• 改造量是不是很大？

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

• 等等

面對上面這些問題，就需要快速了解現(xiàn)有Oracle的對象、語句、訪問特征、性能表現(xiàn)等，并據(jù)此評估技術(shù)方案、遷移方案以及后續(xù)的工作量等。也就是說，需要給我們的數(shù)據(jù)庫進行“畫像”?；谏厦娴臄?shù)據(jù)庫畫像，對去O工作全周期進行指導(dǎo)，包括以下方面都將大有裨益：

• 決策階段：整體難度、成本（人財時）、技術(shù)風(fēng)險

• 架構(gòu)階段：技術(shù)方案、對象結(jié)構(gòu)、性能評估

• 研發(fā)階段：兼容性、復(fù)雜度、測試

• 遷移階段：結(jié)構(gòu)遷移、數(shù)據(jù)遷移、數(shù)據(jù)校驗

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

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

二、設(shè)計思路

收集并匯總 Oracle 數(shù)據(jù)庫信息，包含環(huán)境、空間、對象、訪問特征、資源開銷及SQL語句等六方面信息，全面覆蓋數(shù)據(jù)庫實際運行狀況。為信息收集更有針對性，工具通過參數(shù)設(shè)置部分閾值。通過運行命令行，收集信息后生產(chǎn)WEB版評估報告，以可視化的方式直觀體現(xiàn)出來。不僅可作為去O評估依據(jù)，亦可作為后續(xù)改造的數(shù)據(jù)參考。

三、畫像解讀

下面針對報告數(shù)據(jù)進行解讀，并對常見的去O選型-MySQL進行說明。

3.1 概要信息

顯示收集的目標(biāo)的概要信息，包括IP、實例、用戶等。需注意分析時間，腳本會提取數(shù)據(jù)庫執(zhí)行特征（24小時內(nèi)），因此建議在業(yè)務(wù)高峰之后運行。

3.2 空間信息

空間大小是數(shù)據(jù)庫選型需重點考慮的指標(biāo)之一，也會影響到后續(xù)遷移。如庫規(guī)模較大，應(yīng)考慮做分拆處理。拆分的原則就是盡量控制單庫規(guī)模。一般可遵循如下拆分優(yōu)先原則：

1）業(yè)務(wù)層垂直拆分

在應(yīng)用層面，將數(shù)據(jù)按照不同的業(yè)務(wù)條線進行拆分。例如電商平臺中按照訂單、用戶、商品、庫存等拆分。各自拆分的部分，業(yè)務(wù)內(nèi)聚，無強數(shù)據(jù)依賴關(guān)系。

2）業(yè)務(wù)層水平拆分

在同一業(yè)務(wù)內(nèi)部，對數(shù)據(jù)建立生命周期管理，進行數(shù)據(jù)冷熱分層。針對不同層的數(shù)據(jù)訪問特點不同，可做進一步拆分。例如電商平臺中，針對訂單可分為活躍訂單(二周內(nèi)，可退換貨)、非活躍訂單(二周至半年期，客服可受理)、歷史訂單（半年以上）。

3）應(yīng)用層分庫分表

若經(jīng)過上述拆分單個庫的規(guī)模仍然較大，可考慮使用分庫分表技術(shù)。通常的做法是引入數(shù)據(jù)庫中間層，邏輯上虛擬出一個數(shù)據(jù)庫，但物理上劃分為多個數(shù)據(jù)庫。這是一種不太“優(yōu)雅”的方案，因為很難做到應(yīng)用透明。也就是說，必須在研發(fā)方面有所妥協(xié)，犧牲一部分數(shù)據(jù)庫能力。常見技術(shù)方案上可分為：Client、Proxy、SideCar三類，現(xiàn)多推薦使用Proxy模式（容器部署可考慮SideCar模式）。

4）基礎(chǔ)層分布式數(shù)據(jù)庫

較“分庫分表”方式更為徹底的是直接使用分布式數(shù)據(jù)庫。它提供了一種可承載更大規(guī)模（容量、吞吐量）的解決方案。近些年來，分布式數(shù)據(jù)庫已逐漸成熟，推廣落地；并開始在關(guān)鍵場景中嘗試使用。

3.3 對象信息

針對Oracle中對象，在改型中各有不同的考慮要點。報告中給出匯總數(shù)據(jù)，也可給出明細數(shù)據(jù)方便查詢。

1）表

表的數(shù)量過多，直接影響數(shù)據(jù)字典大小，進而影響數(shù)據(jù)庫整體效率。從MySQL來看，還需考慮文件句柄等問題。這一指標(biāo)沒有一定之規(guī)，需根據(jù)情況酌情考慮。這里更多是數(shù)據(jù)架構(gòu)層面考慮，避免單庫數(shù)據(jù)表過多。曾經(jīng)歷過單庫10萬張表，性能低下；優(yōu)化后整合成2萬張的優(yōu)化案例。如選擇MySQL，建議單庫不超過5000張表；庫*表的總數(shù)不超過20000。

2）表(大表)

控制單表的規(guī)模，是設(shè)計的要點之一，直接影響到訪問性能。表過大，應(yīng)考慮采用上面的原則進行拆分。表大小沒有通用原則，這里可通過參數(shù)進行配置?？砂凑瘴锢泶笮』蛴涗洈?shù)兩個維度設(shè)置。這里的關(guān)鍵點在于表的訪問方式，如均為簡單的kv型訪問，規(guī)模大些還好；如訪問比較復(fù)雜，則建議閾值設(shè)置更低些。如選擇MySQL，大表復(fù)雜查詢或多表關(guān)聯(lián)等均不是其擅長場景，可考慮使用ES、solr+hbase等方式異步處理復(fù)雜查詢。

3）表(分區(qū)表)

從9i、10g以來，Oracle的分區(qū)功能日趨完善、功能增強?？梢哉f已成為Oracle應(yīng)對海量數(shù)據(jù)的利器。但對于MySQL來說，仍然不太建議使用分區(qū)功能。一方面，隨著硬件能力的增強，單表可承載力變大；另一方面，MySQL使用分區(qū)還需面對“DDL放大”、“鎖變化”等問題。如果團隊可以很好地駕馭數(shù)據(jù)庫中間層，還是建議使用復(fù)雜度更低的分表技術(shù)。這也許會稍許增加研發(fā)量，但對運維來說，好處多多。

4）字段(大對象)

在任何數(shù)據(jù)庫中，都不建議使用大對象。如果你用了，趁著改造工作，趕緊去掉吧。大對象功能對數(shù)據(jù)庫來說，就是肋。數(shù)據(jù)庫自身的ACID能力，應(yīng)著力保存更為重要的數(shù)據(jù)。

5）索引(B樹)

索引過多會影響DML效率、占用大量空間?？赏ㄟ^“索引/表”，大致反應(yīng)出索引數(shù)量的合理程度。這里沒有建議的數(shù)值，可根據(jù)情況酌情考慮。對于任何數(shù)據(jù)庫來說，都有類似的問題，就是如何“構(gòu)建戰(zhàn)略性索引策略”。這里可參考下表（選自李華植-《海量數(shù)據(jù)庫解決方案》一書），梳理索引需求。科學(xué)地創(chuàng)建、維護索引。

6）索引(其他)

Oracle除了通常的B+樹索引外，還支持其他類型的索引。如選擇其他數(shù)據(jù)庫，那么這些索引都需要改造，通過其他方式實現(xiàn)。

7）視圖

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

8）觸發(fā)器/存儲過程/函數(shù)

對于數(shù)據(jù)庫來說，承載了計算、存儲兩類能力。作為整個基礎(chǔ)架構(gòu)部分最難擴展的組件，盡量發(fā)揮數(shù)據(jù)庫的核心能力很重要。相較于存儲能力而言，計算能力是可通過應(yīng)用層解決，而應(yīng)用層又是往往容易擴展的。此外，考慮到未來的可維護性、可遷移性等因素，這部分考慮在應(yīng)用端解決吧。

9）序列

Oracle中的序列，可提供遞增的、非連續(xù)保障序號服務(wù)。在MySQL中有類似的實現(xiàn)，是通過自增屬性來完成。這部分應(yīng)該可以做遷移，但如果并發(fā)量非常大；亦可考慮使用發(fā)號器的解決方案。

10）同義詞

同義詞是數(shù)據(jù)耦合的表現(xiàn)，無論在什么數(shù)據(jù)庫，都應(yīng)該摒棄掉。應(yīng)考慮在業(yè)務(wù)端進行拆分，不再依賴于這種特性。

3.4 訪問特征

這里收集了，在過去的24小時內(nèi)數(shù)據(jù)庫中DML次數(shù)最多的Top20。這直接地反應(yīng)出當(dāng)前系統(tǒng)的操作的“熱點”對象。這些對象都需要在選型之后、遷移之前重點評估其性能表現(xiàn)。能考慮分拆、緩存等手段，均可減低這些對象的熱點壓力。不僅局限于這些對象，更建議的是建立“業(yè)務(wù)壓力模型”。通過對業(yè)務(wù)充分的了解和評估后，將業(yè)務(wù)邏輯抽象出來，轉(zhuǎn)化為數(shù)據(jù)壓力模型。此處的難點在于對業(yè)務(wù)邏輯的抽象能力及對模塊業(yè)務(wù)量的比例評估。

形成類似下面的偽代碼：

可依據(jù)上述偽代碼，編制壓力測試代碼。通過一些工具調(diào)用測試代碼，產(chǎn)生模擬測試的壓力。這對于系統(tǒng)改造、升級、擴容評估、新硬件選型等均有意義。在具體去O工作中，新技術(shù)方案是否滿足需要，可通過此方法進行評估驗證。更多用業(yè)務(wù)的語言，來對比去O前后的承載力變化。這也是決策技術(shù)方案是否可行的考慮因素之一。當(dāng)然上述信息，只包括了DML，對查詢部分是不包含的，可以從Oracle AWR中獲得這些數(shù)據(jù)。更為完整的，可以考慮結(jié)合應(yīng)用做全鏈路的壓測。焦作國醫(yī)胃腸?？漆t(yī)院：http://jz.lieju.com/zhuankeyiyuan/37845056.htm

3.5 資源消耗

這里列出了最近24小時的資源使用情況。這些數(shù)據(jù)主要有兩個目的：鄭州哪家醫(yī)院治療不孕不育好：byby.zztjyy.com

1）評估整體負載

因為上述指標(biāo)是Oracle的度量顯示的，無法直接類比到其他數(shù)據(jù)庫。可以憑借專家經(jīng)驗+歷史數(shù)據(jù)，評估負載壓力。用于對其他備選技術(shù)方案進行評估的依據(jù)之一。這其中的有些指標(biāo)（例如user calls等），可以轉(zhuǎn)化為量化指標(biāo)指導(dǎo)后續(xù)測試等工作。

2）評估瓶頸點

對于某項指標(biāo)非常突出的情況，那說明現(xiàn)有業(yè)務(wù)也有瓶頸，在遷移至其他方案時盡量在設(shè)計階段就予以考慮，并在測試環(huán)節(jié)重點關(guān)注，減少可能的技術(shù)風(fēng)險。

3.6 SQL語句

SQL語句的改寫，是整個遷移工作中最為頭疼的部分。除非是完全重構(gòu)，否則是需要關(guān)注SQL改寫的工作任務(wù)。這里面涉及到改寫量、復(fù)雜度、性能對比等諸多內(nèi)容，很多還是需要人工甄別完成。

筆者曾經(jīng)有過這樣的經(jīng)驗，項目組花1個月的時間就完成某項目的“結(jié)構(gòu)+SQL”的遷移工作，但是后續(xù)又花費了3個月的時間完成語句優(yōu)化、甚至結(jié)構(gòu)調(diào)整。其原因是遷移上線后語句無法滿足性能需求。而這是在邊上線、邊調(diào)整，過程異常痛苦。因此早期查明現(xiàn)有SQL情況，對于評估工作量、改寫難度、性能評估，有著重要的意義。而上面這部分就是收集了分析用戶在歷史的所有SQL（可以打開明細開關(guān)，顯示全量SQL），其包含了以下這些維度。焦作國醫(yī)胃腸?？漆t(yī)院：https://www.jianshu.com/p/b8966d1a468e

1）總SQL數(shù)

該指標(biāo)可近似反映業(yè)務(wù)繁忙程度。此外，也可用于后續(xù)有問題語句的比例分析基礎(chǔ)。

2）超長SQL

這里列出了超過指定字符數(shù)的語句，閥值在可通過參數(shù)進行配置。如果是考慮MySQL，建議使用“短小精悍”的SQL，面對復(fù)雜SQL則一般表現(xiàn)不佳。那么對于這些超長的語句，都是值得關(guān)注的對象，起碼是容易出現(xiàn)問題的語句。

3）ANTI SQL

反向查詢，數(shù)據(jù)庫處理上都較為困難，這部分也比較考驗優(yōu)化器。雖然在MySQL的較新版本中，對反向查詢有了不錯的優(yōu)化，但這部分仍然值得關(guān)注。

4）Oracle Syntax SQL

有Oracle特征的寫法，即Oracle的方言（例如特有函數(shù)、偽列等），這些都是需要在遷移中進行處理的。當(dāng)然現(xiàn)在也有的廠商，宣布其產(chǎn)品是兼容Oracle語法的，但也建議針對這些做專門測試。

5）Join 3+ Table SQL

多表關(guān)聯(lián)，也是比較考驗優(yōu)化器。特別是MySQL表間關(guān)聯(lián)效率偏低，不建議使用超過2個以上表的關(guān)聯(lián)。這里列出的是3個及以上的關(guān)聯(lián)查詢，需要考慮修改。針對特別復(fù)雜的查詢，可以考慮將其卸載到大數(shù)據(jù)平臺完成。

6）SubQuery SQL

子查詢情況類似上面，也是MySQL不擅長的。雖然優(yōu)化器可在一定程度上進行優(yōu)化，但還是值得關(guān)注。