百麗時(shí)尚集團(tuán)（以下簡(jiǎn)稱百麗）是中國(guó)領(lǐng)先的大型時(shí)尚鞋服集團(tuán)，其核心財(cái)務(wù)系統(tǒng)剛剛經(jīng)歷了一場(chǎng)“換心臟”手術(shù)。 本文詳細(xì)拆解MyCat 切換 OceanBase 的三個(gè)步驟與技術(shù)方案、問題匯總，干貨滿滿，推薦閱讀～

作者：盧文豪，百麗時(shí)尚數(shù)據(jù)庫(kù)負(fù)責(zé)人

百麗時(shí)尚集團(tuán)（以下簡(jiǎn)稱百麗）是中國(guó)領(lǐng)先的大型時(shí)尚鞋服集團(tuán)，旗下?lián)碛?0+ 個(gè)鞋服品牌，如#BELLE（百麗）、#TATA（他她）、#TEENMIX（天美意）等，覆蓋了從高端到大眾時(shí)尚、功能、運(yùn)動(dòng)、潮流等品類，線下門店共計(jì)8000+，覆蓋300+城市。作為中國(guó)時(shí)尚鞋履市場(chǎng)占有率連續(xù)十余年位居第一的企業(yè)，百麗擁有發(fā)達(dá)的線下銷售網(wǎng)絡(luò)，從原料到設(shè)計(jì)到生產(chǎn)，再到終端零售，已形成產(chǎn)供銷一體的完整供應(yīng)鏈。

在這條供應(yīng)鏈背后，由集團(tuán)的科技中心統(tǒng)籌業(yè)務(wù)系統(tǒng)的建設(shè)與運(yùn)維，包括零售、庫(kù)存、財(cái)務(wù)等核心板塊。為了解除底層技術(shù)瓶頸對(duì)業(yè)務(wù)發(fā)展的影響，科技中心不斷迭代技術(shù)方案。其中作為核心之一的財(cái)務(wù)系統(tǒng)剛剛經(jīng)歷了一場(chǎng)“換心臟”手術(shù)，將數(shù)據(jù)庫(kù)方案從分庫(kù)分表MyCat 架構(gòu)遷移到 OceanBase，實(shí)現(xiàn)了提性能和降成本的 “雙豐收”。

先說(shuō)成果：性能提升30倍，降本高達(dá)原架構(gòu)的18倍

關(guān)鍵功能效率提升30倍。

以財(cái)務(wù)系統(tǒng)的成本核算功能為例，整體運(yùn)行時(shí)間相對(duì)較長(zhǎng)。原本在 MyCat 運(yùn)行時(shí)需耗時(shí) 10 小時(shí)，遷移至 OceanBase 后僅需 20 分鐘，性能提升 30 倍。由監(jiān)控?cái)?shù)據(jù)（見圖1）可以看出，原系統(tǒng)在每日 02:00–12:00 期間磁盤持續(xù)高負(fù)載；而在 OceanBase 環(huán)境下，相同任務(wù) 20 分鐘內(nèi)即可完成，負(fù)載迅速回落，提效幅度顯著，已得到研發(fā)團(tuán)隊(duì)的高度認(rèn)可。

圖1 數(shù)據(jù)庫(kù)遷移前后性能監(jiān)控?cái)?shù)據(jù)

存儲(chǔ)成本降96.7%，硬件成本降59.4%。

原來(lái)的 MyCat 數(shù)據(jù)共占用 20.3 TB，遷移至 OceanBase 后僅占用 1.3 TB，整體壓縮率高達(dá)96.7%。壓縮收益主要來(lái)自兩方面：一方面是 OceanBase 自身的高壓縮率，另一方面是原來(lái)的 MyCat 架構(gòu)下存在大量數(shù)據(jù)冗余，經(jīng)過(guò) OceanBase 的存算一體化架構(gòu)整合，冗余數(shù)據(jù)得到釋放。

另外，原來(lái)的 MyCat 環(huán)境部署共使用 37 臺(tái)服務(wù)器，遷移到 OceanBase 后僅用 10 臺(tái)服務(wù)器即可支撐全部業(yè)務(wù)，使該業(yè)務(wù)服務(wù)器費(fèi)用從207萬(wàn)縮減為84萬(wàn)，硬件成本下降59.4%。

之所以能夠取得這樣的效果，一方面是由于原架構(gòu)的冗余與性能瓶頸對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生了限制，而新的數(shù)據(jù)庫(kù)方案不僅解開了瓶頸，還帶來(lái)了更大的增益。另一方面，歸結(jié)于正確的遷移和技術(shù)優(yōu)化，下文展開敘述我們的遷移經(jīng)驗(yàn)。

經(jīng)驗(yàn)匯總：MyCat 切換 OceanBase 三步走

切換背景

百麗的業(yè)務(wù)系統(tǒng)原本統(tǒng)一采用#MyCat中間件 實(shí)現(xiàn)分庫(kù)分表，以每個(gè)大區(qū)（如華南、華北）規(guī)劃分片粒度，確保了絕大多數(shù)門店級(jí)庫(kù)存操作收斂到單分片執(zhí)行，從而顯著減少分布式事務(wù)。

