本文作者楊傳輝，花名日照，現任 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 楊傳輝直接互動。
點選連結
https://www.oceanbase.com/community/answer，一鍵直達問答區。