初探oceanbase和newsql資料庫

為什麼是分散式資料庫？

網際網路時代，資料已經成為企業運營的命脈。作為聚合支付的領軍企業之一，李俶 2021 年受理交易金額 3500 億，覆蓋全國 600+ 城市，服務 110 萬 + 線下商戶，日交易量 2300 萬 + ，合作伙伴 1000+ 。在如此龐大的交易和支付場景下，資料意味著李俶的服務質量，意味著企業管理的未來和活力。所以對於資料的基礎來說，資料庫的穩定性高於一切， 7*24*365 穩定執行是基本要求，服務連續性是服務質量的底線，資料庫的高可用性、避免單點故障、快速容災切換、資料無損是資料庫技術的大勢所趨 ， 也扮演著很重要的角色 。

 

資料庫技術發展

 

從資料庫技術的發展歷史來看，經歷了單資料庫、子資料庫和子表資料庫、分散式資料庫的發展。相對於我們的業務應用和服務，我們很早就開始了微服務和單元化架構升級，其本質也是服務分發。我們透過分散式一致性協議來協調各種應用和元件，從而達到高服務可用性和高吞吐量的能力。雖然延遲的分散式資料庫技術比應用服務的技術框架落後半步，但是從最終的發展趨勢來看，分散式資料庫一定會成為主流資料庫。

 

單機資料庫

 

自 1970 年 IBM 研究員 E.F.Codd 博士提出關係模型以來，經過幾十年的發展，關係模型得到了充分的發展，成為資料庫的主流模型。這幾十年也產生了知名的獨立資料庫產品，如 Oracle 、 DB2 、 MySQL 和 PG 。

 

單資料庫易用，單節點維護成本低，保證了 ACID 的特性 ( 原子原子性、一致性一致性、隔離性和永續性 ) 。但隨著業務量的增長，似乎無法應對高併發讀寫，海量資料的高效處理。不斷提高單個節點的規格，最終會遇到天花板，摩爾定律趕不上業務增長的規模。

 

 

 

對於電腦時代的史前產品，放個黑白圖片例子。

 

子資料庫和子表

 

當單個資料庫無法承載高併發、海量讀寫等任務時，分庫分表的方案已經開始出現，至今仍方興未艾。分庫分表的方案，解決了業務快速增長帶來的高併發訪問問題，同時可以透過分而治之的方式滿足海量讀寫。典型的中介軟體包括 TDDL 、分片 JDBC 、 MyCat 等。

 

透過對目前一些主流雲資料庫產品的調研，我們發現大部分雲上的分散式資料庫基本都是以 MySQL 和 PG 為核心的子資料庫產品。使用分散式元件，如 ZooKeeper 和 etcd ，可以管理多個資料庫例項，從而實現一個分散式資料庫產品。本質上，它類似於將多個資料庫與應用程式連線起來，只是後設資料管理被移到了單獨的元件中。在實際使用中會發現， ACID 無法保證，快速的業務發展需要拆分例項資料遷移等運維工作的高投入。

 

分散式資料庫

 

21 世紀，分散式資料庫的概念被提出。與傳統資料庫和非關聯式資料庫 NoSQL 相比，新一代資料庫是 newsql 資料庫。這種資料庫兼有傳統資料庫和 NoSQL 資料庫的功能和優點。兩者完美結合，既能保證 ACID 特性，又能解決分散式擴充套件能力，又能保證海量儲存，同時達到高可用、高效率的目的。

 

21 世紀初，分散式資料庫已經初具規模。 Oracle 的 RAC 以共享儲存為代表，計算節點的分散式處理可以看作是分散式資料庫的一種嘗試。畢竟高階儲存硬體一般企業買不起，儲存層還是無法橫向擴充套件。

 

2012 年，谷歌釋出了 Spanner 。由於其封閉的原始碼，我們只能透過論文一窺端倪。共享無， Paxos ， ACID ， MVCC 等基本建立了分散式資料庫的主流架構模型。

 

 

 

