本文摘自《OceanBase社區版在泛互場景的應用案例研究》電子書，獲取完整版內容可直接點擊鏈接。

作者：馬琳，萬家數科數據庫專家。

從性能到擴展性：華潤萬家數據庫系統面臨的挑戰

（一）華潤萬家與萬家數科企業概況

華潤萬家是華潤集團旗下優秀零售連鎖企業，業務覆蓋中國內地及香港市場。面對萬家眾多業務需求和互相關聯的業務環境，集團亟需加強各業務耦合性，以適應線上、線下、物流、財務等各個業務環境的快速發展。在這樣的背景下，華潤萬家成立了下屬信息科技公司——萬家數科商業數據有限公司。公司聚焦於零售領域，在服務華潤萬家的同時，市場化運營發展，為零售商及其生態提供核心業務系統的整體解決方案與運維服務。

圖1 華潤萬家集團概況

隨着信息技術的快速發展和數字化轉型的推進，數據庫作為數據管理和存儲的基石，正扮演着越來越重要的角色。華潤萬家希望通過數據庫數字化升級及創新技術和智能化應用，為企業提供高效、可靠和安全的數據管理解決方案。對此，萬家數科積極響應國家、集團以及華潤萬家自身信息安全的戰略規劃，通過引入自主研發的數據庫系統，以實現關鍵業務的持續支撐，智能化運作，提升業務系統運營效率，繼而提升終端消費者的服務質量，實現“降本-增效-風險合規”的高效循環，助力萬家適應複雜多變的市場環境和業務可持續發展，為公司在激烈的市場競爭中贏得先機。

（二）傳統數據庫現狀及使用痛點

1.傳統數據庫現狀

傳統數據庫系統如MySQL、Oracle等，在數據存儲和處理方面發揮了重要作用。然而，隨着互聯網和移動設備的普及，數據量呈現爆炸性增長。為了應對數據暴漲趨勢，許多企業採用擴展架構的方式來提高和擴展傳統數據庫的性能和容量。其中，MySQL是非常流行的擴展架構。常用的MySQL架構主要有以下三種。 第一，主從複製架構。通過複製數據到一個或多個從服務器來提高性能和容量。

圖2 MySQL主從複製架構

第二，分庫分表架構。將數據分散到多個數據庫實例中，以實現水平擴展。

圖3 MySQL分庫分表架構

第三，讀寫分離架構。將讀操作和寫操作分別分發到不同的數據庫實例，以提高併發性能。

圖4 MySQL讀寫分離架構

MySQL擴展架構通常出現在業務膨脹的情況下，上述三種架構仍無法保證業務穩定時，可以通過分庫分表與讀寫分離綜合運用的方式來解決性能問題。

圖5 MySQL擴展架構

需要注意的是隨着集羣膨脹架構複雜度上升，其運維開發成本急劇上升，將面臨各種問題。如木桶效應：一塊“短板”拖累整個系統穩定。

2.傳統數據庫在華潤萬家業務中的使用痛點

華潤萬家於1984年在香港成立了第一家門店，至今已有40年曆史。在整體零售業務的發展的過程中，集團系統從最初簡單的進銷存系統演變為如今多套系統的配合，如物流供應鏈，會員系統、線上業務系統等。但新老系統的交替運行積攢了各種各樣的問題，這些問題與傳統數據庫自身存在的侷限交織在一起，可以分為以下幾類。

（1）性能瓶頸：在面對大量併發請求時，傳統數據庫的性能會受到限制。如監控系統中有幾百台主機、1~2W監控項時，後台數據庫還遊刃有餘。擴展到上萬台主機、50~100W監控項時，MySQL出現大量數據延時，嚴重時延時超過30分鐘，此時監控數據已無實際意義。

（2）擴展性限制：傳統數據庫在擴展性方面存在一定限制，難以滿足不斷增長的數據需求。如硬件方面，受制於CPU內存存儲限制，隨着數據量增長會導致數據庫性能下降，響應時間增加等問題。為了保證數據庫健康，我們必須時刻監控數據量，定期清理數據。這實際是對數據庫性能的妥協，因為對於業務來説盡可能地保證數據可查可用是最理想狀態。同時隨着系統規模的不斷擴展，代碼的複雜度增加，導致維護難度加大。如果擴展系統，不僅需要投入大量的資金，還需要大量的人力資源支持，企業要面臨的成本壓力極大，這也成為了限制企業發展的主要矛盾。

