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

作者：楊家鑫，多點數據庫團隊DBA

在當今數字化轉型的大潮中，企業面臨着諸多挑戰，尤其是在零售SaaS場景下，數據處理的複雜性和成本問題尤為突出。作為零售數字化領域的先鋒，我們不僅是國內頂尖的全局數字化解決方案提供商，更在亞洲市場上佔據領先地位。我們擁有上百個全渠道系統，涵蓋會員管理、商品、營銷、O2O、POS系統、WMS物流、AI出清、AI導購等多個關鍵環節，為零售企業提供全方位的數字化支持。我們的客户遍佈國內、東南亞及歐洲等地，其中包括知名網紅商家、全國性頭部連鎖便利店、合資連鎖商超等。在業務高速增長的背後，我們也面臨着來自零售SaaS場景和業務系統瓶頸的挑戰。

本文將結合多點DMALL面臨的挑戰、OceanBase數據庫的優勢與選擇、多點DMALL應用OceanBase的實踐、OceanBase在多租户架構下的資源隔離實踐等內容，分享我們藉助OceanBase升級數據庫架構、簡化技術棧，從而實現降本提效的實踐經驗。

一、多點DMALL面臨的挑戰

（一）系統複雜度高

多點 DMALL 採用了微服務架構，其全流程業務環節繁多，系統應用規模龐大。與之對應的是，數據庫數量已然超過 500 個。此外，隨着系統持續迭代升級，數據規模呈現出不斷增長的態勢，這使得運維管理的難度日益增大。就如同在一張龐大而複雜的網絡中，每一個節點都承載着關鍵業務，牽一髮而動全身，運維人員需要時刻保持警惕，以應對可能出現的各種問題。

（二）業務增長快，水平擴展需求增多

隨着業務的蓬勃發展，我們積極制定了出海戰略，旨在海外開拓新的業務版圖。然而，基於地區數據安全法的嚴格要求，必須獨立部署一整套全新的系統來承接海外業務流量。在初始部署階段，由於難以精準預估後期業務規模以及數據增長速度，數據庫資源在初始階段的分配成為了一大難題。為了有效控制成本，常見的做法是先分配較少的部署資源。但很快，業務的快速增長帶來了數據的迅猛增長，此時如何快速實現擴容，成為了擺在面前的一道棘手難題。這就好比在高速行駛的列車上，突然發現前方軌道需要緊急拓寬，而時間卻十分緊迫。

（三）需要在同一個集羣中服務大量商家

便利店和連鎖商超的 SKU（最小存貨單位）規模差異較大，從幾千到幾萬不等。在這種情況下，很難為每個商家獨立部署一套系統。因此，我們的SaaS系統需要支持上百個中小商家客户，所有商家產生的數據在底層共享數據庫資源。這就如同在一個大倉庫中，不同商家的貨物需要合理存放和管理，既要保證各自的獨立性，又要充分利用倉庫的空間，實現資源的高效共享。

（四）資源成本高昂

零售作為與民生息息相關的行業，其業務系統必須保持全天候運行。無論是供應鏈的採購、銷售、物流環節，還是電商業務，除白天正常作業外，夜間乃至凌晨也依然活躍。這導致大量數據源源不斷地涌入數據庫，使得資源成本如同一條不斷上升的斜線，呈現出無限制增長的態勢。多點 DMALL 主要使用六種開源數據庫，在整個生產環境中，數據庫實例已超過一萬個，數據空間規模也接近 10PB 級別。如此龐大的數據量和複雜的數據庫環境，無疑給資源成本控制帶來了巨大挑戰。

（五）運維成本居高不下

在使用多種數據庫的過程中，我們遭遇了一系列棘手問題，包括技術複雜性帶來的難題、高昂的運維成本、煩瑣的管理成本、巨大的學習成本以及複雜的交付成本。一套私有化環境的交付涉及上百個系統，以及上百套數據庫集羣和數百個數據庫實例。這就好比搭建一座宏偉的建築，每一個部件都需要精心安裝和調試，任何一個環節出現問題都可能影響整個系統的正常運行，因此運維成本始終居高不下。

二、OceanBase數據庫的優勢與選擇

（一）分佈式數據庫的優勢