圖2是業(yè)務(wù)原來(lái)基于MyCat的sharding架構(gòu)，采用一主兩從的配置，主機(jī)房位于北京，兩個(gè)從節(jié)點(diǎn)位于烏蘭察布機(jī)房作為異地容災(zāi)機(jī)房。業(yè)務(wù)數(shù)據(jù)根據(jù)地區(qū)劃分不同的大區(qū)分片，每個(gè)地區(qū)數(shù)據(jù)訪問經(jīng)由MyCat下發(fā)到各大區(qū)分片執(zhí)行，為了避免分布式事務(wù)，業(yè)務(wù)層面盡量保證每次獲取的數(shù)據(jù)都只定位到其中某個(gè)大區(qū)。

圖2 基于MyCat的sharding架構(gòu)

在業(yè)務(wù)的演進(jìn)過(guò)程中，業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)需求隨之增多，分庫(kù)分表 MyCat 架構(gòu)逐漸暴露出三類主要問題。

第一類問題是數(shù)據(jù)遷移困難。 當(dāng)業(yè)務(wù)需要合并或調(diào)整大區(qū)時(shí)，必須進(jìn)行跨庫(kù)數(shù)據(jù)搬遷。整個(gè)過(guò)程腳本復(fù)雜、回滾窗口小，風(fēng)險(xiǎn)高、周期長(zhǎng)。

第二類問題是MyCat 功能缺陷影響業(yè)務(wù)。 MyCat 僅提供基礎(chǔ)路由能力，對(duì)復(fù)雜 SQL（多表關(guān)聯(lián)、子查詢、聚合統(tǒng)計(jì)）和分布式事務(wù)支持有限，因財(cái)務(wù)等模塊的查詢較為復(fù)雜，被迫將分片表改為全局表，且需要應(yīng)用適配，導(dǎo)致數(shù)據(jù)冗余并增加維護(hù)成本。

第三類問題是擴(kuò)展性差。 橫向擴(kuò)容需要重新劃分大區(qū)并再次觸發(fā)全量數(shù)據(jù)遷移，當(dāng)出現(xiàn)性能瓶頸時(shí)，只能依賴垂直升配硬件，無(wú)法通過(guò)水平擴(kuò)展快速解決。

為替代 MyCat 并解決其固有痛點(diǎn)，科技中心將選型范圍鎖定于原生分布式數(shù)據(jù)庫(kù)，并明確兩項(xiàng)核心訴求：一是高可用，零數(shù)據(jù)丟失；二是在線彈性擴(kuò)展，無(wú)需停服或搬遷數(shù)據(jù)。

經(jīng)過(guò)市場(chǎng)調(diào)研和多輪評(píng)估，百麗科技中心最終選定 OceanBase。下文將以財(cái)務(wù)核心系統(tǒng)從 MyCat 升級(jí)至 OceanBase 的項(xiàng)目為例，系統(tǒng)梳理數(shù)據(jù)庫(kù)替換過(guò)程中的關(guān)鍵實(shí)踐。無(wú)論采用哪一種替換方案，均需圍繞三個(gè)核心步驟展開。

1. 數(shù)據(jù)流轉(zhuǎn)：梳理全鏈路數(shù)據(jù)流，明確數(shù)據(jù)從哪里來(lái)、到哪里去。
2. 數(shù)據(jù)校驗(yàn)：確保數(shù)據(jù)正確性，驗(yàn)證準(zhǔn)確性和一致性。
3. 兼容與調(diào)優(yōu)：識(shí)別兼容、性能問題，并治理。

第一步：數(shù)據(jù)流轉(zhuǎn)

MyCat 架構(gòu)下

上游數(shù)據(jù)同步鏈路如圖三所示。

• 主數(shù)據(jù) MySQL：通過(guò) MyCat 以全局表方式向各大區(qū) DB 下發(fā)集團(tuán)各業(yè)務(wù)通用數(shù)據(jù)。
• 財(cái)務(wù)應(yīng)用：其他業(yè)務(wù)系統(tǒng)也會(huì)將數(shù)據(jù)同步到 MyCat，因?yàn)椴煌瑯I(yè)務(wù)對(duì)應(yīng)的分區(qū)是相同的，所以不同業(yè)務(wù)間的數(shù)據(jù)同步是通過(guò)DB一一對(duì)應(yīng)的方式進(jìn)行。
• 同步工具：紅色鏈路代表數(shù)據(jù)同步鏈路，統(tǒng)一采用阿里開源工具 Otter。

圖3 MyCat架構(gòu)下，上游數(shù)據(jù)同步鏈路

下游數(shù)據(jù)同步鏈路如圖4 所示。

• 數(shù)倉(cāng)：通過(guò) Binlog 抽取實(shí)現(xiàn)入倉(cāng)。
• Oracle：財(cái)務(wù)系統(tǒng)的業(yè)務(wù)數(shù)據(jù)需同步到#Oracle 進(jìn)行報(bào)表分析。
• 同步工具：紅色鏈路代表數(shù)據(jù)同步鏈路，統(tǒng)一采用阿里開源工具 Otter。

