OceanBase CTO 楊傳輝：下一代企業級分散式資料庫的一體化設計

本文作者楊傳輝，花名日照，現任 OceanBase CTO、團隊創始成員。本文根據4月28日的直播《下一代分散式資料庫一體化設計》內容整理。

大家好，我是楊傳輝，上個月和大家討論了分散式資料庫經歷的三代演變：第一代 NoSQL 系統，第二代可擴充套件的 SQL 處理，到下一代透明擴充套件的企業級資料庫。與第二代相比，下一代企業級分散式資料庫採用一體化設計，融入經典資料庫精細化的設計理念，追求極致效能。本次直播是上次的延續，將介紹下一代企業級分散式資料庫的一體化設計。

把穩定的系統做高效，遠比把高效的系統做穩定更容易

開始之前，首先穿插一段我對系統設計理念的思考。每個系統設計時都需要考慮架構、穩定性和效能，這三者之間的關係是什麼？一個經典的規律是“ 把穩定的系統做高效，遠比把高效的系統做穩定更容易”。

最難的是從 0 到 1 把系統做穩定。有了穩定的系統，接下來逐步最佳化效能往往會比較順利，直到遇到系統架構的效能天花板。因此，系統架構設計之前，首先要考慮清楚系統的目標和效能天花板，接著基於正確的架構把系統做穩定，最後最佳化效能。如果系統的目標是成為世界級的企業級分散式資料庫，那麼，架構設計之初就必須把追求極致效能作為一個必選項，這將從根本上改變企業級分散式資料庫的設計。

回顧一下三代分散式資料庫：

為了解決可擴充套件性和併發處理效能問題，分散式資料庫經歷了三次迭代：

第一代是分散式儲存系統，也稱為 NoSQL，2013 年之前比較流行，基本思路是犧牲 SQL，犧牲事務、一致性和企業級功能，只支援簡單的 KV 操作從而做到可擴充套件；

第二代是分散式資料庫，以 Google Spanner 系統為代表，支援可擴充套件的 SQL，在第一代 NoSQL 系統的基礎之上引入了 SQL 和分散式事務，保證強一致性，但是不太注重 SQL 相容性和價效比，單機效能往往比較差；

第三代是透明擴充套件的企業級資料庫，也就是我說的“下一代企業級分散式資料庫”。以 OceanBase 為代表。分散式架構對業務透明，支援完備的相容 MySQL 和 Oracle 的企業級功能，支援 HTAP 混合負載，採用 C 語言實現，單機效能很高，且系統架構的效能天花板很高，可以基於該架構追求極致效能。

企業級分散式資料庫除了做好分散式，更要堅守初心

經典資料庫包含儲存、事務、SQL 這幾個核心引擎，以及基於這些核心引擎之上的資料庫功能和效能、成本、安全、可靠等企業級特性。 企業級分散式資料庫在經典資料庫的基礎之上引入了分散式，實現了高可用和可擴充套件。雖然分散式資料庫在原生分散式架構上產生了很多創新技術，但在資料庫的功能、效能、精細化程度上還有一段很長的路要走。

企業級分散式資料庫除了做好分散式，更要堅守資料庫的初心：提升功能相容性和單機效能。經典資料庫的關鍵技術經受住了時間的考驗，例如 SQL 標準、事務模型，企業級分散式資料庫需要向經典資料庫學習 SQL 相容性。今天，分散式領域很熱門的一些技術，例如儲存計算分離、HTAP，最早也出自經典資料庫，且經典資料庫在精細化程度上往往做得更好。

儲存計算分離

相信今天很多人都聽過儲存計算分離，但不同系統的做法差別很大。 業界有三種儲存計算分離方案：

第一種本質是基於中介軟體分庫分表，後端的資料庫表示儲存，中介軟體表示計算，這種方案是真正的儲存計算分離嗎？顯然不是，我也把這種方案叫做“偽儲存計算分離”；