為了應對上述挑戰，我們開始了數據庫選型。由於分佈式數據庫支持更大的容量規模，具備透明擴展的能力，提供金融級數據安全，並且可以提高開發效率以及降低運維成本，能夠更好地支撐業務發展。因此，我們堅定地認為它是數據庫未來的趨勢，此次選型僅調研了分佈式數據庫產品。

（二）基於業務的選型考慮因素

首先，從擴展性角度考慮，我們面臨諸多挑戰。目前，多個 MySQL 單庫的數據量已超過 4 TB，並且仍在快速增長。當我們將最大的 MySQL 庫切換到分佈式數據庫後，數據量已增長至 29 TB。面對數據的快速增長及 MySQL 容量瓶頸，DBA （數據庫管理員）深感憂慮：

• 一方面，我們不斷敦促研發團隊進行數據清理和歸檔，但效果往往不佳，因為他們的主要工作是業務需求迭代，難以兼顧數據清理。
• 另一方面，考慮繼續擴展磁盤空間。在雲環境下，擴展空間相對容易，雲廠商提供的塊存儲單盤容量可達 32 TB 或更大。然而，數據持續增長，僅通過擴展磁盤空間只是將問題延後，無法從根本上解決問題，未來可能會面臨更大的困境。
• 此外，我們還可以選擇分庫分表的方案，但這操作煩瑣、風險較高，且需要耗時數月。因為該方案會損害 SQL 能力，代碼改造不可避免。

因此，我們期望利用分佈式數據庫透明且可擴展的能力，平穩支撐業務的快速增長。

其次，從運維成本角度考慮，在保證系統穩定性的前提下，我們致力於降低運維複雜度。以 MySQL 為例，假設一個數據庫（database）是一個“蛋”，一個 MySQL 實例是一個“籃子”，那麼部署 1000 個數據庫時，應該如何合理分配到多個 MySQL 實例中？哪些數據庫應該放在同一個實例中？如果將兩個對資源要求都很高的重要數據庫放在同一個實例中，可能會導致資源搶佔。另外，如支付類數據庫，雖然數據量不大，但對業務要求極高，也不宜與其他數據庫放在同一個實例中。由於業務差異、優先級不同、數據增長速度各異以及 QPS（每秒查詢數） 要求不同，DBA 經常需要調整數據庫分佈。即便不考慮資源成本，僅運維挑戰就已相當大。我們期望分佈式數據庫能夠解決這一問題，幫助 DBA 自動調整數據庫分佈（見圖1）。

圖1 使用分佈式數據庫實現“自動挪蛋”示意圖

最後，從高可用角度考慮，我們期望保證集羣的高可用能力。在運維 MySQL 集羣時，我們通常採用 MHA、Orchestrator 等工具實現高可用，但它們都是“外掛”形式，本質上無法解決網絡分區導致的腦裂問題（見圖2）。因為數據庫和 MHA 組件是兩個獨立的軟件，不在同一個進程內，缺乏一致性協同控制。相比之下，MySQL 的 Group Replication 這類高可用架構更為可靠，它與 OceanBase 或 TiDB 等分佈式數據庫一樣，基於 Paxos 或 Raft 分佈式一致性協議，可以實現 RPO=0（數據丟失為零），RTO<30s（恢復時間目標小於30s）的高可用目標。

圖2 使用分佈式數據庫實現“金融級高可用”示意圖

（三）產品選型測試數據

基於上述選型因素，我們選擇了原生分佈式數據庫 OceanBase，並進一步對比了 OceanBase 與 MySQL 在表讀寫、表只讀、表只寫等方面 QPS的表現，以及二者在存儲成本方面的差異。表1為此次產品選型測試的相關配置。

表1 產品選型測試的相關配置

在 OceanBase 與 MySQL 配置相同的情況下，對比了包含10張3000萬條記錄的sysbench表，我們發現：當併發數小於20時，MySQL的表現略好於OceanBase。但無論是QPS還是延遲，隨着併發數的增加，OceanBase的性能都會逐漸接近並可能超過MySQL。關於OceanBase不同配置的對比如下（見圖3）。

圖3 測試結果1

對於單機部署的模式，選擇通過連接OBProxy訪問OBServer還是直接連接OBServer，會影響其在10張3000萬條記錄的sysbench表讀寫QPS的表現。測試結果顯示，直接連接OBServer的性能比通過OBProxy連接的性能高30%~50%。因此，對於單機部署的模式，我們建議直接連接OBServer，以避免通過OBProxy訪問OBServer時產生的額外網絡開銷。