圖4 MyCat架構(gòu)下，下游數(shù)據(jù)同步鏈路

OceanBase 架構(gòu)下

如果使用 OceanBase 替換 MyCat，上線后能否打通現(xiàn)有數(shù)據(jù)鏈路正常流轉(zhuǎn)呢？

上游（見圖5）以 OceanBase 作為目標(biāo)端的鏈路實(shí)現(xiàn)比較簡(jiǎn)單，只需修改目標(biāo)端配置即可實(shí)現(xiàn)數(shù)據(jù)同步，可以維持舊方式進(jìn)行同步。

圖5 OceanBase架構(gòu)下，上游數(shù)據(jù)同步鏈路

相對(duì)上游，下游的替換比較復(fù)雜。之前 MyCat 架構(gòu)下是基于 Binlog 實(shí)現(xiàn)的數(shù)據(jù)同步，如果替換為 OceanBase，無(wú)法直接提供 Binlog 日志以供下游消費(fèi)。 那么如何同步數(shù)據(jù)到下游呢？有兩種解決方案（見圖3）。

第一種方案： 在Fas OceanBase部署OceanBase Binlog Service來(lái)生成 Binlog，對(duì)整個(gè)數(shù)據(jù)鏈路來(lái)說(shuō)，基本可以通過(guò) Otter 跑通整個(gè)鏈路，兼容性是最好的，改動(dòng)最小。但也存在一些問題，比如MyCat 中有八個(gè)MySQL分片，相當(dāng)于8個(gè)線程去采集8個(gè)數(shù)據(jù)庫(kù)實(shí)例的數(shù)據(jù)。由于 OceanBase Binlog Service 是以租戶為維度，無(wú)論是生產(chǎn)Binlog還是消費(fèi)Binlog，都只能有1個(gè)線程去處理。在業(yè)務(wù)高峰期間, 可能存在性能瓶頸。

第二種方案： OMS 將數(shù)據(jù)變更下發(fā)到 Kafka，通過(guò)這種方案，數(shù)倉(cāng)能夠以較低的延遲快速抽取數(shù)據(jù)，從而滿足實(shí)時(shí)報(bào)表及其他高時(shí)效性業(yè)務(wù)需求，解決了方案一的性能問題。同時(shí)由于數(shù)據(jù)倉(cāng)庫(kù)和部分?jǐn)?shù)據(jù)同步到 Oracle 需求，對(duì)實(shí)時(shí)性要求極高，也必須采用 OMS 到 Kafka 的鏈路實(shí)現(xiàn)。為此，需要開發(fā)數(shù)據(jù)同步工具，完成下游從 Kafka 到 Oracle 的數(shù)據(jù)流轉(zhuǎn)需求。

圖6 MyCat替換為OceanBase同步數(shù)據(jù)至下游的兩種方式

關(guān)于 OMS 的使用經(jīng)驗(yàn)，我們總結(jié)了幾點(diǎn)實(shí)踐中遇到的問題與注意事項(xiàng)。

其一，OMS 插入存在沖突會(huì)在日志打印，不影響復(fù)制。

OMS 在插入數(shù)據(jù)時(shí)，若檢測(cè)到數(shù)據(jù)沖突，會(huì)在日志中記錄相關(guān)信息，不會(huì)中斷復(fù)制流程。這意味著，例如在分庫(kù)場(chǎng)景下，即使存在組件沖突，OceanBase 通過(guò) OMS 的鏈路仍將持續(xù)運(yùn)行，不會(huì)因此中斷。對(duì)此，我們需在后續(xù)工作中加強(qiáng)數(shù)據(jù)校驗(yàn)機(jī)制，及時(shí)發(fā)現(xiàn)并處理潛在的數(shù)據(jù)一致性問題。

其二，OMS V4.2.5.2 之前的版本需要關(guān)注字段超過(guò) 4K 的復(fù)制情況。

在 OMS 4.2.5.2 之前的版本中，對(duì)于超過(guò) 4K 的LOB字段行外存儲(chǔ)的話，執(zhí)行DML時(shí)OBCDC可能不吐出LOB列的前鏡像，導(dǎo)致下游數(shù)據(jù)不一致。具體表現(xiàn)為：若某行數(shù)據(jù)未對(duì)該大字段進(jìn)行修改，OMS 在將變更消息下發(fā)至 Kafka 時(shí)，會(huì)將該字段內(nèi)容置為空。這一行為對(duì)一般依賴全鏡像復(fù)制的數(shù)據(jù)同步工具而言并不友好。例如，如果僅修改更新時(shí)間，也可能導(dǎo)致大于 4K 的字段被置空，從而影響下游數(shù)據(jù)的完整性，建議使用4.2.5.2以后的版本（OMS 4.2.5.2版本已解決該問題）。

其三，OMS 下發(fā)數(shù)據(jù)變化到 Kafka，從消費(fèi)角度 Hash 性能最優(yōu)，但是要考慮是否存在唯一鍵的問題。

