單機分佈式一體化數據庫的架構設計與優化詳情 - 分佈式,數據庫設計老紀的技術嘮嗑局動態日志

作者：楊志豐，OceanBase產品總經理、首席架構師

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

本文摘自《OceanBase社區版在泛互場景的應用案例研究》，歡迎點擊鏈接閲讀詳細內容。

綜述

在OceanBase 十餘年的技術演進中，共經歷了三次大的架構升級：第一次架構升級是 OceanBase 0.1~0.5 版本（2010 年~2015 年），當時的 OceanBase 通過單寫多讀架構實現了準分佈式，包含 UpdateServer、ChunkServer、MergeServer 等多種不同的角色；第二次架構升級是 OceanBase 1.0~3.0 版本（2016 年~2022 年），OceanBase 成為一個對等的全分佈式架構，所有節點可讀可寫，逐步支持了完整的 SQL 功能；第三次架構升級是OceanBase 4.0 版本，於2022年8月正式被提出，是業內首個單機分佈式一體化數據庫。

OceanBase 4.0版本有一個形象的比喻叫做“小就是大”。這是因為，單機分佈式一體化的核心是採用一套系統，實現從單機到分佈式的轉換，使用户無感知。通過單機分佈式一體化架構，滿足用户從小到大的業務規模化訴求：用户無需關心集中式或分佈式技術路線選型，可以在業務量小的情況下從小規格單機部署起步，使用完備功能的單機部署形態，隨着業務壓力的變化將數據庫從單機平滑擴容到多機甚至超大規模的分佈式集羣，同時具備多機平滑縮容到單機的能力。也就是説，通過一套數據庫滿足業務從小到大的集中式和分佈式架構訴求，用一個系統滿足每一個用户業務從小到大的全生命週期數據存儲與管理需求。

本文從技術角度簡要介紹單機分佈式一體化架構的設計思路、技術優化和業務價值。

一、三次架構迭代，從分佈式到單機分佈式一體化

（一）從原生分佈式到單機分佈式一體化的技術挑戰

OceanBase 從 2010 年開始研發，彼時分成存儲和計算兩層。上層是無狀態提供 SQL 服務的服務層，下層是由兩種 server 共同組成的存儲集羣。這樣的架構具備一定的擴展性，尤其是讀擴展性較強，並且 SQL 層是無狀態的，可以自由伸縮。但該架構最大的問題是單點寫入、多點讀，導致在更大規模併發要求下，無法擴展。同時，存儲層和SQL層的割裂使時延難以控制。

為解決上述問題，OceanBase 摒棄之前的架構，發展出了 OceanBase1.0 ~3.0 的架構，所有的節點都可以在處理 SQL 的同時，處理事務並保存數據。如圖1所示，縱向為分佈式可擴展層，通過不斷加機器提升擴展性；橫向為複製層。提供服務高可用能力。

圖1 OceanBase1.0-3.0架構

在該架構下，OceanBase成為彼時唯一通過 TPC-C 測試的分佈式數據庫，證明了該架構的擴展性和併發處理能力可以滿足絕大多數當前世界上在線服務系統需求。

但隨着業務需求的迭代，OceanBase在走向通用數據庫的道路上，希望能夠支撐更小規模的應用。但卡點在於：3.0版本的架構下，事務日誌流數目和存儲分片數是對應綁定的，存儲分片的粒度決定事務處理和高可用能力是相應粒度，這就導致存儲分片增多，日誌流隨之增多，在越小規模的業務系統中，開銷顯得越大。因此，需要將存儲分片數和事務日誌流解耦，讓若干個存儲分片共享一個事務日誌流以及這個日誌流對應的高可用服務，實現擴展性與成本的平衡，以更好地支撐小規模應用。

此外，考慮到業務的發展規律與生命週期，數據庫需要具備從支撐小規模應用的單機模式，平滑過渡為可處理海量數據的分佈式模式。單機分佈式一體化架構便被創新性地提出，該架構要求兼具分佈式的擴展性和集中式數據庫的功能和單機性能。事務的 ACID（ Atomicity，Consistency，Isolation，Durability）是數據庫的基本要求，而分佈式數據庫的難點就在於如何在異常場景下保證事務的 ACID，核心就是如何基於重做日誌（Redo log）實現故障恢復，以及基於重做日誌實現異常場景下分佈式事務的原子性。

為了真正實現一體化，需要解決如下三個關鍵的技術問題。

（1）應用透明： 從單機到多機不需要應用做改造，需要客户端支持動態路由技術，當後端數據庫發生分區遷移時，能夠動態路由到目的服務器上。另外，不管是單機還是分佈式，需要支持全部的 SQL 功能。