（3）高可用性不足：傳統數據庫在面臨故障時，往往難以保證高可用性，影響業務連續性。華潤萬家在集羣高可用性上做足了各種準備，主從架構、多從、分庫、異地災備等傳統新型方案均有設計。但在極端狀態下其RTO時間也需要10分鐘至半小時。某些情況下需要人為判斷系統是否必須切換，對於風險等級業務重要度更高的數據庫操作，需要整個團隊共同分析、判斷。

（4）多系統並行：隨着華潤萬家業務發展階段的演變，系統也從最初的套裝系統轉變為Java定製開發，使用了多種不同的數據庫，如IBM informix、Oracle、MySQL等。不同數據庫的差異化非常大，以至於不同團隊需要頻繁溝通，制定統一交互協議，確保數據流轉順暢，這會耗費大量的時間和精力。同時，由於各個系統之間的技術架構、數據格式、接口規範存在差異，需要定製化開發適配器和中間件，增加了集成難度。隨着業務量增長，各業務系統之間的資源耗費也隨之加劇，帶來了成本壓力，各團隊需要合理分配硬件資源、網絡帶寬，優化系統配置，減少資源衝突，提升整體性能。

（5）用户體驗降低：系統用户分為內部用户和外部用户，總體而言存在三點體驗痛點。首先，不同用户對系統的功能、界面、操作方式等有不同的需求，滿足個性化需求難度較大。其次，用户要求系統的響應速度越來越快，尤其是在高併發情況下，但保證系統的快速響應是一個挑戰。第三是易用性，系統的複雜功能可能導致用户操作困難，降低用户體驗。

（6）維護困難：一方面，傳統數據庫需要投入大量人力物力進行維護和管理。另一方面，由於各系統在數據傳輸過程中存在各種各樣的問題。導致故障點難定位，需要經過多環節排查，增加修復時間，且鏈路中某環節容易造成瓶頸，影響整體性能，需要優化資源配置。運維人員使用監控手段定位問題，然而某些監控盲點需要一個更強大的運維團隊做實時分析，這十分考驗監控運維團隊對業務的理解能力。

（7）安全性問題：傳統數據庫的安全性通常是關注的重點之一，需要採取多種措施來確保數據的安全性。如備份恢復問題，MySQL數據庫在備份恢復方面缺乏整體解決方案，導致備份不完整、備份文件丟失或損壞、恢復時間長等問題。又如，在基於中間件的MySQL架構中，審計問題困難較大，對用户訪問、數據修改查詢等操作的跟蹤是較為棘手的問題，通常很難查到歷史問題SQL的發起者。上一點提到的複雜鏈路業提升了被攻擊的風險。

數據庫選型：MySQL與OceanBase各項測試對比

基於以上種種痛點和挑戰，近年來較為火熱的國產自研數據庫進入華潤萬家的調研視野。在選擇數據庫時，我們主要考慮以下幾點。

• 符合自主研發需求：數據庫為完全自主研發具有自主知識產權的國產數據庫，同時適配自研系統兼容性要求。
• 兼容性：與現有系統的兼容性（數據庫如MySQL、Oracle，操作系統如CentOS、RedHat等），包括協議、數據格式和API等方面。
• 高可用性：節點故障處理、容災能力和數據可擴展性：節點擴展、數據分區和負載均衡等。
• 性能：讀寫速度、併發處理和數據處理能力。
• 成本：遷移成本、開發成本、主機存儲成本等。
• 業務耦合性：不同場景下與各個業務的耦合性，表現為應用適配，以及SQL在不同場景中的性能抖動。

基於上述原則，萬家數科技術團隊選擇了兩款國產數據庫進行了基準測試和壓力測試，觀察二者在性能、成本及兼容性方面的表現。

（一）基準測試性能對比

由於對比的數據庫架構不同，為保證公平性，我們以總CPU及總內存作為基本參數，不以主機數量為評判。系統主機規格：總CPU64C、總內存256GB，測試結果如圖6、圖7。

圖6 OceanBase與某分佈式數據庫的性能測試結果對比

從測試結果看，OceanBase對比某分佈式數據庫，在oltp_update_index場景下，OceanBase不同併發下QPS幾乎都是200%或以上；在oltp_read_only、oltp_read_write、oltp_update_non_index、oltp_insert場景下，OceanBase表現更優，不同併發下平均提升40%的QPS；在oltp_point_select、oltp_write_only場景下，不同併發下兩款數據庫性能各有優劣，總體性能持平。

