今天，我們邀請了智慧油客的研發總監黃普友，為我們講述智慧油客與 OceanBase 初識、熟悉和結緣的故事。

---

智慧油客自2016年誕生以來，秉持新零售的思維，成功從過去二十年間以“以銷售產品為中心”的傳統思維模式，轉向“以運營客戶為中心”，并且依托智能大數據，驅動業務精準運營，致力于推動能源零售行業實現全面的產業升級。智慧油客全棧 SaaS 服務體系目前已幫助數萬加油站完成產業升級，為加油站提供了全新一代的自動化智慧油站運營服務，集進銷存業務運營、會員客戶管理、自屬移動互聯網平臺營銷、聚合支付、財務管控、大數據和人工智能分析等技術為一體。目前已覆蓋全國 30 個省級行政區，服務 1 萬多座油站、3000 多萬車主，每天訂單量超過 100 萬單。

初識 OceanBase

2021 年中旬，機緣巧合之下，智慧油客接觸到國產分布式數據庫產品 OceanBase，經過那次溝通交流，我對 OceanBase 有了簡單的了解和認識，原來當年阿里的去 IOE、每次雙十一大促的數據庫功臣叫 OceanBase，其經歷了 11 年的自主研發，是螞蟻全棧都在使用的一款企業級原生分布式數據庫。

這次交流后，我對 OceanBase 一些特性比較感興趣，如高可用、高性能、可擴展、低成本、云原生、高度兼容 SQL 標準和主流關系型數據庫生態等特點，對于企業比較吸引人，同時它也是全球首家通過 TPC-C 和 TPC-H 測試的分布式數據庫。

隨后我去查看了 TPC 的官方網站：TPC-C 連續兩年蟬聯第一，超越 Oracle 性能 20 多倍，這個結果對于一款純國產數據庫來說，頗有一些揚眉吐氣的感覺，霸榜多年的 Oracle 被中國的產品完勝超越。

在當時的時間點，智慧油客正處于業務快速發展階段，全線業務快速迭代，同時數據是智慧油客的立命之本，切換數據庫對于我們還是需要謹慎和評估，因此當時未投入成本去驗證產品。

后話：如果當時選擇 OceanBase，可能就沒有后面的一些小插曲。

再識 OceanBase

2022 年，剛剛過完忙碌的春節，OceanBase 團隊再次約見。

調研分布式數據庫

在這次交流前，針對之前介紹的分布式數據庫專門去做了一些調研。畢竟分布式數據庫的出現和發展沒有幾年，技術是否成熟，產品是否過硬，有多少客戶案例，客戶實際體驗如何，這些都是問號。帶著這些問題，我們對分布式數據庫市場進行了一些技術預研。

首個分布式關系型數據庫誕生于 2012 年，Google 發布 Spanner，打造的全球分布式數據庫，承載 Google 自身的全球業務，代碼閉源，近發布論文說明其架構原理，Shared Nothing 無共享模式是純粹分布式的體現、ACID 是關系型數據庫的基礎，MVCC 是并發訪問的保障。自此開創了分布式關系型數據庫的元年，這樣算來分布式關系數據庫的發展也近十年的歷史。

再看 OceanBase，Shared Nothing、ACID、MVCC 等等，分布式一致性協議為 Paxos，不由得想起 Google 的 Chubby 作者 Mike Burrows 的那句話：“There is only one consensus protocol, and that's Paxos”（世界上只有一種一致性算法，那就是 Paxos）。從數據庫架構上來看，滿足了關系型數據庫的各類特性，同時也具有分布式的擴展性、一致性的特點。

OceanBase 官網也有很多產品資料和手冊，頗有 Oracle 官方手冊的規范性，面向 DBA 的、面向開發的等資料一應俱全。案例介紹、解決方案、培訓中心等各個板塊也都有清晰的分類，之前的疑問基本打消了一半。