在不同租户內存配置下，性能也會有所不同。測試結果顯示，32GB租户內存相比16GB租户內存，性能提升約14%（見圖4）。

圖4 測試結果2

（三）OceanBase 與 MySQL 表空間對比

在生產環境監控快照場景中，我們將20張表共計5億數據量從MySQL遷移到OceanBase，發現表空間佔用降低了60%（見圖5）。

圖5 表空間對比結果

基於上述遷移過程中的測試數據，我們最終決定在生產環境中上線OceanBase。總的來説：

• 在生產環境監控快照場景中，對比MySQL存儲（單副本）和OceanBase存儲（單副本），我們發現OceanBase的數據壓縮率達到了6:1，顯示出OceanBase優秀的數據壓縮能力。
• 在單機部署並且連接OBProxy的情況下，當併發度較低時，OceanBase的QPS和平均延遲表現略遜於MySQL（但值得注意的是，OceanBase的最低QPS也過萬，且租户內存越高，QPS性能越好；最低平均延遲為3ms）。然而，隨着併發度的逐漸上升，OceanBase各項性能的提升比例高於MySQL。具體來説，當併發度超過200之後，OceanBase的各項性能會逼近甚至超過MySQL。
• MySQL採用一層架構，而OceanBase採用兩層架構（由OBProxy和OBServer組成）。在單機部署時，直接連接OBServer相比通過OBProxy連接，性能會提升30%~50%。這主要是因為每多一層架構，網絡層面的延遲消耗就會相應增加。

（四） OceanBase選用原因

OceanBase的選用原因如下。

(1) OceanBase是單機分佈式一體化數據庫。這意味着它在兩個方面具有顯著優勢：一方面，單機性能可以像MySQL單機一樣實現低延遲、高性能，滿足業務初期數據量較小時的極致性能需求；另一方面，分佈式特性使得我們在業務高速增長期可以輕鬆擴展，幾乎不受容量限制。這兩個特性共同解決了業務在全生命週期內對性能和擴展性的需求，無需改代碼、不停機即可遷移，並保證高性能。

(2) 作為原生的分佈式數據庫，OceanBase天然具備分片自動遷移和負載均衡的可擴展能力，能夠在業務無感知的情況下實現透明擴縮容。基於Paxos協議的極致優化，OceanBase 4.x版本進一步提升了系統可用性，可以做到RPO=0，RTO<8s。

(3) OceanBase通過最小化分佈式開銷的架構設計，保證了數據庫的高性能。同時，其高壓縮比相比MySQL可節省成本6倍以上。此外，OceanBase的多租户特性十分契合SaaS客户的業務場景，資源隔離和擴縮容操作非常容易。

關於分佈式數據庫的數據處理延遲和吞吐能力，我們需要明確以下幾點：內存中讀寫數據的延遲在0.1μs級別，SSD延遲約為0.1ms，機房內網絡延遲約為0.1ms，同城機房間延遲約3ms。內存的讀寫延遲與SSD、網絡之間相差了100~1000倍。在吞吐方面，內存讀寫可達到100GB/s，而SSD約為1～2GB/s，萬兆網絡約為1.2GB/s，內存與SSD、網絡之間的吞吐能力相差約100倍。

值得注意的是，MySQL作為單機數據庫，其InnoDB和Server層在同一進程中，數據交互非常高效，因此在性能和延遲方面表現出色。然而，對於分佈式數據庫而言，計算存儲分離架構往往帶來網絡I/O開銷，這是設計上的性能瓶頸。OceanBase的獨特之處在於其架構設計，將SQL引擎、存儲引擎和事務引擎實現在一個進程裏，OBServer既做計算又做存儲。應用通過OBProxy連接OBServer集羣，OBServer節點會把數據路由信息上報給OBProxy。OBProxy在接收到應用層SQL後，根據路由信息直接轉發SQL到最合適的OBServer上去執行（見圖6）。如果數據都在同一個OBServer節點上，那麼SQL執行過程就是單機的，類似於MySQL，從而最大程度減少了網絡I/O開銷。

圖6 OceanBase的架構設計

（五） OceanBase選用性能

當數據量較大或併發更高時，OceanBase的性能明顯優於MySQL。為了理解這一現象，我們對OceanBase的架構進行了深入研究。