OMS 支持兩種數(shù)據(jù)變更下發(fā)方式：一種是以表維度，另一種是以主鍵 Hash 分區(qū)維度。從消費(fèi)者角度考慮，主鍵 Hash 分區(qū)的性能最好。但需要考慮某些場(chǎng)景目標(biāo)端存在的唯一鍵問題，可能會(huì)導(dǎo)致數(shù)據(jù)丟失。

以我們遇到的場(chǎng)景為例：假設(shè)有一張表（tab1），有一個(gè)主鍵（id）和一個(gè)唯一鍵（uniq_col），我們對(duì)該表依次執(zhí)行以下三步操作：

1. 插入一行數(shù)據(jù)：insert into tab1 values(1,'a');
2. 按照唯一鍵刪除數(shù)據(jù)：delete tab1 where unique_col = 'a';
3. 插入一行 ID 為 2 的數(shù)據(jù)：insert into tab1 values(2,'a');

如圖7所示，當(dāng)上述變更通過(guò) OMS 下發(fā)至 Kafka 時(shí)，若采用 ID 作為哈希值，(1,'a') 和 (2,'a') 很可能不被分發(fā)到同一個(gè) Partition 中。在 Partition1 中，同時(shí)存在 insert 和 delete，而在 Partition2 中，只有一條 insert 記錄。

圖7 OMS 下發(fā)數(shù)據(jù)變化到 Kafka時(shí)可能存在的結(jié)果

由于下游消費(fèi)者在消費(fèi)消息時(shí)存在各種情況，可能不按照語(yǔ)句執(zhí)行順序進(jìn)行，無(wú)論下游的數(shù)據(jù)同步采取 insert into 模式還是 insert into ... on duplicate update... 模式，都有可能遇到 (2,'a') 數(shù)據(jù)丟失的情況。

如果下游的數(shù)據(jù)同步采用insert into 模式，在按照?qǐng)D8的順序消費(fèi)時(shí)，先插入 (1,'a')，再繼續(xù)消費(fèi) msg3 插入 (2,'a') ，此時(shí)由于 a 列沖突不再執(zhí)行，最后消費(fèi) msg2，導(dǎo)致 (2,'a') 數(shù)據(jù)丟失。

圖8 下游的數(shù)據(jù)同步采用insert into 模式

如果下游的數(shù)據(jù)同步采用 insert into ... on duplicate update... 模式（見圖9），先插入 msg3 即 (2,'a') ，后續(xù)基于 insert into ... on duplicate update 模式，在消費(fèi) msg1 時(shí)，一旦 a 列出現(xiàn)沖突，會(huì)將 a 列的值更新為1，最后消費(fèi) msg2，導(dǎo)致 (2,'a') 數(shù)據(jù)丟失。

圖9 下游的數(shù)據(jù)同步采用insert into ... on duplicate update...模式

上述 OMS 以主鍵 Hash 分區(qū)模式下發(fā) Kafka 在消費(fèi)時(shí)可能存在的問題，本質(zhì)是因?yàn)樵谥麈I Hash 分區(qū)模式下，不同 Partition 存在并發(fā)修改同一行時(shí)同時(shí)疊加了唯一鍵導(dǎo)致的。因此在上述 OceanBase 架構(gòu)下 OMS 將數(shù)據(jù)變更下發(fā)到 Kafka 的第二個(gè)方案中，消息按表還是主鍵 hash 分區(qū)取決于兩點(diǎn)：一是對(duì)高性能有無(wú)需求，二是如果下游的表沒有唯一鍵，也可以按照主鍵 Hash 分區(qū)方式進(jìn)行。

反向同步

圖10是業(yè)務(wù)切換前后的數(shù)據(jù)鏈路，不同顏色的鏈路代表不同的數(shù)據(jù)傳輸工具：紅色鏈路代表 Otter、藍(lán)色鏈路代表 OMS、綠色鏈路代表百麗自研的數(shù)據(jù)同步工具 SQLapplier、黑色鏈路代表其他工具。

圖10 業(yè)務(wù)切換前后的數(shù)據(jù)鏈路

切換前，業(yè)務(wù)數(shù)據(jù)通過(guò) OMS 同步到 OceanBase，OceanBase 通過(guò) OMS 下發(fā)到 Kafka。同時(shí)在上線前需要做數(shù)據(jù)同步測(cè)試，通過(guò) Kafka 將數(shù)據(jù)同步到測(cè)試 Oracle 和測(cè)試 MyCat，持續(xù)驗(yàn)證同步工具的性能和功能適配。

數(shù)倉(cāng)可以提前驗(yàn)證和切換。業(yè)務(wù)切換時(shí)，需要暫停應(yīng)用和上游業(yè)務(wù)的同步，此時(shí) MyCat 和 OceanBase 處于相對(duì)靜止的狀態(tài)。然后需要停止 OMS，將 Kafka 反向同步到 MyCat 和 Oracle，再將上游業(yè)務(wù)指向 OceanBase 即完成了切換過(guò)程。反向同步的意義在于，如果在切換初期出現(xiàn)任何問題可以及時(shí)回切，提高系統(tǒng)容災(zāi)能力。