小插曲：智慧油客經過多年的快速發展，數據量級已經達到了單實例 MySQL 的上限，因此去年 10 月份，我們對 MySQL 云實例進行了升級，采用計算存儲分離的 MySQL，對數據庫存儲擴容，同時采用一主三從架構，以應對數據的爆發式增長。

春節的返鄉潮，連續多日出現加油高峰，瞬時流量突發性增長，此時數據庫卻成為我們的拖累，執行計劃未走索引，SQL 命中低，硬解析升高，負載急劇上升，延遲飆高，甚至出現了數據庫宕機罷工，嚴重影響了客戶加油體驗，我們的研發團隊，在這個春節加班加點保障服務 SLA，在大年初一終于扛過這一波業務高峰。

后來，通過 OceanBase 解決方案架構師對產品的詳細介紹，同時結合我們業務規劃和之前遇到的痛點為我們的數據庫摸脈問診，讓我們對 OceanBase 有了一些信心，當時我們比較堅持的即使切換數據庫也不會選擇 MySQL 內核數據庫，而 OceanBase 完全自主研發，不基于任何數據庫內核，內核引擎同時支持 MySQL 和 Oracle，這在數據庫產品中也是獨一無二。

最終，我們決定詳細測試和驗證 OceanBase 數據庫，看是否能夠給我們帶來額外驚喜。

全業務驗證 OceanBase

我們組織了專項團隊進行 OceanBase 驗證測試，包括全鏈路、全業務的功能驗證，性能壓測。

首先，通過 OceanBase 生態產品 OMS 進行數據遷移，將我們的真實生產數據遷移到 OceanBase，OMS 產品支持結構遷移、全量遷移、增量遷移、全量校驗等功能，一站式解決了數據庫遷移和驗證等問題。我們遷移了線上 5TB 的數據，到了 OceanBase 整個存儲僅 1.1TB，近 20% 的壓縮率確實給我們一個不小的驚喜，直接存儲成本下降 80%，對于一個重數據成本的公司，成本下降顯著。

OMS數據遷移產品

• 兼容性

OceanBase 自主研發，未基于任何數據庫內核，這一點反倒讓我們擔心其兼容性，因為語法兼容度越高，業務代碼的改造成本越小，我們的業務快速迭代，如果因為切換數據庫而投入過多人力，得不償失。

根據 OceanBase 團隊的介紹，OceanBase 支持 MySQL 5.7 絕大部分語法，同時官網也有詳細的 MySQL 兼容項對比。我們的生產庫采用 5.6 版本，對后續測試我們還是比較樂觀。

經過我們測試團隊全量的集成測試，發現了幾個不兼容項，比如table的大小寫問題，插入時間戳的默認值的問題，函數兼容性等問題，對于一個新的數據庫產品，我們本著嚴格篩選的原則，將這些問題一一反饋 OceanBase 專家，沒想到 OceanBase 做到了 MySQL語法兼容的同時，很多參數、變量也都沿用了 MySQL 的傳統，對于學習成本和維護成本也都沒有太多壁壘，最終僅通過參數和變量的調整均得到了解決。

• 性能壓測

智慧油客的業務中，智慧支付是客戶體感最強烈的環節，服務與賦能加油站企業，首先是能讓車主順暢加油快捷支付，其次才是為車主和油站提供附加服務和運營管理能力。因此針對訂單、支付、油價查詢等高頻場景進行了針對性的壓測，對高并發高流量場景進行驗證。

測試集群采用 OceanBase 公有云 14C70G 規格，OceanBase支持多租戶資源隔離，在該集群上開了三個租戶，其中壓測的租戶規格僅 8C48G 資源。

首先開啟 30 個并發小試牛刀，這個并發下對數據庫完全沒有壓力，TPS、QPS 各項平穩，壓測場景中測試數據集中，存在熱點行，但此時依靠準內存數據庫級的高性能寫入，RT 延遲依然較低。

高并發壓測，6000 并發訪問驗證突發峰值流量時的響應，對于突發訪問數據依然采用較為集中的測試數據，因此也是考驗對于熱點行的高并發情況，對于一個 8C 的小資源租戶，讀寫延遲增加也在意料之中，但數據庫整體穩定，可以應對突發流量。