（2）單機操作： 單機只有一個 redo 日誌，單機事務寫 redo 日誌的方式和經典的單機數據庫相似。經典的單機數據庫採用B+樹存儲引擎，OceanBase 的技術創新是將 B+ 樹數據分塊的思路融入 LSM 樹存儲引擎，一方面能夠像 LSM 樹一樣具備高壓縮能力，並把熱點數據放在內存中提供服務，另一方面通過類似 B+ 樹的數據分塊思路來減少 LSM 樹的寫入放大。在OceanBase 4.1版本中，即使在三台機器做強同步的情況之下無論是單機的性能還是存儲成本都優於 MySQL 8.0。

（3）跨機操作： 跨機操作通過底層的分佈式架構提供，上層的 SQL 功能不受影響。如果事務只涉及一台機器，走單機事務；如果涉及多台機器，通過兩階段提交實現分佈式事務。另外，通過分佈式、並行、異步化等技術手段儘可能地優化性能。

（二）可行性分析，如何消除分佈式帶來的overhead？

架構設計的首要任務是可行性分析，核心在於取捨。在設計OceanBase單機分佈式一體化架構時，我們也做了這樣的設計假設：對於一個分佈式數據庫，雖然能夠處理的數據量很大，但大部分操作仍為單機操作（>80%），少部分操作才是跨機操作（<20%）。

基於早期OceanBase在阿里體系內部推廣的經驗：在泛互行業，To C 的在線業務基本都能夠按照用户號 (user_id) 做 sharding 實現分佈式，後續的絕大部分操作都是單用户內部的操作，只有非常少數的跨用户操作；金融行業類似，大部分時間都在讀寫自己的賬户，少部分時間才做轉賬等跨賬户操作。於是，系統的優化目標變成：首先確保 80% 的單機操作沒有任何分佈式相關的 overhead（本文指額外開銷），這部分操作能夠和單機數據庫站在同一起點比較性能，其次才是優化另外 20% 跨機操作的性能，儘可能追求極致。

單機操作的分佈式相關 overhead 主要來自於兩個方面：一方面是高可用，另一方面是可擴展性。曾在2023年，支付寶 Oracle DBA 分享其經驗：當 Oracle 打開強同步時，性能降低至少 30% 。OceanBase 為了實現無損容災，底層採用了基於 Paxos 的強同步方案，即通過改變架構以達到單機高性能。

我們的做法是把數據庫中的 redo 日誌提交給異步化，以避免數據庫內部的工作線程等待日誌提交返回結果，即使網絡和磁盤情況較差，強同步帶來的開銷也相對小。我們使用 sysbench 對 OceanBase 三台機器強同步進行性能評測，結果表明 Paxos 強同步對於 OceanBase 的性能損失只有 8% 左右。這是完全可以接受的，且可以通過其它模塊的優化彌補這部分損失。可擴展性帶來的性能損耗主要是數據分片導致的，每個數據分片都需要寫單獨的 redo日誌，可以簡單地把每個數據分片想象成一個 mini 數據庫，分片越多，每台機器上分片管理相關的分佈式 overhead 就越大。

單機分佈式一體化架構的創新就在於動態日誌流。每台機器上的每個租户只有一個日誌流，一個租户上的所有數據分區都動態綁定在該日誌流之上，從而避免大量日誌流導致的 overhead。另外，分區到日誌流是動態綁定的，當系統增加新的服務器時，可以把分區從源端的日誌流動態解綁並重新綁定到目的端的日誌流，從而實現分區動態遷移。

二、技術優化：通過改造日誌流，保證單機和分佈式的靈活切換及性能與擴展性

在傳統數據庫方案中（見圖2），隨着業務規模的增長，選型路徑會經歷從支撐小型業務的小規格 MySQL，到支撐中型業務的高規格的 Oracle，再到大型業務使用 Oracle RAC 解決基礎的擴展性問題，後續可能還要升級到小型機+DB2 的方案承載核心業務。

圖 2: 企業業務規模與數據庫選型策略示意圖

這一傳統路徑存在幾大缺陷。首先，擴展性存在天花板，無法做到隨業務體量無限靈活擴展。其次，每次升級改造都涉及大量軟硬件的替換，帶來無法估計的成本。最後，這條升級路線是“單行道”，面對現實場景中更曲折的業務變化難以“回頭”，無法規避超額的成本投入。

OceanBase“單機分佈式一體化”概念的提出，旨在探索用一套解決方案，應對企業在不同發展階段、不同業務體量帶來的不同挑戰，讓數據庫伴隨業務成長，滿足企業“一次選擇支撐全生命週期業務發展”的需求。