第二步：數(shù)據(jù)校驗(yàn)

數(shù)據(jù)流轉(zhuǎn)完成后一般需要進(jìn)行數(shù)據(jù)校驗(yàn)，對(duì)于單庫(kù)遷移，可以直接使用 OMS 完成數(shù)據(jù)校驗(yàn)，在重復(fù)多次校驗(yàn)時(shí)，可根據(jù)數(shù)據(jù)不一致情況生成訂正數(shù)據(jù)。如果源端是 MyCat 的情況，可以搭建源端為 MyCat，目標(biāo)端是 OceanBase 的校驗(yàn)，但由于百麗使用了很多 Otter 工具，同時(shí)有一些 MySQL、Oracle的異構(gòu)數(shù)據(jù)庫(kù)校驗(yàn)需求，因此使用了內(nèi)部自研的工具（見圖11）。

圖11 使用自研工具進(jìn)行數(shù)據(jù)校驗(yàn)

數(shù)據(jù)校驗(yàn)基本原理

以圖12為例，如何校驗(yàn)對(duì)應(yīng)行數(shù)據(jù)在目標(biāo)端是一致的，即把各個(gè)字段拼成一個(gè)字符串，然后做 crc32 校驗(yàn)。如果兩端的 crc32 匹配，則源端和目標(biāo)端的數(shù)據(jù)一致。如果對(duì)某一端的數(shù)據(jù)做簡(jiǎn)單修改（如加一個(gè)空格），那么數(shù)據(jù)將會(huì)有很大的變化。對(duì)于整表來(lái)說(shuō)，將按照一定的行數(shù)拆成多個(gè) chunk，以 chunk 的維度進(jìn)行目標(biāo)端和源端的 crc32 比對(duì)。如果出現(xiàn)數(shù)據(jù)不一致的情況，將進(jìn)行重試，經(jīng)過(guò)多次重試后數(shù)據(jù)還是不一致時(shí)，會(huì)進(jìn)行分裂；如果多次分裂數(shù)據(jù)還是不一致，將最終轉(zhuǎn)換為上文行數(shù)據(jù)的暗行（字符串）來(lái)進(jìn)行校驗(yàn)。

圖12 例證校驗(yàn)對(duì)應(yīng)行數(shù)據(jù)在目標(biāo)端是一致的方法

數(shù)據(jù)校驗(yàn)問題匯總

圖13是將平臺(tái)中 OceanBase 作為源端，Oracle 作為目標(biāo)端的數(shù)據(jù)校驗(yàn)過(guò)程，在我們測(cè)試過(guò)程中一共發(fā)現(xiàn)了4個(gè)問題。

1. 業(yè)務(wù)數(shù)據(jù)異常。由于 MyCat 約束較小，隨著長(zhǎng)時(shí)間使用，以及有變更遷移數(shù)據(jù)等操作，可能會(huì)遺留一些歷史問題，例如 ID重復(fù)。
2. 唯一鍵約束范圍差異導(dǎo)致數(shù)據(jù)丟數(shù)。MyCat 的唯一約束只能約束到 DB 分區(qū)維度中的約束，但在 OceanBase 中是全局約束，這種差異也會(huì)導(dǎo)致數(shù)據(jù)丟失。
3. Kafka 消費(fèi) Hash 分區(qū)、下游唯一鍵約束丟數(shù)。
4. OBServer V4.2.5.2 之前 4K 大字段丟數(shù)。

圖13 將平臺(tái)中 OceanBase 作為源端，Oracle 作為目標(biāo)端的數(shù)據(jù)校驗(yàn)過(guò)程

數(shù)據(jù)校驗(yàn)覆蓋了數(shù)據(jù)治理和數(shù)據(jù)正確性、數(shù)據(jù)一致性校驗(yàn)，在上線前解決存在的數(shù)據(jù)異常問題，是一項(xiàng)非常重要的工作。

第三步：SQL 兼容及性能測(cè)試

在打通數(shù)據(jù)鏈路、完成數(shù)據(jù)校驗(yàn)后，需要解決的就是 SQL 兼容性和性能問題，例如如何對(duì)比 MyCat 和 OceanBase 的數(shù)據(jù)庫(kù)性能差異，OceanBase 性能是否能滿足我們的業(yè)務(wù)需求等。針對(duì)上述需求，一個(gè)樸素的方法是：可以將 MyCat 中所有SQL 在 OceanBase 中實(shí)現(xiàn)，即可完整地測(cè)試兼容性問題以及性能表現(xiàn)。

為此我們開發(fā)了流量回放功能，如圖14所示，通過(guò)數(shù)據(jù)庫(kù)管理平臺(tái)在各個(gè) DB 中采集全量日志，然后解析為 CSV 格式，最終將所有 CSV 文件整合即可形成解析報(bào)告，用于分析集群層面的整體 SQL 分布、DDL、DML 等情況。將 CSV 回放到 MyCat、OceanBase 后，形成回放對(duì)比報(bào)告。

圖14 流量回放的執(zhí)行過(guò)程

看到該過(guò)程的你可能會(huì)有兩個(gè)疑問：