600 并發壓測，TPS、QPS 平穩，SQL 硬解析后很快走 Plan Cache，整體 RT 平穩，寫 RT 在 1ms 以下，讀 RT 也在 1ms 左右，整體性能和穩定性都非常滿意。

• 測試小結

整個測試歷時兩周，全面分析評測，在顯著節約成本的同時，無論是兼容性還是性能均超出預期，同時分布式數據庫的高可用能力也能為我們的服務保駕護航。

結緣 OceanBase

測試結果讓我們對 OceanBase 充滿信心，準備全面切換數據庫服務。如何平穩切換數據庫，如何在切換過程中保證服務的可用性成為我們的難題，OceanBase 的遷移平臺為我們提供了遷移的保障。具體遷移步驟和數據清洗等細節，OceanBase 提供了數據庫遷移規劃和咨詢服務，經過一周的討論研究，同時結合 OceanBase 專家的建議，最終梳理并確定了全業務遷移方案。

一站式服務

智慧油客的近兩年業務規模飛速發展，2020 年初服務 5000 家油站，2021 年初服務 8000 家油站，到 2021 年底已經超越 10000 家，年增長 40% 以上。

快速增長對我們的技術架構提出了挑戰，持續擴容應用節點數量，最終壓力都匯聚到了數據庫，高并發、高流量對于傳統數據庫，終究會達到連接上限和性能極限，即便開了再多的從庫，傳統數據庫的單節點寫無法滿足高并發寫入場景。

分庫分表解決方案可以解決多節點寫入問題，但中間件的性能瓶頸，數據均衡等問題，以及業務改造成本、運維成本都是制約業務發展的因素。與其采用一個中間態的產品，不如直接進化到分布式內核的數據庫產品，通過 OceanBase 公有云服務提供的一站式部署、擴容、監控運維管理、開發工具、數據遷移、備份恢復等端到端數據庫服務化解決方案，同時兼顧了運維成本與服務保障。

OB Cloud 產品架構

大幅度降本

線上全業務遷移，包括我們的業務庫、報表庫等三個實例集群，經過分析清洗，通過 OMS 遷移工具，可以邊界的選擇 Schema 進行遷移，最終遷移原來三個實例共 5TB 數據，OceanBase 存儲僅僅 869GB，比測試階段的主庫壓縮率高出更多，直接節省存儲 83%。

總存儲壓縮對比

租戶存儲監控

? ??

企業上云可以節省運維和資源成本，而云產品的選擇也是一門學問，面對眾多同類云服務，充分調研產品特性，與云產品的團隊深入溝通，充分測試云產品是否適合企業架構，前期的投入最終均會回報到后續運營成本上。OceanBase 對 MySQL 的高兼容性降低改造成本，存儲壓縮特性大幅度降低存儲成本，數據庫的直接賬單成本節約 40% 以上。

未來，智慧油客將持續進行服務升級改造，快速迭代打磨產品，OceanBase 數據庫作為智慧油客的數據底座，通過多租戶的資源動態調配、分布式的彈性擴容，上層業務架構更加靈活，面對突發流量、營銷活動等場景也多了一份從容。

實踐 Tips

在 MySQL 中通過參數 lower_case_table_names 來控制表名的存儲和比較規則，即 Table 大小寫敏感等規則，在 OceanBase 上的語義與 MySQL 完全一致。

MySQL 官方文檔對 explicit_defaults_for_timestamp 的說明

時間戳默認值，explicit_defaults_for_timestamp 變量控制時間戳默認值，在MySQL 5.6、5.7，默認為關閉，而 MySQL 8.0 此參數默認開啟，直接導致的是一個 not null 且有默認值的時間戳字段，如果顯式插入該字段為 NULL，會直接報錯。出于 SQL 的嚴謹性和規范性，建議企業未來開啟此選項，OceanBase 默認開啟，在關閉該變量后，完全兼容 MySQL 5.7。