第二種把系統劃分為 SQL、事務和分散式 KV 層，分散式 KV 表示儲存，SQL 和事務表示計算，儲存和計算採用松耦合設計，這種方案能夠解決可擴充套件的 SQL 處理問題，但每次操作都涉及到計算和儲存之間的遠端訪問，且事務相關後設資料儲存到分散式 KV 表格中，增加了事務處理的額外開銷，犧牲了效能；

第三種採用緊耦合設計，SQL、事務和 KV 表示計算，KV 層資料塊依賴的分散式檔案系統表示儲存。這種方案來自於經典資料庫的 IOE 架構，SQL、事務和 KV 層表示計算，底層依賴 EMC 的 SAN 儲存。Amazon Aurora 借鑑了經典資料庫的儲存計算分離架構，並在雲原生環境下發揚光大，成為最終的事實標準。

為了追求極致效能， 我認為，企業級分散式資料庫應該向經典資料庫學習原生儲存計算分離技術，我推薦第三種方案。

HTAP

HTAP 也是分散式資料庫領域的一個熱門概念。有兩種做法：

第一種是主備庫物理隔離，主庫做 OLTP，備庫做 OLAP，主備之間透過 redo 日誌做同步，備庫與主庫之間有一定的延遲。第二種是在同一套引擎實現 OLTP 和 OLAP 混合負載，區分 OLTP 和 OLAP 請求所在的資源組，對資源組進行邏輯隔離。

第一種方案實現相對簡單，但由於產生了更多資料冗餘，價效比較低；第二種方案實現相對複雜，但採用一體化設計，價效比更高。第二種方案來自經典資料庫，例如 Oracle、SQL Server。

我認為， 企業級分散式資料庫應該學習 HTAP 技術，採用第二種方案。

極致效能

現代資料庫的效能瓶頸往往在 CPU，不在磁碟 IO。為了最佳化 CPU，經典資料庫往往會採用本地化處理：

• 儘量減少跨伺服器操作，做到伺服器本地化；

• 儘量在同一個執行緒完成全部 SQL 操作，做到 CPU 核心本地化；

• 儘量將每次訪問的資料放在一起命中 CPU 二級快取，做到 CPU 快取區域性化。

• 在程式碼層面追求精細化，主要程式碼採用 C 語言實現，少量關鍵路徑程式碼甚至採用組合語言實現，最佳化每個SQL 運算元的 CPU 指令數。手動管理記憶體，充分利用資料庫記憶體生命週期的特點提升記憶體利用率，避免語言層面記憶體自動垃圾回收的額外效能開銷。

企業級分散式資料庫還應該向經典資料庫學習精細化設計，從而獲得極致效能。資料庫最佳化到最後往往是摳細節。怎麼理解系統設計的天花板？打個比方，如果一個分散式資料庫設計之初沒有考慮極致效能，那麼，無論怎麼做，也只能做出對標晶片 28nm 的技術；只有設計之初就把極致效能考慮在內，才可能做出對標晶片 7nm，5nm，甚至 3nm 的技術。當然，7nm，5nm 的技術架構複雜度會遠遠高於 28nm，前面幾年做起來會比較慢，但等到架構穩定之後才會逐步釋放技術紅利。

企業級分散式資料庫的一體化設計

企業級分散式資料庫借鑑經典資料庫的一體化設計理念，追求極致效能，本質是一個支援動態擴充套件和無損容災的 MPP 架構。

在 SQL 層，借鑑企業級資料庫，例如 Oracle 的 HTAP 設計，在同一套引擎同時支援 OLTP 和 OLAP 混合負載；在事務層，實現了支援自動容錯的分散式事務和多版本併發控制，保證與經典集中式資料庫對標的強一致 ACID；在儲存層，透過分割槽級 Paxos 日誌同步實現高可用和自動擴充套件，支援靈活的儲存架構，包括本地儲存，以及儲存計算分離。

當企業級分散式資料庫既具備可擴充套件性，又具備良好的功能相容性和價效比，並在 TPC-C、TPC-H 等資料庫 benchmark 和核心應用場景上都取得突破時，才是名副其實的下一代分散式資料庫。

企業級分散式資料庫的 Paxos