1. 為什么用全量日志？全量日志的好處在于全局變量便于開關(guān)，如果發(fā)現(xiàn)性能有壓力，可以選擇關(guān)掉。
2. 為什么用 CSV 格式？這是因?yàn)榭紤]到兼容性問題。例如目前 OceanBase 能夠?qū)?SQL 轉(zhuǎn)成 CSV 格式，后續(xù)可以直接從 OceanBase 的 SQL Audit 中撈取 SQL，并以 CSV 的格式保存，同樣可以跑通回放流程。

回放報(bào)告

回放報(bào)告中的統(tǒng)計(jì)信息（見圖15）包括：將所有回放 SQL 進(jìn)行參數(shù)化形成模板生成對(duì)應(yīng)的 SQL ID；該 SQL 使用到的表；每個(gè) SQL ID 的最小響應(yīng)時(shí)間、最大響應(yīng)時(shí)間、平均響應(yīng)時(shí)間、執(zhí)行次數(shù)、錯(cuò)誤次數(shù)、對(duì)應(yīng) SQL 等。

圖15 回放報(bào)告中的統(tǒng)計(jì)信息

通過(guò)回放報(bào)告，我們可以進(jìn)行兼容性分析，確定優(yōu)化范圍和任務(wù)分配，并持續(xù)進(jìn)行回放，從而提升工作效率。

兼容性分析。通過(guò)比較源端和目標(biāo)端的執(zhí)行結(jié)果，檢查是否存在兼容性錯(cuò)誤。比如報(bào)告中顯示存在錯(cuò)誤，需要進(jìn)一步核實(shí)錯(cuò)誤原因是超時(shí)還是 SQL 語(yǔ)句本身不兼容，從而準(zhǔn)確定位 SQL 語(yǔ)句的兼容性問題。

確定優(yōu)化范圍。回放報(bào)告可以幫助我們確定需要優(yōu)化的 SQL 語(yǔ)句范圍。由于報(bào)告生成了大量 SQL 語(yǔ)句，并非所有 SQL 語(yǔ)句都需要優(yōu)化。報(bào)告中提供了每個(gè) SQL 語(yǔ)句的平均響應(yīng)時(shí)間、執(zhí)行次數(shù)等數(shù)據(jù)，通過(guò)這些數(shù)據(jù)可以評(píng)估 SQL 語(yǔ)句性能，從而明確優(yōu)化范圍。

任務(wù)分配。在確定了優(yōu)化范圍后，如何合理分配任務(wù)成為一個(gè)關(guān)鍵問題。最初，任務(wù)分配可以比較隨意，直接根據(jù) SQL ID 進(jìn)行分配，但在每周的慢查詢研討會(huì)中，我們逐漸發(fā)現(xiàn)這種分配方式可能導(dǎo)致工作效率低下。為了改善這種情況，我們利用之前收集的表組信息 tablelist ，以表組為維度進(jìn)行任務(wù)分配，這不僅提高了慢查詢治理的效率，也避免了重復(fù)工作。

持續(xù)進(jìn)行的回放。由于回放報(bào)告會(huì)多次回放，尤其是在流量變化較大的系統(tǒng)中，如財(cái)務(wù)系統(tǒng)在月初和月末的流量可能差異很大。因此，我們會(huì)從月初到月末持續(xù)抓取流量，并進(jìn)行多次回放。然而隨著報(bào)告數(shù)量的增加，橫向比較越來(lái)越不方便。為了解決這個(gè)問題，我們將報(bào)告整合到平臺(tái)中，并以 SQL ID 作為關(guān)鍵要素，將每次回放的報(bào)告串聯(lián)起來(lái)，以便于分析和比較。

SQL 持續(xù)治理及跟進(jìn)

圖16是我們平臺(tái)的 SQL 持續(xù)治理及跟進(jìn)面板的截圖，可以展示每條 SQL 在每一輪回放中的變化，每個(gè) DBA 只需要關(guān)注自己負(fù)責(zé)的 SQL 即可。例如圖中所示的 SQL，我們?cè)诟鶕?jù)表組進(jìn)行調(diào)優(yōu)后，可以看到它的最大響應(yīng)時(shí)間等數(shù)據(jù)明顯下降，證明回放報(bào)告對(duì)于 SQL 診斷和治理帶來(lái)的效率提升是非常直觀的。

圖16 平臺(tái)的 SQL 持續(xù)治理及跟進(jìn)面板

此外，值得一提的是OCP 有一個(gè)非常實(shí)用的功能，可以根據(jù)特定時(shí)間點(diǎn)恢復(fù)數(shù)據(jù)。在進(jìn)行壓力測(cè)試及流量回放過(guò)程中，可能會(huì)涉及對(duì)數(shù)據(jù)執(zhí)行 DML 操作，從而對(duì)數(shù)據(jù)造成修改。面對(duì)這種情況，OCP能夠迅速將數(shù)據(jù)恢復(fù)至某一時(shí)間點(diǎn)的數(shù)據(jù)副本，便于我們立即將數(shù)據(jù)投入使用。使用完畢后，可以將其刪除。對(duì)此，我們認(rèn)為這一功能極具價(jià)值。