圖7 OceanBase與某分佈式數據庫性能對比細節

（二）壓力測試對比

壓力測試的環境和基準測試環境相同，測試結果如圖8、圖9。

圖8 OceanBase與某分佈式數據庫的壓力測試對比結果

從業務壓測結果來看，OceanBase表現更優，對比某分佈式數據庫，寫業務的QPS是其2倍，查詢業務的QPS是其4倍；但延遲僅為其1/4。

圖9 OceanBase與某分佈式數據庫壓測對比細節

根據各項對比結果來看，OceanBase的表現均為最優，並且使用OceanBase能夠最大化利用技術存儲資源，降低碎片化資源，對比MySQL可降低存儲成本約60%，保守測算綜合成本可降低30%。其他項如兼容性、高可用性、可擴展性，兩款數據庫差別不大，如圖10所示。

圖10 OceanBase與某分佈式數據庫其他項目對比

經過對比，華潤萬家最終選擇將原有數據庫替換為原生分佈式數據庫產品OceanBase。

引入OceanBase，性能提升70%，成本效益顯著

（一）OceanBase遷移過程

2022年6月，萬家數科引入OceanBase 3.x版本，並開始POC測試、核心系統驗證。直至2022年12月，我們瞭解到單機分佈式一體化的OceanBase 4.0版本即將發佈，便等到新版本發佈後及時跟進了系統遷移測試。經過幾個月生產環境的上線實踐，取得的效果讓我們非常滿意。在2024年，我們將大批系統遷移到OceanBase數據庫，將其作為技術底座。

包括新項目的生產開發與舊項目的遷移在內，目前萬家數科已有五六十個項目使用OceanBase，未來將有更多的項目建立在OceanBase數據庫之上。

（二）OceanBase遷移經驗解析

在引入OceanBase數據庫方案的初期，萬家數科技術團隊選定了華潤萬家的某核心業務系統作為數據庫升級改造對象。我們使用了OMS進行數據庫遷移方案，而原MySQL集羣是基於中間件的多實例分庫分表集羣。

OceanBase遷移服務（OceanBase Migration Service，OMS）是OceanBase數據庫提供的一種支持同構或異構數據源與OceanBase數據庫之間進行數據交互的服務，具備在線遷移存量數據和實時同步增量數據的能力。OMS提供可視化的集中管控平台，只需要進行簡單的配置即可實時遷移數據。OMS可以低風險、低成本、高效率地實現同構或異構數據庫向OceanBase進行實時數據遷移和數據同步。OMS的優勢包括以下幾點。

• 支持多種數據源。OMS支持MySQL、Kafka等多種類型的數據源與OceanBase數據庫進行實時數據傳輸。
• 在線不停服遷移，業務應用無感知。在不停服的情況下，可以通過OMS無縫遷移數據至OceanBase。應用切換至OceanBase後，OceanBase數據庫上所有的變更數據會實時同步至切換前的源端數據庫。
• 高性能、安全可靠的數據遷移。OMS能夠準實時實現異構IT基礎結構之間大量數據的秒級延遲複製。因此可以應用於數據遷移、跨城異地數據災備、應急系統、實時數據同步、容災、數據庫升級和移植等多個場景。OMS能夠實現在業務應用無感知和不中斷的前提下，運行數據遷移和數據同步任務，並保證數據的完整性和事務的一致性。全量遷移性能可以達到100 MB/s，20萬TPS，數據同步性能可達50000RPS。同時，OMS提供高可用的部署架構方案，為數據遷移和實時同步提供穩定可靠的傳輸任務。
• 一站式交互支持數據遷移的全生命週期管理。可以在管理控制枱界面操作完成數據遷移任務的創建、配置和監控，交互簡便。
• 實時數據同步助力業務解耦。OMS支持OceanBase兩種租户與自建Kafka、RocketMQ之間的數據實時同步，可應用於實時數據倉庫搭建、數據查詢和報表分流等業務場景。
• 多重數據校驗。OMS提供多種數據一致性校驗方式，更加全面、省時、高效地保證數據質量。同時展示差異數據，提供快速訂正途徑。