OceanBase 的“單機分佈式一體化”架構在部署形態（見圖3）方面有兩層含義。第一層含義是指同一個 OBServer 既可以單機部署，也可以分佈式部署。第二層含義是在 OceanBase 分佈式集羣中，可以存在單機形態的租户。並且，無論在租户層面還是集羣層面，單機和分佈式的形態可以靈活調整切換，以便企業選擇最適合當前需求的部署模式。

圖 3: OceanBase 單機分佈式一體化產品形態示意圖

在初始階段，企業可以使用小規格機器部署單機 OceanBase。隨着數據規模的增長，可以選擇替換更大規格的單機進行垂直擴展，同時主備庫、三副本等部署模式支持企業的容災和高可用需求。當數據規模進一步擴展時，企業可以選擇水平擴展，擴大集羣規模，支撐大型業務。

“單機分佈式一體化”聽起來並不複雜，當一個數據庫可以解決複雜的分佈式事務時，似乎單機部署也並不是一件難事。然而事實並非如此。在分佈式架構方面，OceanBase 多年來在分佈式 TP 領域的豐富經驗，以及打破 TPC-C 世界紀錄的成績已經證明了其處理分佈式事務的能力。因此在面對“單機分佈式一體化”命題時，挑戰主要存在於“單機”和“一體化”兩方面。

挑戰1：如何提升數據庫在小規模單機模式下的性能，使其與單機數據庫相當？

分佈式系統為了實現分佈式事務的原子性和持久性，其日誌流設計相比單機數據庫會產生更大的開銷，支撐單機事務和小規格分佈式事務的性能表現顯著低於單機集中式數據庫。對一些企業來説，採用分佈式系統反而會導致數據庫性能下降，因此寧願選擇用更高成本對現有數據庫進行機器規格上的垂直升級。

具體而言，日誌流是數據庫實現事務原子性和持久性的保障。基於日誌流，分佈式數據庫為了保證原子性而引入了兩階段提交等分佈式事務協議；為了保障持久性，又引入了 Paxos 等選舉協議。這些相比單機數據庫額外增加的操作也帶來了更大的開銷。另一方面，分佈式的寫入是多點的，因此會產生多條日誌流。日誌流的數量會影響參與兩階段提交和參與 Paoxs 選舉的組的數量，從而影響分佈式事務的開銷。

在常見的分佈式系統中，日誌流的數量對應數據分片的數量，數據量越大，分區的數量越大，分佈式事務的開銷就越大、性能受到的影響越明顯。想要讓分佈式數據庫的單機性能和單機數據庫性能相媲美，就需要降低日誌流的數量。

面對這一問題， OceanBase 的做法是將日誌流的數量降到和節點數相關。單機部署模式下的 OceanBase，從架構上來説和傳統的單機數據庫沒有區別，只有一條日誌流，在進行分佈式擴展時，日誌流數量僅與節點數相關，分佈式代價的增長顯著降低。

通過對日誌流的改造，OceanBase 實現了在單機模式和小規模分佈式部署模式下，性能與單機數據庫相當。如圖4所示，在 4C16G 的小規格場景下，Sysbench 測試結果顯示，OceanBase 4.0 的 insert 和 update 性能可以達到 MySQL 8.0 的兩倍，其他幾項性能也能做到與 MySQL 8.0 相當。同時，單機部署模式下，OceanBase 的存儲成本更低。經測試，在 TPC-H 100G 場景下 OceanBase 4.0 的存儲成本僅有 MySQL 的 1/4。

圖 4: 4C16G 規格 Sysbench 性能測試對比 OceanBase 社區版 4.0 v.s RDS for MySQL 8.0

挑戰2：如何在不犧牲性能的情況下，實現單機模式和分佈式的靈活調整切換？

解決了單機和分佈式部署模式下的性能問題，如何在不犧牲性能的情況下保障水平方向的靈活擴展成為了單機分佈式一體化架構需要解決的另一個問題。

除了前文提到的，通過對日誌流的改造，在進行水平擴展時，日誌流數量隨節點數增加，從而減少開銷之外，OceanBase 還引入了多種方法，支持用户通過手動或自動的方式提升擴展性能。

作為分佈式數據庫，為了滿足擴展性和多點寫入等需求，OceanBase 數據庫支持分區功能，即將一個表的數據分成多個分區來存儲，將分區方式相同的表聚集到一起就形成了表組。在系統進行負載均衡時，表組可以幫助用户將具有關聯關係的數據聚集在同一台機器上，即同一個表組的表會被綁定在同一個日誌流中。通過設置表組，用户可以避免大量的跨機器操作，從而有效降低連接場景下的數據傳輸的開銷，提升性能。極端情況下，如果一個事務涉及的表在一個表組內，那麼它即為一個單機事務，不會存在分佈式開銷。