SQL 問題分類

在進(jìn)行 SQL 治理和調(diào)優(yōu)過(guò)程中，我們共發(fā)現(xiàn)了四個(gè)問題。

問題1：部分SQL不兼容。

在 SQL 使用過(guò)程中，我們通常用“--”進(jìn)行注釋，放在 SQL 語(yǔ)句最后。在 MySQL 中一般不會(huì)發(fā)生報(bào)錯(cuò)，但在 OceanBase 中報(bào)錯(cuò)了，研發(fā)團(tuán)隊(duì)直接進(jìn)行了修改。值得肯定的是，在回放了大約4.5萬(wàn)個(gè) SQL ID 后，發(fā)現(xiàn)的不兼容問題僅有這一個(gè)，由此看出OceanBase 對(duì) MySQL 5.7 版本的語(yǔ)法兼容度是非常高的，基本無(wú)需在兼容性方面投入過(guò)多的工作量。

圖17 不兼容的SQL

問題2：RPC 代價(jià)高。

當(dāng)使用多組模式進(jìn)行查詢時(shí)，如果 SQL 涉及多個(gè) OBServer，可能會(huì)導(dǎo)致網(wǎng)絡(luò)開銷增大，特別是在處理大量數(shù)據(jù)的情況下，可能會(huì)顯著降低查詢效率。解決該問題需要進(jìn)行分片表表組設(shè)計(jì)或者對(duì)于相對(duì)穩(wěn)定的主數(shù)據(jù)表，設(shè)計(jì)復(fù)制表。此外，為了快速判斷是否為 RPC 問題，可以通過(guò)恢復(fù)一個(gè)單主環(huán)境，并在該環(huán)境中執(zhí)行 SQL，然后與多主環(huán)境進(jìn)行性能對(duì)比，從而有效判斷問題是否由 RPC 代價(jià)引起。

問題3：分區(qū)裁剪。

分區(qū)裁剪是另一類需要花費(fèi)大量時(shí)間進(jìn)行調(diào)優(yōu)的問題。例如，在涉及 DTL 訂單明細(xì)表的 order by 關(guān)聯(lián)查詢中，指定某個(gè)大區(qū)條件，在 MyCat 中沒有圖18所示紅框中的條件，這是因?yàn)?MyCat 的分區(qū)規(guī)則相同，即在物理層面進(jìn)行了隔絕，本來(lái)就在一個(gè)大區(qū)內(nèi)，所以不需要對(duì)大區(qū)進(jìn)行指定。而在 OceanBase 中，如果將這個(gè)條件去掉，會(huì)引發(fā) om 表正常進(jìn)行分區(qū)裁剪，但 od 表不知道需要在這個(gè)大區(qū)內(nèi)進(jìn)行，因此 OceanBase 需要指定這個(gè)條件以確保分區(qū)裁剪的正確性。這是一個(gè)非常典型的分區(qū)裁剪問題，其根本原因在于 MySQL 的機(jī)制在某些方面并不完善，原本物理隔絕的 SQL 在 OceanBase 是一個(gè)完整的庫(kù)，這就需要我們?cè)?OceanBase 中進(jìn)行相應(yīng)的調(diào)整和優(yōu)化。

圖18 補(bǔ)充分區(qū)條件

問題4：執(zhí)行計(jì)劃問題。

執(zhí)行計(jì)劃問題涉及幾個(gè)關(guān)鍵參數(shù)。

• partition_index_dive_limit 參數(shù)是 SQL 采樣分區(qū)參數(shù)，可能會(huì)影響執(zhí)行計(jì)劃的評(píng)估，如果采樣分區(qū)較小且數(shù)據(jù)為空，可能會(huì)導(dǎo)致采樣誤判，影響代價(jià)評(píng)估，建議根據(jù)實(shí)際需求將參數(shù)調(diào)大。
• 大小參數(shù)的問題，指同一 SQL 在不同變量下讀取的數(shù)據(jù)差異較大，但使用了相同的執(zhí)行計(jì)劃，可能會(huì)導(dǎo)致性能問題，此時(shí)可以使用 /+USE_PLAN_CACHE(NONE)/ 進(jìn)行規(guī)避，但這會(huì)使得每次執(zhí)行該SQL都硬解析，有額外的CPU開銷，需要綜合評(píng)估使用。
• 如果 in 參數(shù)過(guò)多，可能會(huì)導(dǎo)致硬解析時(shí)間過(guò)長(zhǎng)，此時(shí)可以適當(dāng)調(diào)整參數(shù)_inlist_rewrite_threshold，使 in 參數(shù)到達(dá)一定閾值后可以進(jìn)行改寫以避免硬解析的代價(jià)。

問題匯總

在實(shí)際應(yīng)用中，我們還遇到了一些其他問題：