在眾多分散式資料庫選擇中， TPCC 榜單上的 OceanBase 進入了我們的視線， TPCC 連續兩年測試第一，超過 Oracle 效能 20 多倍。同時，經過了解， OceanBase 資料庫是一個完全獨立的分散式資料庫，而不是基於其他核心產品的包，這也是我們準備測試 OceanBase 的一個重要原因。

 

 

 

選型驗證海洋基地

基於資料庫的發展趨勢，李俶作為一家創新型網際網路企業，始終緊跟技術發展的步伐，不斷迭代平臺架構，以不斷提升服務質量，應對業務發展的不斷增長。因此，基於對分散式資料庫的研究，我們選擇 OceanBase 進行測試和驗證，並基於我們的業務使用 newsql 資料庫進行測試，這也是對分散式資料庫產品的初步探索。

 

其實對 OceanBase 並不陌生。 2019 年我們已經和 OceanBase 團隊溝透過了。當時經過初步瞭解，發現對我們的資料遷移和運維管理提出了一些挑戰，成本和風險讓我們暫時擱置。時隔兩年，再次見到 OceanBase 團隊，感覺很親切，也希望這兩年的沉澱能給我們帶來不一樣的產品。

 

高相容性

 

切換應用程式資料庫不僅僅是改變資料庫驅動程式那麼簡單。驅動程式只解決應用程式和資料庫之間的通訊協議。資料庫與 SQL 的相容性直接影響我們業務遷移的轉換成本。 OceanBase 的一個叢集同時支援 Oracle 和 MySQL 兩種模式，是我們研究的眾多資料庫中唯一的一個。

 

 

 

在本次相容性評估中， OceanBase 提供了 OMA 遷移評估工具，可以在資料遷移前全面掃描 newsql 資料庫透過 OMA 評估工具，我們直接評估了測試庫的結構和 SQL 的相容性。同時，我們還可以透過靜態程式碼分析來分析應用中的 SQL ，並透過評估報告對不相容項提供詳細的解釋和改進建議。

 

 

 

透過命令列方式的結構化遷移評估，快速生成評估報告。根據評測報告中的不相容項，我們還找到了兩種非口號的方法來消除相容性隱患。

 

 

 

OMA 還支援靜態程式碼分析評估。透過 OMA 工具直接在本地進行靜態程式碼分析，避免核心程式碼的洩露。相容性分析為 100% 。在實際的應用接入測試中，發現評測報告是準確的。當然，前提是保證 perfomance _ schema 中的 SQL 覆蓋我們業務的所有 SQL 。

 

OMA 使用方便，評估準確。給 OceanBase 點個贊。

 

高壓縮比

 

評估結束後，我們透過 OMS 遷移工具整理並遷移了幾條資料進行測試和對比。我們不得不提到 OMS ，它可以透過幾個步驟的配置操作進行拉取和遷移。整個操作過程非常簡單易用。

 

 

 

遷移後，我們專門比較了資料庫儲存的差異。對於一個以資料為核心業務的公司來說，資料的儲存成本是與日俱增的， OceanBase 儲存壓縮比確實讓我們大吃一驚。超高的壓縮比可以大大節省儲存成本。下圖是一個 300GB+ 寬的表的儲存對比，整個庫的儲存壓縮率在 70% 以上。

 

 

 

業務庫表的儲存比較

 

OceanBase 的高壓縮比不僅是 zlib 、 lz4 等傳統壓縮演算法，還有編碼、差分演算法等先進的壓縮演算法。與傳統的壓縮演算法相比，它提供了一個更極端的壓縮比，這真的是意想不到的。

 

HTAP

 

OceanBase 資料庫不僅僅是一個 TP 關聯式資料庫，它的主 HTAP 也是我們最喜歡的特性。對於李俶的支付場景，支付交易訂單量巨大，業務規模快速增長。線上交易的同時，希望有一些實時的統計分析，比如合作商家對近期交易彙總資訊的統計查詢，這也是服務體驗對於查詢時效的重要一環。

 