OceanBase 也提供了自動化的調度，幫助提升擴展性能。例如 OceanBase 支持自動對 RPC 進行聚合，還支持通過自動負載均衡將分佈式事務的分區調度在一起，減少分佈式開銷。

圖5展示了 TPC-C 測試 OceanBase 集羣節點數從 3 台機器擴展到 1500 台機器的過程中，tpmC 的數值變化。測試結果表明，即使在包含 10%分佈式事務的情況下，OceanBase 集羣性能仍能隨集羣規模擴展實現線性提升。

圖 5: TPC-C 性能測試 OceanBase 在不同節點數規模下 tpmC 值變化情況

基於上述技術優化，OceanBase單機分佈式一體化架構，一方面具備單機數據庫高性能、低成本的優勢，幫助客户降本增效；另一方面具備分佈式數據庫高可用、可擴展等優勢，幫助客户更好地挖掘數據價值。此外，還擁有三個特點：靈活、簡單、開放。

1.靈活。

除了上文提到的單機和分佈式模式靈活切換外，OceanBase 通過內置的多租户隔離架構，能夠實現共享實例，從而儘可能降低成本。當用户的業務量越來越大時，通過單機分佈式一體化架構，可以逐步從小規格實例擴展到分佈式實例，靈活擴容、縮容。

2. 簡單。

OceanBase 4.0 希望降低數據庫選型和運維的複雜度，儘可能用一套數據庫滿足不同場景的需求。一方面，單機和分佈式的架構差異可以通過上文提到的動態日誌流方案統一起來；另一方面，在一套系統中實現 OLTP、實時 OLAP、Key-Value、JSON、GIS 等多種數據模型的處理，避免用户因為基礎設施能力不足而採用多套系統。

3.開放。

OceanBase 早期版本支持本地部署，後來逐步支持多雲部署，並選擇開放的存儲計算分離方案。具體做法是拋開 SQL 和 KV 分層方案，數據庫讀寫數據塊時支持本地或者遠程的各種分佈式文件系統，數據庫用來做計算，文件層用來做存儲。這種方式最大的難點是需要將高可用和可擴展的處理融入到分佈式事務，實現複雜，好處是保證了性能和開放性，數據庫內部的 SQL 和 KV 模塊之間不再需要 RPC 交互，且能夠適配多雲平台上的各種存儲系統。另外，OceanBase 在設計存儲格式時降低了對外部文件系統的依賴，以便用户可按實際業務需求，將數據庫部署到不同的雲平台甚至多雲，並確保系統穩定和高性能。

三、一次選擇支撐業務全生命週期發展

對用户和開發者來説，單機分佈式一體化架構看起來什麼都行，既能做單機，又能分佈式，現階段的側重點到底是什麼呢？短期來看，OceanBase 單機分佈式一體化能力對於用户和開發者有以下兩個維度的價值和意義。

（1）極大地降低分佈式數據庫的門檻。 原先的 NewSQL 單機性能太差，業界主流的 NewSQL 系統如 CockroachDB 和 YugabyteDB 的單機 sysbench 性能只有 MySQL 的 1/5 ~ 1/10（數據日期：2023年）。隨着單機分佈式一體化數據庫逐步成熟，這類 NewSQL 會被逐步取代。同時即使是在分佈式部署場景下，相較於其他分層的分佈式數據庫，OceanBase 的性能有很大的優勢，如果用户做精細控制的話，單機事務比例增加後，效率可與單機數據庫相當。目前已經有很多用户將 NewSQL 系統替換為 OceanBase 以實現降本增效。

（2）解決用户從小到大擴展的需求。大多數中小企業的業務發展在不同的發展階段對數據庫規模和性能有着不同的需求。OceanBase 既可以單機方式部署，提供單機數據庫相當的能力，並且可以在任何時刻，管理員可以去做形態的變換，由一個單機的形態變成分佈式形態，從分佈式形態變回單機形態，動態切換。相較之下，即使業務現階段數據量不大，採用單機數據庫足以支撐，但對比業務發展後再修改應用更換數據庫，選擇一開始就採用單機分佈式一體化數據庫，顯然是更好的選擇。

總結而言，OceanBase通過原生分佈式保障分佈式事務 ACID 的同時提供滿足擴展性需求，在業務無感知的情況下支撐企業實現快速迭代升級；通過單機分佈式一體化架構，有效支撐企業全生命週期的規模與需求變化，伴隨業務成長，從根源解決企業數據庫應用難題。