• l- ocal rescan 計(jì)劃不優(yōu)，低代價(jià)的 nlj 計(jì)劃由于 local rescan 的規(guī)則被錯(cuò)誤裁剪，導(dǎo)致 SQL 最后走了高代價(jià)執(zhí)行慢的 hash join，該問題出現(xiàn)在 OceanBase V4.2.5.3 之前的版本，已經(jīng)在 OceanBase V4.2.5.3 版本修復(fù)。
• 調(diào)整 tablegroup，手動(dòng)發(fā)起均衡，若存在空分區(qū)，均衡計(jì)算可能會(huì)導(dǎo)致任務(wù)卡住，該問題出現(xiàn)在 OceanBase V4.2.5.3 版本，已經(jīng)在 OceanBase V4.2.5.4 版本修復(fù)。
• 包含復(fù)制表的 SQL，一定情況下會(huì)存在無(wú)法復(fù)用執(zhí)行計(jì)劃的情況，該問題出現(xiàn)在 OceanBase V4.2.5.4 版本，已經(jīng)在 OceanBase V4.2.5.5 版本修復(fù)。

切換收尾：平臺(tái)適配

我們內(nèi)部使用 Archery 工單平臺(tái)完成 SQL 的管理和發(fā)布，并且現(xiàn)有的 MySQL 等數(shù)據(jù)庫(kù)也都在使用 Archery 工單平臺(tái)，因此我們計(jì)劃使用該平臺(tái)接入 OceanBase。

目前，OceanBase 已經(jīng)對(duì)接了 goInception 項(xiàng)目（https://github.com/whhe/goInception），可以實(shí)現(xiàn) OceanBase 資源類型的工單回滾，即結(jié)合 OBServer 完成 SQL 的回滾操作。

在使用 Archery 平臺(tái)管理 MySQL 時(shí)，我們通常通過(guò) ptosc或 gos 等方式實(shí)現(xiàn) Online DDL 操作。然而，這種方式對(duì)于 OceanBase 的離線操作，可能會(huì)直接鎖表。

針對(duì)這種情況，我們期望達(dá)到的效果是：提交工單時(shí)，無(wú)論是 DBA 還是研發(fā)人員都能夠識(shí)別出操作是 Online 還是Offline。過(guò)去我們依賴于肉眼判斷，為了改進(jìn)這一流程，我們?cè)黾恿艘豁?xiàng)小功能：在提交工單時(shí)，我們會(huì)在測(cè)試環(huán)境中的 OceanBase 中運(yùn)行一遍，檢查 Table ID 是否發(fā)生變化。如果 Table ID 發(fā)生變化，則表明操作是 Offline 的；如果沒有變化，則表明操作是 Online 的，告警信息如圖19所示。

圖19 告警信息

這一設(shè)計(jì)雖然簡(jiǎn)單，但效果顯著，研發(fā)人員在提交工單時(shí)可以一目了然地知道操作是在線還是離線，大大提高了工作效率。

百麗核心系統(tǒng)為什么選擇OceanBase？

以上就是百麗財(cái)務(wù)系統(tǒng)從MyCat遷移至OceanBase的技術(shù)經(jīng)驗(yàn)總結(jié)，在此過(guò)程中，非常感謝 OceanBase 社區(qū)團(tuán)隊(duì)在我們項(xiàng)目測(cè)試及切換過(guò)程中的密切關(guān)注與大力支持。 那么，為什么我們會(huì)選擇OceanBase，而不是同樣作為開源分布式數(shù)據(jù)庫(kù)的TiDB、PolarDB……呢？

理由可以歸納為三個(gè)方面。

第一方面是OceanBase的技術(shù)優(yōu)勢(shì)：

• 可靠。Paxos 多副本機(jī)制，RPO=0，故障自動(dòng)切換，數(shù)據(jù)零丟失。
• 彈性。單機(jī)型與分布式模式可在線互轉(zhuǎn)；多租戶隔離；高壓縮比降低存儲(chǔ)成本；容量可按需橫向擴(kuò)展，無(wú)需提前重度預(yù)估。
• 統(tǒng)一。原生 HTAP，同一套引擎同時(shí)支撐 TP、AP、KV 及向量檢索，后續(xù)引入新負(fù)載無(wú)需新增技術(shù)棧。
• 易用。提供 OCP、OMS、ODC、OBAgent 等完整工具鏈，顯著降低部署、遷移、監(jiān)控、運(yùn)維門檻。

第二方面是社區(qū)活躍，OceanBase保持完全開源與快速迭代的風(fēng)格，對(duì)于用戶的問題及時(shí)響應(yīng)，確保了用戶的技術(shù)交流渠道暢通。同時(shí)，社區(qū)經(jīng)常開展技術(shù)交流活動(dòng)與培訓(xùn)課程，不斷加強(qiáng)用戶對(duì)于問題的解決能力。此外，用戶對(duì)于其版本發(fā)布節(jié)奏也是可預(yù)期的。

第三方面是行業(yè)驗(yàn)證，OceanBase在金融、運(yùn)營(yíng)商、零售等高要求行業(yè)規(guī)模化上線，歷經(jīng)核心系統(tǒng)長(zhǎng)時(shí)間運(yùn)行考驗(yàn)，穩(wěn)定性已經(jīng)得到大量企業(yè)的充分證明。