我們首先進行了遷移評估，對現有數據庫的性能、可用性和可擴展性等方面進行評估，並確定遷移目標和計劃。其次，根據評估結果制定詳細的遷移方案，包括數據備份、數據轉換、節點遷移和測試等。最後，在完成遷移融合後，需要對新系統進行長期的監控和維護，確保其穩定運行並滿足業務需求。

1. 遷移評估

該系統使用基於中間件的MySQL讀寫分離分庫分表集羣，架構如圖11所示。

圖11 某系統原有MySQL架構

該數據庫採用5實例，每個實例10個分庫，共50分庫；每個實例兩從庫，使用中間件合併為一邏輯庫讀寫分離。

評估時，我們首先估算了系統性能。實際生產核算15TB數據量。併發量估算3000併發。高頻SQL通過後台監控抓取Top50。其次評估可用性及可擴展性。基於中間件的MySQL架構的擴展性已有極大提升，通過添加新的MySQL集羣及中間件路由配置可快速擴展集羣容量及集羣算力，但在集羣擴容期間仍需短暫停機。第三，評估遷移後數據量。預估遷移後大約6TB數據，OceanBase數據庫需最少7TB數據盤保證數據空間健康。第四，裝載測試數據進行高頻SQL壓測，驗證數據庫承載情況。第五，評估分析系統關聯業務，對每一個關聯業務進行詳細地摸底排查，逐一驗證。

通過模擬評估，我們驗證了使用新系統的可行性，預估使用OceanBase數據庫資源量CPU、內存、硬盤等初步數據。

2. 遷移方案

對於7*24小時運行業務，穩定運行階段如何能實現業務無感知平滑遷移是這次的遷移難點。為此，萬家數科技術團隊設計了巧妙的步驟分步遷移數據庫。我們按照讀寫分離策略，先遷移讀業務，後遷移寫業務，保證系統穩定、平滑地過渡至新系統。最大程度保證用户無感知。

圖12 某系統遷移過程

MySQL分庫分表集羣遷移OceanBase需考慮合庫問題，如何合庫合表是遷移難點。需對每張大表檢查驗證，確認每條數據的唯一性，並配置合適的大表分區鍵，確認熱點SQL的性能最優。同時也要考慮歷史數據能夠快速卸載，保證運維清理能夠簡單高效。對此，我們對數據庫進行了詳細地分析和驗證，確定遷移改造方案。

該業務大表主鍵使用雪花算法，這種算法只能保證每一個DB有唯一性，在多個DB中有極小的概率會存在主鍵衝突。對於這種問題，如果是小表，可以通過查詢、排除主鍵的方式來更改；如果是幾十億上百億數據量的大表，使用排除主鍵法是不可行方案，會耗費大量資源。因此我們對主鍵做了一些改造，拋棄現有基於雪花算法的主鍵，新增了自增主鍵，並對所有DB的自增鏈設置了一個範圍的起始值，如圖13。這樣能夠保證在一定時間內數據庫的主鍵不會衝突。而在這個時間段內，需要儘快合庫合表並完成遷移。

圖13 業務大表遷移方法

在切割方案中，我們對讀寫業務進行應用改造以適配雙數據源，設置合理的規則，在整個遷移過程中分批次進行業務遷移，直到遷移完成，如圖14。

圖14 遷移切割方案

這樣做的好處是可以把整個業務的遷移風險降到最低。第一步只是利用小部分流量做遷移測試，確定沒問題後再進行後續步驟，逐一遷移讀寫業務。每步遷移過程在10秒內即可完成業務遷移，對業務影響極低。

3. 流數據實時處理

在數據庫業務關聯數據流的處理中，Kafka的使用是非常關鍵的。Kafka的存放格式有很多，其中Canal、Shareplex等是業內使用較多的格式。這些格式在OceanBase中得到了廣泛支持，使數據流轉更加穩定可靠，同時也極大地降低了遷移開發的成本。OMS為這些格式提供了全面的支持，使數據流轉過程更加順暢，不再是一個棘手的問題。

Debezium格式是萬家數科在推進Flink生態時所採用的統一格式，而當時OMS V3版本不支持此格式，如果為此進行改造，涉及的上下游鏈路非常多，預估改造工作量巨大。經過溝通，OceanBase-OMS開發團隊針對Debezium格式進行了相應的開發與適配，保證了我方項目的順利進行，在此感謝OceanBase技術團隊的傾力支持。