企業級分散式資料庫支援分割槽級 Paxos 日誌同步，透過 Paxos 選舉協議實現高可用和自動容錯，RPO=0，RTO<30 秒；透過分割槽級日誌同步做到可擴充套件，支援動態增加伺服器提升系統的處理能力，無需人工干預。

2014 年，OceanBase 將 Paxos 協議引入到資料庫，首次在金融核心系統做到 RPO=0，也正是依靠這項技術，成為支付寶的最終選擇。基於 Paxos 協議，OceanBase 繼續研發了同城三機房、兩地三中心、三地五中心等多種靈活的容災部署方案。

經典集中式資料庫往往採用主備同步方案，有兩種同步模式：第一種是強同步，每個事務操作都需要強同步到備機才可以應答使用者，這種方式能夠做到伺服器故障不丟資料，但必須停服務，無法保證可用性；另外一種是非同步，每個事務操作只需要在主機成功就可以應答使用者，這種方式能夠做到高可用，但主庫和備庫之間資料不一致，備庫切換為主庫之後會丟資料。

強一致和高可用作為資料庫最重要的兩個特性，在主備同步模式下，魚和熊掌不可兼得。Paxos 是一種基於多數派的分散式投票協議，每個事務需要成功寫入超過一半伺服器才可以應答使用者。俗話說得好，“三個臭皮匠頂過一個諸葛亮”，假設總共有 3 臺伺服器，每個事務操作要求至少在 2 臺伺服器上成功，無論任何一臺伺服器發生故障，系統中還有 1 臺包含了全部資料的伺服器能夠正常工作，從而做到完全不丟資料，並在 30 秒之內選出新的主庫恢復服務，RPO 等於 0，RTO 小於 30 秒。所有保證 RPO=0 的協議都是 Paxos 協議或者 Paxos 協議的變種，Raft 協議就是其中之一。

Raft 協議是 Paxos 協議的一種簡化，原理是在 Paxos 協議基礎上增加了一個限制，要求按順序投票，也就意味著資料庫 redo 日誌順序同步。Raft 協議的好處是實現簡單，但每個分割槽只能順序同步，併發同步效能較差，在弱網環境下事務卡頓現象機率較高；Paxos 協議支援亂序同步，雖然實現更加複雜，但併發同步效能好，在弱網環境下事務卡頓現象機率較低。Raft 類系統發明了一個概念叫：Multi-Raft，指的是每個分片執行一個 Raft 協議。這個概念和經典的 Multi-Paxos 是不對等的，Multi-Paxos 指的是一個分片內做併發，Multi-Raft 指的是多個分片之間做併發，如果單個分片寫入量很大，仍然是會產生效能瓶頸的。

Paxos 和 Raft 兩種協議都是合理的做法，我個人建議採用併發效能更高的原生 Paxos 協議，這也是頂尖網際網路公司在大規模分散式儲存系統的主流做法，包括 Google  Spanner，Microsoft Azure，Amazon  DynamoDB，OceanBase 等等。

經典資料庫往往採用伺服器級靜態日誌流，主庫和備庫之間只有一個單一的日誌流，這種方式一般不支援動態擴容。企業級分散式資料庫可擴充套件性的關鍵在於採用分割槽級的動態日誌流，從而很自然地實現分割槽級負載均衡，用於動態擴容。儲存計算分離可以借鑑 Oracle 的自動儲存管理技術，也就是 ASM 技術，透過統一介面管理本地磁碟和遠端分散式儲存，每個資料塊可以寫入本地磁碟，也可以寫入遠端分散式儲存。由於資料塊往往可以透過 buffer pool 快取到 SQL 計算節點，大部分場景能夠做到本地化處理，效能較好。這也是 Oracle RAC 系統中採用的方案。

今天參與直播的同學應該有很多從事 DBA 工作，我過去接觸過的很多 DBA 都有一個固有的認知：強同步意味著效能大幅降低，例如 Oracle DataGuard 開啟強同步之後效能大幅下降。