為此，我們對我們現有的資料庫和 OceanBase 的 TP 和 AP 能力進行了詳細的對比，驗證其能否在保證支付業務穩定性的場景下，提供實時的統計查詢能力。透過 4.9 億 + 條資料的寬表和 SQL 在不同場景下的統計分析，我們發現 OceanBase 具有出色的查詢效能。 TP 效能是 TPCC 頂級的，保證了高併發和高效能。同時， HTAP 混合動力引擎還提供實時資料分析能力。

 

 

透過真實業務 SQL 的執行對比， OceanBase 的表現再次超出預期。

 

 

透過在不同場景下的測試和驗證， OceanBase 不僅滿足了我們對分散式資料庫的要求，還具有意想不到的效能和較高的儲存壓縮比。

 

首先，我們選擇了一個創新的業務 “合作伙伴”進行遷移和割接。這個業務上線時間不長，但是業務增長很快。快速增長的業務對 newsql 資料庫也是極大的挑戰。不知道哪一天會有突然的增長。對於傳統的 MySQL 來說，即使把資料庫和表分了，再把表分了再遷移也來不及了。

 

在資料遷移過程中， OMS 再次發揮作用，不僅支援資料的全量遷移，還支援結構遷移、全量校驗、增量遷移、反向同步等功能。全額驗證對我們支付場景的幫助非常大，省去了我們開發驗證程式的工作，同時也保證了資料遷移的準確性。增量遷移可以與源資料庫保持實時同步，為我們的業務驗證提供了一個視窗，以充分驗證和保證線上割接的穩定性。

 

 

透過全量資料的資料遷移，對比一個邏輯庫的儲存壓縮， “ Laipartnership ”業務的基礎壓縮率為 26.4% ，符合之前的測試預期。

 

 

對比遷移到邏輯庫前後， 11.06GB 的儲存下降到 2.92GB

 

在遷移和割接的過程中，應用程式碼只需要修改配置檔案和切換資料來源， OceanBase 與 MySQL 協議的相容性完全不需要改變驅動。同時，基於之前 OMA 的評測報告，應用的驗證也非常流暢， OceanBase 對 MySQL 語法的相容也降低了 newsql 資料庫的切換門檻。

 

遷移後，透過 OceanBase 的雲服務平臺， CPU 、 TPS 、 QPS 等的效能可以監控，同時可以設定告警，保證服務 SLA 。實時診斷功能為 DBA 提供了一套“利器”，如慢速 SQL 查詢、 TopSQL 查詢，甚至慢速 SQL 的索引繫結，無需更改業務程式碼，大大提高了資料庫運維效率。

 

 

感謝 OceanBase 生態工具的加持，成功遷移了第一筆業務，同時繼續線上監測。目前業務執行順利。後續李俶將逐步遷移其他業務線，遷移到 OceanBase ，擁抱分散式資料庫時代，享受分散式資料庫帶來的技術紅利！

 

在過去的兩年中，雖然楚不可能愛上楚，但在過去的兩年中， OceanBase 在各種生態產品上取得了突破性的進展。各類周邊配套產品基於客戶的實際問題，解決了評估、遷移、運維等一系列問題。這個測試驗證了資料庫和生態產品都得到了客戶的認可，也是我們“把簡單留給客戶，把複雜留給自己”的實踐。

 

針對李俶高流量、高併發的業務場景，在評估和遷移過程中，結合 ant 的最佳實踐，對 core newsql 資料庫 table 結構進行了部分最佳化，實現了業務程式碼的零轉換，提升了資料庫擴充套件能力和效能。

 

Chu 在 OceanBase 的首次商業登陸僅僅是一個開始。對於其他業務，尤其是海量資料付費，我們會和楚一起努力，希望透過 OceanBase 給客戶帶來一鍵遷移、運維一體化、 HTAP 庫的服務體驗。