過去，我們基於BinLog日誌變更使用kafka-connector監聽對集羣數據進行實時捕獲。需對每個MySQL節點進行日誌監聽，維護複雜難度大。任務調度不能保證實時性，推送延時大，業務量龐大時存在推送不及時、可靠性較差，如圖15。

圖15 原有任務調度模式

遷移到OceanBase後，我們基於OMS+Flink調度的流數據實時處理，取代了此前基於MySQL+Kafka的延時較高的任務調度模式，如圖16。

圖16 基於OMS+Flink的流數據處理

OMS提供可視化的集中管控平台，界面化操作，可以基於時間點同步，維護成本低。同時我們使用Flink流實現實時數據處理邏輯，通過Flink的StreamSink和TableSink將處理後的數據實時推送到目標系統，確保目標系統支持實時數據的接收和處理。其checkpoint機制可實現任務的持續檢查和恢復，在任務運行過程中定期檢查checkpoint狀態，可確保任務在異常情況下能夠恢復到一致的狀態。

OMS+Flink方案保證了用户操作簡單和數據實時性，整個數據流轉可在2s內完成，保證每一筆數據消費都能準確實時可靠地推送至每一個用户。

4. 遷移融合成果

經過多次充分準備和驗證，我們成功將萬家某核心系統遷移融合至OceanBase數據庫平台。在遷移過程中，用户無感知，業務系統穩定運行。經過實際生產驗證，OceanBase較原系統性能提升約70%，成本降低約50%，本次遷移融合項目取得了圓滿成功。

（三）OceanBase優化案例解析

利用OceanBase豐富的生態體系，我們還極大簡化了監控運維的工作，不僅提升了運維管理細粒度，還提高了運維效率。

以OCP和ODC的性能優化為例。

1.問題出現

某日凌晨，業務人員反饋在程序發佈後，新增業務需求執行效率低下，該場景在UAT環境中性能穩定，但上線後效率較之前降低幾倍，造成業務單據壓單，無法實時處理業務單據。

2.問題分析

OCP：通過OCP-SQL診斷功能，發現該時間點TOPSQL中無明顯慢SQL，通過與開發溝通得知該場景為高頻SQL場景，平均響應時間慢幾毫秒均會對業務產生影響，隨即確定問題SQL。發現其並無相關索引問題呈現。 ODC：將問題SQL在ODC執行查詢其實際執行計劃，定位問題發現SQL存在較多RPC調用，如圖17。

圖17：ODC性能問題

3.問題解決

新建表組避免RPC調用。圖18為建立表組後的SQL執行計劃基本信息，可見已沒有RPC調用。

圖18 ODC性能問題解決方法

（四）OceanBase遷移收益

我們將遷移後的具體收益總結為以下5點。

• 成本節約：高壓縮存儲技術，原存儲遷移後容量降低約60%，硬件成本節約50%，業務綜合成本節約25%左右。
• 資源有效利用率提高：使用集羣匯聚多個實例，多租户資源隔離，減少資源碎片，充分利用資源。
• 改善業務韌性，開發效率提升：優化業務架構，統一技術棧，降低開發難度，提升開發效率，增強業務穩態和擴展性。相比此前整個運維團隊都忙於穩固MySQL集羣，現在大家輕鬆多了。
• 性能提升：解除當前架構中的性能瓶頸，系統性能提升70%，同時支持實時報表查詢，減少了數據鏈路開發與維護的工作，兼備混合分析場景的支持。
• 運維效率提升：數據庫平台化管理，支持DBA白屏化操作，提升了運維效率，降低了運維工具開發和運維成本。

未來展望

未來，萬家數科技術團隊將致力於構建一套完整規範的數據庫體系，加強團體培養建設，充分發揮其優勢，優化資源配置和監控運維機制，實現降本增效與業務可持續發展的目標。

最後為大家推薦這個 OceanBase 開源負責人老紀的公眾號「老紀的技術嘮嗑局」，會持續更新和 #數據庫、#AI、#技術架構 相關的各種技術內容。歡迎感興趣的朋友們關注！

「老紀的技術嘮嗑局」不僅希望能持續給大家帶來有價值的技術分享，也希望能和大家一起為開源社區貢獻一份力量。如果你對 OceanBase 開源社區認可，點亮一顆小星星✨吧！你的每一個Star，都是我們努力的動力。