企業級分散式資料庫面向 Paxos 強同步設計，透過非同步提交和批次提交（Group Commit）技術規避強同步對系統效能的影響。事務提交寫日誌任務後立即釋放工作執行緒，釋放出來的工作執行緒可以處理其它併發事務，等到日誌強同步成功後再透過非同步任務回撥應答使用者。另外，寫日誌時可以將多個併發事務的日誌合併成一批寫入同一個緩衝區並強同步到備機。OceanBase 的實踐經驗表明，透過各種最佳化手段，能夠將強同步對系統併發效能的損耗減少到 5%~10% 以內。

企業級分散式資料庫支援自動容錯的分散式事務和多版本併發控制。分散式資料庫的難點在於分散式場景下的故障恢復和併發控制，其中，大量程式碼邏輯都是用於異常處理的。很多同學都有過一個疑惑，分散式資料庫不就是單機資料庫加上 Sharding，為什麼會這麼難呢？根本原因在於容錯處理和極致效能，導致同步操作變成非同步操作，需要給每個操作增加錯誤處理，且這些問題是耦合在一起的，需要在架構層面統一考慮清楚，任何一個地方出現漏洞都可能導致架構方案推倒重來。

很多場景都會遇到分散式事務的需求，有多種不同的應對方案，中介軟體 XA 的做法是依賴底層資料庫，只要底層資料庫持續可用，就能很簡單地進行異常處理，不會出現經典的協調者故障導致的阻塞問題；NoSQL 系統的做法是迴避一致性和分散式事務，只支援單行事務或者單機事務。

對於企業級分散式資料庫，必須直面問題，採用 Paxos 加兩階段提交協議來實現自動容錯的分散式事務：

Paxos 協議實現自動容錯，兩階段提交協議保證分散式事務的原子性。很多分庫分表方案也支援分散式事務，但往往不支援容錯，伺服器故障時需要人肉處理掛住的分散式事務。這種方案也許能夠透過 PoC 測試，但無法大規模應用到生產系統。

兩階段提交協議把事務提交過程分成了 prepare 和 commit 兩個階段，相比經典資料庫的事務提交，兩階段提交額外增加了一個階段。為了避免兩階段提交協議增加事務延遲，可以採用一階段最佳化技術。與兩階段提交的經典實現不同，協調者不需要持久化狀態，而是在故障恢復時由參與者共同協商。基於這種實現方案，prepare 成功即可應答使用者，不需要等到第二輪 commit 成功再應答使用者。最終，只有一次寫日誌延遲和一次 RPC 同步延遲，且寫日誌與 RPC 同步可以並行起來，追求極致。當然，這種方案增加了故障處理的複雜度。

多版本併發控制來自經典資料庫，早期資料庫的併發控制往往基於鎖來實現，資料庫事務的四種隔離級別，例如repeatable read，就是針對鎖機制量身定製的。然而，鎖機制導致讀寫互斥，系統併發效能較差。今天，除了IBM DB2 仍然在使用細粒度鎖做併發控制之外，其它主流資料庫，包括 Oracle、SQL Server、OceanBase 都清一色地採用多版本併發控制，隔離級別為快照隔離（snapshot isolation）。這種方案的好處在於寫入操作不影響讀取，更適合併發越來越大的分散式資料庫。Oracle 今天很成功，除了商業因素之外，幾個核心技術選型也非常關鍵，例如選擇多版本併發控制而不是細粒度鎖，一體化的 Oracle 叢集技術，一體化的混合負載技術。

多版本併發控制有兩種比較經典的實現：一種是 MySQL 資料庫中使用的 read view，另外一種是 Oracle 等商業資料庫中使用的 read version。

其中，read view 方案的事務沒有提交版本號，每次讀取時需要獲取所有正在進行中的事務列表，擴充套件性比較差；read version 方案的每個事務都有唯一的提交版本號（相當於 Oracle 資料庫中的 scn ），每次讀取時只需要獲取最新的事務版本號即可，擴充套件性比較好。

企業級分散式資料庫採用 read  version 方案，每個事務執行過程中的產生的修改都以未提交資料儲存在系統中，讀取時根據快照版本選擇系統中的歷史資料，不會見到正在修改的資料，保證事務的原子性。如上圖，賬戶 A 在機器 1，賬戶 B 在機器 2，賬戶 A 給賬戶 B 轉賬 50，快照讀取要麼讀到轉賬之前的資料，要麼讀到轉賬之後的資料，不會出現讀取到一半的情況。

