關於作者
趙裕眾
OceanBase 資深技術專家，2010 年加入支付寶後從事分散式事務框架的研發，2013 年加入 OceanBase 團隊，目前負責儲存引擎相關的研發工作。
近年來，隨著應用場景多樣化和資料量的增長，我們看到分散式資料庫正快速普及到各行各業，透過資料一致性、高可用、彈性擴充套件等方面的技術能力，為使用者海量資料、高併發的業務場景提供極佳的解決方案。同時，分散式資料庫天然會需要配置多臺伺服器，以保證高可用和效能。因此，在很多資料規模較小、相對簡單的業務場景，使用者通常會在發展初期選擇門檻更低、效能更強（小規格下）的集中式資料庫。但這一選擇也存在一定的弊端：隨著使用者的業務量不斷增長，最終會到達集中式資料庫的效能瓶頸，等到再進行架構調整重構時，將會帶來極高的難度和成本。
在今年的雲棲大會，OceanBase 社群版 4.0（代號：小魚） 正式與大家見面，這也是業內首個相容 MySQL 的單機分散式一體化資料庫。 這一版本提供了許多使用者期待的能力，我們透過單機一體化架構、單機部署、小規格降低部署成本，一鍵安裝部署提升易用性，更強的 OLAP 能力提升分析能力，最終實現 OceanBase 社群版 4.0 在 4C16G 的生產系統能夠穩定執行。我們希望可以透過單機與分散式的雙重技術優勢，為使用者在資料庫選型時帶來“一次選擇，終身受用”的新可能。
從使用者的反饋來看，OceaBase 社群版 4.0 在單機分散式一體化、小型化方面備受大家關注。我們認為，小型化不只是完備功能前提下的單機部署，更重要的是在同等硬體下可以實現更好的效能。本篇文章將分享 OceanBase 對分散式資料庫探索“小規格”的思考，介紹我們在實踐單機分散式一體化架構時的技術創新思路與方案：
使用者為什麼需要小型化的分散式資料庫；
分散式資料庫小型化的關鍵步驟；
OceanBase 在小規格下的效能表現。
使用者為什麼需要小型化的分散式資料庫？
在進入主題之前，我們先回顧一下 OceanBase 發展歷程中的重要時刻：2010 年，OceanBase 正式創立，創立至今的 12 年間， OceanBase 相繼打破 TPC-C、TPC-H 世界紀錄，陪伴大家度過了一次次“雙 11”，保障大家每一筆交易都能夠安全高效地執行。在這一次又一次的挑戰中，OceanBase 作為一款完全自主研發的原生分散式資料庫，擴充套件性和穩定性也被不斷得到驗證，從 TPC-C 第一次打榜的 203 臺 ECS 伺服器到第二次打榜的 1554 臺 ECS 伺服器，OceanBase 的效能都是隨著機器數量增加而線性提升。
另一方面，隨著 OceanBase 從金融場景逐步走向通用場景，我們意識到並不是所有使用者的業務都具有“雙 11”時所面對的資料量，事實上，在許多使用者的業務發展初期，單機部署形態的資料庫完全可以滿足其需求。因此，在使用者業務初期資料量還很小的時候，給使用者提供一個儘可能低的啟動規格非常重要。這將幫助使用者以一個非常低的成本，做業務啟動探索，同時藉助 OceanBase 的良好擴充套件性，在後期又可以彈性擴容，以面對不斷增加的使用者資料和效能需求。
▋ 從小到大，每一個創新業務對資料庫的基本訴求
最新的 OceanBase 4.0 版本最小支援 4C8G 的部署規格。4C8G 是什麼概念？其實就是一臺稍好的膝上型電腦的配置，換句話說，OceanBase 4.0 可以在大家的個人電腦上安裝部署並穩定執行了。
從 4C8G 開始，OceanBase 4.0 可以隨著使用者的業務增長進行彈性擴容，能夠從小到大支援使用者全生命週期的資料庫需求，幫助使用者更好地降本增效、進行業務創新。
- 在使用者業務發展初期， 資料量並不大，對容災也沒太高需求，便可以在單臺伺服器上部署執行 OceanBase 4.0，同時利用 OceanBase 的備份功能定期做下冷備以防萬一；
- 當使用者業務逐步成長起來， 可以先對伺服器做縱向升級，此時使用者對容災有了一定需求，OceanBase 和傳統資料庫一樣支援主備庫部署，使用者可以使用兩臺伺服器做基礎的線上容災（由於主備架構的限制，此時容災管理仍需要人工介入）；
- 當使用者業務初具規模， 資料變得越來越重要，此時使用者可以升級到 OceanBase 的三副本架構，使用三臺伺服器來保證高可用，容災也將變成自動化：即使單臺機器發生故障，OceanBase 4.0 仍然可以保證 RTO < 8s（8s 內業務恢復）和 RPO = 0（資料不丟）；
- 當使用者業務進一步變大， 單機配置升級到頂，此時使用者就會遇到和當初淘寶、支付寶一樣“幸福”的煩惱，此時，OceanBase 的透明分散式擴充套件能力可以幫助使用者把叢集從 3 臺擴充套件到 6 臺、9 臺乃至上千臺。
圖1 不同業務規模下 OceanBase 與傳統資料庫部署方式演進對比
▋ 平滑過渡，讓效能保持線性增長
OceanBase 的單機分散式一體化架構，可以幫助使用者在從單機形態部署直至多叢集的分散式部署，始終能夠平滑過渡，並保持效能的線性增長。
藉助 OceanBase 良好的單機縱向擴充套件性，單機配置的升級通常會取得效能的線性增長。當使用者進行分散式擴充套件時（例如從 3 臺擴充套件到 6 臺伺服器），通常會引入分散式事務，一般而言，分散式事務的引入通常會帶來一定的效能損失，但 OceanBase 可以透過多種機制降低分散式事務發生的機率：首先可以透過 OceanBase 的 TableGroup 機制，將多張表繫結在一起來降低分散式事務發生的機率；其次 OceanBase 良好設計的負載均衡策略也能幫助減少分散式事務。
此外，OceanBase 良好的分散式擴充套件性也能夠保證隨著使用者使用的伺服器數量增加，效能保持線性增長。例如在 TPC-C 測試中，儘管包含了大約 10% 左右的分散式事務，隨著資料庫叢集規模的增大，OceanBase 效能的提升仍然是線性的。
圖2 OceanBase 在不同節點數量下的 TPC-C 測試結果
更重要的是，在從一臺到兩臺，到三臺以及上千臺的擴容過程中，所有操作都可以透過對 OceanBase 叢集的運維來完成，對業務是完全透明的，使用者上層的業務不需要修改一行程式碼，也不需要手動搬遷運算元據。當然，如果使用者使用的是 OceanBase Cloud，所有的備份、擴容、運維操作都將一站式完成，更方便使用者的使用。
從 OceanBase 4.0 版本開始研發的第一天起，我們就在思考如何讓分散式資料庫執行在更小規格的硬體上，並具備更強勁的效能，幫助使用者在不同的業務場景下滿足對價效比和高可用的要求。OceanBase 4.0 的小型化，不僅可以在具備完整功能的前提下實現單機部署，更重要的是能在同等硬體下實現更好的效能。
OceanBase 4.0 小型化的關鍵技術
在基礎軟體領域，把資料庫系統“做大”是一件非常困難的事情，因為隨著系統中的節點不斷增多，出故障的機率也會不斷增加。例如，OceanBase 做 TPC-C 第二次打榜時使用了 1554 臺 ECS 伺服器，其中出現單臺機器故障的頻率大約是一天一次到兩天一次。這需要我們把產品做的足夠穩定和高可用，才可以讓這樣一個大的叢集保持正常執行。
而把資料庫系統“做小”同樣不容易，因為這需要深入到每一個細節，幾乎是用顯微鏡去摳每一處資源的使用。 不僅如此，在大規格下一些合適的設計或者配置，到小規格下會變得完全不可接受。而更困難的是，我們要在同一套架構裡面同時兼顧小和大，這需要我們在大小規格之間做設計上的權衡取捨，儘可能減少分散式架構帶來的額外開銷，同時在很多場景中讓資料庫系統根據機器規格做自適應處理。下面我們將以 CPU 消耗、記憶體消耗者兩個主要難點的解決過程為例，介紹 OceanBase 4.0 的技術思路。
▋ 實現動態日誌流控制，降低 CPU 消耗
OceanBase 4.0 實現小型化，要解決的第一個問題是 CPU 消耗，在 4.0 版本之前，OceanBase 會為每個資料表的分割槽建立一個 Paxos 日誌流，透過 Paxos 協議來保證分割槽資料的多副本一致性。這樣的設計非常靈活，因為 Paxos 組是基於分割槽的，這意味著分割槽可以非常靈活地在不同伺服器之間遷移；但同時也帶來了很大的 CPU 開銷，由於對每個 Paxos 日誌流都會有選主、心跳和日誌同步的開銷，當伺服器規格較大或者分割槽數量較少時，這些額外開銷相對來說佔的比例並不是很高；但當伺服器規格變小時，Paxos 協議帶來的開銷就變得難以接受了。
OceanBase 4.0 是如何解決這一問題呢？我們認為最直接有效的辦法是減少 Paxos 日誌流的數量。如果能夠將 Paxos 日誌流的數量減少到與伺服器個數同量級的程度，那麼這部分開銷就和傳統資料庫主備庫模式下的日誌開銷差不多了。
圖3 OceanBase 4.0 動態日誌流叢集架構圖
在 OceanBase 4.0 中，我們將多個資料表分割槽聚合為一個 Paxos 日誌流，並進行動態日誌流控制。如上圖所示，一個資料庫叢集中有三個 zone，每個 zone 各包含兩臺伺服器。假設有一個租戶配置了兩個 unit，那麼相應地這個租戶就會有兩個 Paxos 日誌流，一個日誌流中包含分割槽（P1, P2, P3, P4），另一個日誌流中包含分割槽（P5, P6）。
如果兩臺伺服器的負載不均衡，那麼 OceanBase 的負載均衡模組會在 Paxos 日誌流之間做分割槽的排程；
如果需要做叢集的擴容，那麼可以將一個 Paxos 日誌流分裂為多個 Paxos 日誌流，並做 Paxos 日誌流的整體遷移；
如果需要做叢集的縮容，那麼可以將多個 Paxos 日誌流遷移到一起，並做多個 Paxos 日誌流的歸併。
透過動態日誌流控制，OceanBase 4.0 在保證高可用靈活擴充套件的基礎上，極大減少了分散式架構帶來的 CPU 開銷。
▋ 後設資料動態載入，讓小記憶體支援高併發
OceanBase 4.0 實現小型化，要解決的第二個關鍵問題是記憶體消耗。在 4.0 版本之前，出於效能的考慮，OceanBase 會讓一部分後設資料在記憶體中常駐，當記憶體規格較大時，這些記憶體所佔的比例並不是很高；而當伺服器規格要降低到很小時，這些後設資料記憶體的大小就變得難以接受了。為了帶給使用者更加極致的小規格能力，我們實現了所有後設資料的動態載入。
圖4 SSTable 分層儲存
如上圖所示，我們將 SSTable 做了分層儲存，將 SSTable 的根儲存在分割槽內，在記憶體中只維護分割槽的控制程式碼。只有當需要對分割槽進行訪問時，才將需要訪問的資料透過 kvcache 動態載入起來。我們做到了讓 OceanBase 4.0 可以在較小記憶體的規格下，支援較大資料量的高併發訪問。
OceanBase 在小規格下的效能表現
為了測試小規格下的實際效能效果，我們基於三臺 4C16G 的伺服器，按照 1:1:1 模式來部署 OceanBase 社群版 4.0，並同時和 4C16G 的 RDS for MySQL 8.0 透過 Sysbench 進行效能對比，可以看到絕大多數場景中，OceanBase 社群版 4.0 的效能都優於 RDS for MySQL 8.0，尤其在 Insert 和 Update 兩個場景中，同樣的硬體條件下，OceanBase 社群版 4.0 的吞吐量表現是 RDS for MySQL 8.0 的 1.9 倍。
圖5 OceanBase 社群版 4.0 & RDS for MySQL 8.0 Sysbench 效能測試結果（吞吐量，4C16G）
此外，我們也在使用者最為常用的 8C32G、16C64G、32C128G 場景，分別進行了對比測試。隨著伺服器規格的提升，OceanBase 社群版 4.0 與 RDS for MySQL 8.0 的單機效能差距逐漸拉大。在 32C128G 的硬體規格下，OceanBase 社群版 4.0 吞吐量最高可達 RDS for MySQL 8.0 的 4.3 倍，響應時間縮短至 RDS for MySQL 8.0 的 1/4。
|  |
|---|---|
 |  |
圖6 OceanBase 社群版 4.0 & RDS for MySQL 8.0 Sysbench 效能測試結果（吞吐量）
表1 OceanBase 社群版 4.0 & RDS for MySQL 8.0 Sysbench 效能測試結果（吞吐量和響應時間）
寫在最後
無論是對大規格 TPC-C 測試中上千臺機器下極致效能的追逐，還是對小規格 4C16G 單臺機器測試下極致的資源使用，背後始終不變的是 OceanBase 的初心：讓資料管理和使用更簡單。把複雜留給自己，把簡單留給使用者，是每一位 OceanBase 工程師的信念。OceanBase 還在快速成長，也還並不完美。無論是更大規格下的效能最佳化，還是更小規格下的資源節省，我們都還有大量的工作要做。OceanBase 社群版 4.0 版本已經上線，我們也期待和所有使用者一起，打造一款真正好用、通用的資料庫。