(1) OceanBase同時兼具單機低延時和分佈式高吞吐的特性。在生產業務數據中，OceanBase的單機事務佔比可以達到80%以上。這是因為OceanBase中數據分片的粒度是一個表或分區。因此，當更新的只是一張非分區表，或者分區表的單個分區時，該事務必定是單機事務。更進一步，如果事務中涉及的多個表都在同一台機器中，那麼該事務也會是單機事務。

(2) 通過Table group機制優化跨機join，可以將部分跨機事務優化成單機事務。分區粒度的設計保證了大部分事務是單機的。再通過Table group機制優化高頻的跨機join後，單機事務佔比可以進一步提升。如果整個業務中有90%以上的事務都是單機事務，那麼性能自然會非常好。

(3) OceanBase系統通過區分查詢的優先級，使得小查詢優先執行。大查詢最多隻能佔用30%的工作線程，這一比例可以通過arge_query_worker_percentage配置進行調整。在沒有小查詢時，大查詢可以使用到100%的工作線程。這一機制類似於高速公路的通行規則。例如，如果高速公路有三條車道，並且三條車道都有車行駛，那麼後車很難超車。如果制定一個規則，讓大車（大查詢）只能走最右側車道，而小車（小查詢）還有兩個車道可以通行，那麼這樣的運行機制就能有效地預防慢SQL或大查詢堵塞或拖垮系統。

以上三點，源於OceanBase的架構設計以及在實踐中的不斷優化，這些是保證其高性能的關鍵因素。那麼，為何OceanBase能在擁有更高性能的同時，還能實現更低的成本呢？

（六）OceanBase選用成本

OceanBase採用了LSM-Tree存儲引擎，這一引擎同時支持編碼壓縮和通用壓縮，因此具有極高的壓縮比。根據我們的測試數據（見圖7），OceanBase的集羣存儲空間相比MySQL可節省高達75%，從而實現了更低的成本。

圖7 OceanBase與MySQL表空間與集羣總存儲空間測試數據

隨着多點DMALL服務業務的快速發展，數據量急劇增加，節點數也呈現指數級增長。在這種情況下，MySQL的成本很快就會超過OceanBase。我們在真實生產環境中得到的測試數據顯示，OceanBase的壓縮比高達6倍（見圖8）。未來，隨着業務數據的持續增長，OceanBase可以不斷地添加新節點，而其存儲成本的增長速度將遠遠慢於MySQL。

圖8 OceanBase與MySQL成本測試數據

三、多點DMALL應用OceanBase的實踐

（一）OceanBase在多點DMALL業務場景中的優勢

總結而言，OceanBase數據庫主要有四大優勢。

(1) 存儲成本更低。OceanBase之所以存儲成本更低，是因為它不僅採用了通用的壓縮算法，還應用了先進的數據編碼技術。根據我們的實踐經驗，將MySQL數據庫遷移至OceanBase後，單副本的壓縮率可接近90%，這一數據表現極為出色。

(2) 混合部署更穩定。OceanBase之所以在混合部署方面表現更穩定，是因為它不僅能實現租户間的資源隔離，還能在租户內部進一步設置隔離措施，有效限制用户或庫級別的I/O和CPU消耗，從而確保系統的穩定運行。

(3) 兼具低延遲和高併發的特性。OceanBase之所以能同時支持低延遲和高併發，其中一個重要原因是其可配置Primary Zone的功能。通過將主副本集中在一個OBServer節點上進行讀寫操作，類似於單機MySQL的讀寫模式，從而能夠提供更低的延遲和更優的性能。而當需要應對高併發場景時，OceanBase可以靈活配置副本在多個Server節點間進行負載均衡，以支持更高的併發量。

(4) 周邊工具更加完善。我們廣泛利用多台服務器的I/O和CPU資源，其中OCP管理平台發揮了至關重要的作用。OCP管理平台集成了監控告警、備份恢復等豐富功能，無論是常見的還是複雜的需求，都能一應俱全地滿足。在問題排查過程中，它提供的Top SQL、Slow SQL和可疑SQL分析功能尤為實用。此外，OMS數據同步功能也非常強大，支持將多種數據源的數據輕鬆同步至我們的OceanBase數據庫。

（二）從MySQL到OceanBase的遷移實踐

截至目前，我們已在OceanBase上成功部署了五個業務庫，總數據量達到20TB。這些業務對商家至關重要，特別是對於大型客户而言，他們的倉庫與門店緊密相連，需要24小時不間斷運營，包括凌晨時段。這些只是當前的部分應用場景，未來我們將繼續擴大OceanBase的應用範圍，將更多業務遷移到OceanBase平台上。