為了獲取全域性一致的 read version，有兩種實現方案：一種方案是經典的全域性版本號生成器，另外一種方案是 Google Spanner 系統中採用的 TrueTime。TrueTime 的好處在於支援全球級跨地域可擴充套件能力，缺點是每個事務額外增加了 7 到 10 毫秒的延遲。企業級分散式資料庫應該採用全域性版本號生成器的方案，減少事務延遲和應用適配成本。當然，全域性版本號生成器本質上是一個單點，需要解決高可用自動容錯的問題，以及事務版本號生成的效能問題。

企業級資料庫的 HTAP

企業級分散式資料庫借鑑經典資料庫的 HTAP 技術，實現了同一套引擎同時處理 OLTP 和 OLAP 混合負載。HTAP 並不是全新的技術，以 Oracle 為代表的經典資料庫一直都在處理企業客戶的混合負載，且精細化程度極高。無論是混合負載，還是儲存計算分離，企業級分散式資料庫都應該從經典資料庫中借鑑經驗，堅守資料庫的本質，站在巨人的肩膀上做創新。

經典資料庫透過行列混合儲存支援 HTAP 混合負載，將一個表格劃分為行組（row group），每個行組內按列儲存，在行存和列存之間尋找一個平衡點。

每個行組都是一個壓縮單位，支援智慧索引和高效壓縮，例如在行組記憶體儲 count、sum 等索引後設資料。另外，Oracle 和 SQL Server 都支援 In Memory 列存，OLTP 查詢訪問磁碟中的行存表，並在記憶體中額外儲存一份列存表專門用於 OLAP 查詢。HTAP 往往指的是同時支援 OLTP 業務和實時 OLAP 業務，這裡需要避免走極端，

由於 HTAP 採用行列混合儲存，對於純粹的離線 OLAP 業務，效能可能不如更加專用的 OLAP 和大資料系統。HTAP 的價值在於更加簡單通用，對於絕大部分中等規模的客戶，資料量不會特別大，只需要一套系統即可。當然，對於超大型網際網路企業，一套系統肯定是不夠的，需要部署多套系統。我們既要不斷探尋更加通用的 HTAP 方案，又要避免 one size fit all，最終的方案很可能是 one size fit a bunch。

HTAP 的另外一個技術挑戰是資源隔離。

偷懶的做法是多副本做物理隔離，主副本做 OLTP 查詢，備副本做 OLAP 查詢。另外一種是經典資料庫中採用的資源組方案，無論是 Oracle 還是 SQL Server，都支援定義不同的資源組，並限制每個資源組可以使用的物理資源。資源組的隔離可以透過類似 SQL Server 資料庫內的 SQLVM 來實現，也可以透過作業系統底層的 cgroup 機制來實現。

資料庫業務往往有三類使用者：OLTP 使用者做線上交易，Batch 使用者做批處理，DSS 使用者做報表，透過資源組限制每類使用者可使用的 CPU、IO、網路資源，從而避免 OLTP 業務受影響。Oracle 最新版本的多租戶隔離就是採用cgroup 機制，OceanBase 也採用了類似的機制，實際效果都很不錯。

相比 MySQL 等開源資料庫，經典商業資料庫的最大價值在於能夠處理複雜查詢和混合負載，企業級分散式資料庫應該向經典資料庫學習 SQL 最佳化和 SQL 執行技術。

經典資料庫採用基於代價的最佳化，且支援基於代價的改寫，很多分散式資料庫的最佳化器依賴開源的 Calcite 框架，由於通用框架的限制，很難做到基於代價的改寫，複雜查詢的支援能力有限。Oracle 最佳化器分成兩個階段：第一個階段序列最佳化，第二個階段並行最佳化，對分散式和並行場景的考慮相對較少，企業級分散式資料庫可以在 Oracle 最佳化器的基礎上做創新，增強分散式和並行能力，支援一階段最佳化，在代價模型中同時考慮單機和分散式代價。

經典資料庫的 SQL 執行能力也非常出色，無論是 TPC-H、TPC-DS 等 benchmark，還是真實的業務場景，單核執行效能都非常好。企業級分散式資料庫應該學習經典資料庫的 SQL 執行技術，包括編譯執行、向量執行、 push 模型，SIMD 處理、基於結構化資料的強型別系統等等。

企業級分散式資料庫 = 經典資料庫 + 分散式

最後做一個小結：企業級分散式資料庫在經典資料庫的基礎之上引入了分散式，實現了高可用和可擴充套件。

企業級分散式資料庫除了做好分散式，更要堅守資料庫的初心，在功能相容性、價效比上下功夫。今天，分散式資料庫領域流行的一些技術，包括儲存計算分離、HTAP，最早都出自經典資料庫，且經典資料庫經過五十多年的實踐，透過應用驅動技術創新做得更加精細。

我認為企業級分散式資料庫是未來的大趨勢，最終能不能走到那一步，取決於我們能否站在經典資料庫這一巨人的肩膀上，深挖經典資料庫的核心技術和理念，在消化理解的基礎上做創新。企業級分散式資料庫在分散式架構上做了很多創新，包括分割槽級 Paxos 日誌同步實現高可用和可擴充套件，支援容錯的分散式事務和多版本併發控制，但對經典資料庫的核心技術理解還需要加強，例如深入理解 Oracle 和 SQL Server 等企業級資料庫的 HTAP 和儲存計算分離技術。

我也借這個機會在這裡呼籲分散式資料庫領域的從業者更多地向經典資料庫借鑑一體化設計理念，做出下一代分散式資料庫，堅守資料庫的初心。

以上是我的分享，本次分享是《下一代分散式資料庫設計思考》的延續，OceanBase 團隊後續會持續不斷加強技術分享。感謝大家的關注，希望和大家繼續討論分散式資料庫的架構設計問題，也期待大家的建議。謝謝！

附《下一代分散式資料庫一體化設計》直播觀眾 QA

為什麼 OceanBase 要基於同一套引擎實現 HTAP 呢？

A：經典資料庫，比如 Oracle 或者 SQL Server，其實都是在一套引擎下支援 HTAP 混合負載，這種方式做得更精細，價效比更高，且經典資料庫透過類似 cgroup 等技術已經解決了 TP 和 AP 隔離的問題。OceanBase 技術上可以更多借鑑發展了五十多年的經典關聯式資料庫。

OceanBase 最新版中對標準 SQL 的支援度是多少？

A：實際應用中，MySQL 業務大部分都能做到平滑遷移，Oracle 模式下基本的 Oracle 功能也都是支援的，基本只需要很少的改動就可以比較平滑地由 Oracle 遷移到 OceanBase。

OceanBase 作為一個以 TP 見長的資料庫，AP 計算能力怎麼樣呢？

A：AP 主要採用行列混合儲存、編譯執行、向量引擎、基於代價的查詢改寫和最佳化等技術，再加上 OceanBase 的可擴充套件性很好，OceanBase 在 AP 領域裡面的實時分析部分是業界領先的。當然，對於離線大資料處理，Spark 等大資料方案可能是更合適的選擇。

資料量大概多少 可以使用 OceanBase 做 AP 呢？

A：這個是看業務需求，100G 到 PB級 不設限。AP 是 OceanBase 提供的一個能力，資料量小，可以把並行設定小一些，用的計算資源就小。資料規模大了，給計算資源多一些就好了。本質上並沒有一個“量”的限制。AP 的能力，體現在把機器硬體資源充分調動起來的能力，生成高效的並行計劃等方面的能力。

OceanBase 的效能和機器數量的關係是什麼？

A：可以看看 OceanBase 的 TPC-C 報告，TPC-C 場景 1500 多臺機器規模的情況下基本都是線性擴充套件的。

更多問答，可以訪問  OceanBase 官網 “ 開發者” 版塊，在 “ 問答區” 和 OceanBase CTO 楊傳輝直接互動。