(1) 存儲成本收益顯著。當我們將業務從MySQL遷移到OceanBase時，MySQL中原本2.1TB的單副本數據量，在OceanBase中鋭減至252GB。這一顯著變化得益於OceanBase的通用壓縮和數據編碼技術，使得壓縮率接近驚人的90%。考慮到MySQL採用一主兩副本架構，而OceanBase採用三副本架構，綜合計算下來，OceanBase的整體壓縮率為我們帶來了超過80%的成本節省。這不僅體現在存儲成本上，還顯著降低了運維成本。

(2) 運維更加便捷。首先，分佈式數據庫的擴展能力相比集中式數據庫在運維上更為簡單。對於DBA來説，維護並遷移一個20TB規模的數據庫，在MySQL環境下至少需要40套每套1TB的MySQL實例，且遷移過程會有損，導致現有數據庫連接全部中斷，需要至少一名DBA全程參與。然而，在OceanBase中，由於其支持動態擴縮容和無損變更，我們只需擴容OBServer存儲節點，並將域名解析到新的OBProxy上，即可實現無損遷移。此外，OceanBase基於Paxos協議，確保了數據的強一致性和安全性。其次，藉助可視化管控工具，運維工作更加便利。OCP提供了備份、告警的可視化管理，以及良好的可觀測性，包括Top SQL、Slow SQL的監控，並且原生支持高可用架構。為了確保管理的獨立性和數據的清晰性，我們額外建立了一套與業務數據庫分離的元數據數據庫來支持OCP管理平台。

目前，OceanBase中的TPS已達到近1500，而QPS的最高值也接近3000，表現出卓越的性能。

（三）OceanBase的持續進化與未來展望

OceanBase自4.0版本起，已支持單機與分佈式一體化架構。4.2版本正式引入了OBKV Redis支持，進一步豐富了其功能。而最新的4.3版本，更是新增了對向量化引擎和列存的支持，這一引擎正是構建AI大模型的重要基石。OceanBase正不斷進化，符合未來數據庫的設想。

未來，我們將積極探索在更多業務場景中應用OceanBase，包括將關係型MySQL與非關係型Redis數據庫遷移到OceanBase平台。通過這一遷移，我們可以有效控制資源成本的持續增長，優化資源配置，進而直接提升利潤空間。

四、OceanBase在多租户架構下的資源隔離實踐

（一）租户之間的資源隔離能力

OceanBase的多租户架構在CPU、內存、I/O等資源上實現了物理級別的隔離。這一特性至關重要，它確保了不同租户之間的業務不會因資源爭搶而相互影響，從而避免了因單個業務的問題而波及到其他租户的風險。

（二）租户的快速彈性伸縮能力

在OceanBase中，租户的擴容操作極為便捷。以擁有3個Zone、每個Zone包含2台機器（共6台機器）、每台機器含有1個資源單元的租户為例，若需進行水平擴容，僅需執行一條SQL語句，即可輕鬆添加Zone 4和Zone 5，使資源單元從6個增加至10個。同樣，垂直擴容也簡單易行，如初期配置的資源為2C8G，隨着業務增長，若不想增加機器，只需將資源單元從2C8G升級為6C12G。這些擴容操作都是動態且無損的，業務運行完全不受影響。對於DBA而言，整個擴容過程僅需一條SQL語句即可完成，極大地減輕了工作量。因此，OceanBase的多租户能力完美契合了SaaS場景下的需求，既節省了成本，又方便了後期的擴容操作。

五、總結

在面對零售SaaS場景下的諸多挑戰時，我們選擇了OceanBase數據庫作為解決方案。OceanBase憑藉其分佈式架構、高擴展性、低運維成本、高可用性以及優秀的存儲壓縮能力等優勢，成功幫助我們實現了租户間資源的完全隔離與低成本系統升級。通過從MySQL到OceanBase的遷移實踐，我們不僅大幅降低了存儲成本和運維成本，還提高了系統的穩定性和性能。同時，OceanBase在多租户架構下的資源隔離實踐的應用，為我們的未來發展提供了有力的支撐。隨着技術的不斷髮展，我們將繼續與OceanBase攜手共進，推動新零售行業的數字化轉型和升級。

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

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