資料庫是資訊社會的基礎設施，通過開放開源助力資料庫技術的快速發展，建構新一代資料基礎設施是大勢所趨！在“2021雲栖大會 . OceanBase 原生分布式資料庫論壇” 上，OceanBase CTO 楊傳輝為大家帶來了一場主題為《OceanBase 一體化架構助力核心系統更新》的演講。
01核心場景背後的一體化架構技術
演講開始，楊傳輝從核心場景背後的一體化架構技術談起，列舉了使用者使用分布式資料庫時的兩類需求并做了解釋。第一種是分布式、擴充性、高可用需求，第二種是對資料庫本身功能和性能的要求。
目前，很多客戶業務發展很快，是以每隔一段時間就需要對資料庫進行擴容。盡管經典資料庫采用 IOE 架構，基于高可靠硬體做容錯，但是即使使用大機也可能發生故障，且發生故障時隻能等待廠商恢複。另一方面，經典資料庫中的備庫隻是用來做讀取，甚至某些備庫隻做故障恢複沒有辦法做寫入，造成了大量的資源浪費。
而大多客戶隻想要一個資料庫，在一套系統裡一并支援 OLAP 和 OLTP ，并保證資料分析操作不會影響線上交易的業務。同時在一家公司的多個部門之間，資料庫不會産生幹擾。當某個部門資料庫出現問題時，比如說寫的SQL 不穩定，不會影響其它部門。
在對客戶需求進行分析以後，楊傳輝談到目前資料庫領域最大的趨勢——融合。這裡的融合指的是分布式和資料庫的融合，當下的分布式資料庫已經進入了第三次疊代期。
最早一次疊代是分布式存儲系統，當時被叫做 NoSQL。因為很難保證跨機分布式事務的高效性和強一緻，是以最早的做法就是犧牲一緻性，犧牲 SQL 來換取分布式的擴充性和高可用能力，那時候隻支援 NoSQL。當 NoSQL 發展到一定階段，大家發現它不再好用，還是 SQL 更符合人類思維，此時第二代分布式資料庫誕生，本質是在第一代 NoSQL 的基礎之上，引入了 SQL 文法支援，支援一些基本的 SQL 功能，也被稱為可擴充的 SQL 處理，但犧牲了單機性能和成本，且很難應用到核心場景。
發展到第三代時，最大差别就在于兼顧了分布式的擴充性和單機性能。盡管第三次疊代的底層還是原生分布式架構，但是它對外展現的是與經典關系型資料庫相同的使用方式，追求單機性能極緻，最終做到單機性能和延遲與經典集中式資料庫基本相當，并且對“ HTAP ”進行了深度挖掘，進而滿足了核心系統要求。
最早的資料庫沒有區分 OLTP 和 OLAP，無論是關系模型、事務模型還是代價優化器，都沒有針對 OLTP 或者 OLAP 場景。然而，早期資料庫采用集中式架構，随着使用者和應用場景不斷增多，資料庫的處理能力成為瓶頸，于是有了把資料分析從資料庫中拆分出來的做法，并引入了 OLAP 和資料倉庫這兩個概念。随着雲計算和分布式計算的不斷發展，可以通過分布式架構不斷提升資料庫的處理能力，于是又有了把 OLTP 和 OLAP 融合在一起的趨勢，這也就需要把國外提出的HTAP 理念在中國作進一步創新結合。
02完全自研+融合核心場景的核心優勢
楊傳輝進一步闡述了一體化架構充分融合分布式和集中式架構的優勢。
一方面它的底層仍然是原生分布式架構，可以永遠線上無限擴充，且不需要考慮容量和伺服器故障，所有硬體問題都由軟體做處理和容錯，基于分布式架構之上對外展現更加符合使用者使用習慣。與經典資料庫相容的 HTAP 架構、單機性能和延遲與經典資料庫也基本相當。
對于一體化架構的核心理念，需要開發者開放心态充分把分布式、雲計算最新技術融入到我們的資料庫裡面，同時站在資料庫幾十年的發展基礎之上再做創新。楊傳輝進一步強調了OceanBase 的核心技術理念：堅持完全自研、堅持原生分布式、堅持核心場景。因為原生分布式一定要重視性能，完全掌控核心，應用到核心場景才可以代表未來。
目前，國内的資料庫産品主要有兩條研發路線：第一是基于開源做二次開發的主流路線；第二則是完全自主研發的路線。兩條路線各有優劣，基于開源做二次開發，其好處是剛開始投入成本比較低，但後期發展會面臨瓶頸，完全自研則可以完全百分之百掌控核心，做出有靈魂的資料庫，但前期投入成本特别高，周期甚至長達十年二十年。
楊傳輝以 OceanBase 現身說法：“剛開始的初心是要做比 Oracle 更為強大的下一代分布式資料庫，那麼走開源路線肯定做不到。開源資料庫離 Oracle 這樣的商業資料庫有很大的差距，也不具備分布式能力，要做出比 Oracle 更加強大的企業級分布式資料庫，開發必須要完全掌控核心。”
“時至今日，回過頭來看很幸運，因為自研這條路線很正确。2017年，螞蟻集團将所有資料庫完完全全由 Oracle 遷移到 OceanBase，那個時間點也正是 OceanBase 自研系統的能力開始超過開源資料庫的轉折點，OceanBase 數十年成長曆程積累的核心掌控能力，正在不斷拉開與基于開源做二次開發的資料庫的技術代差。”楊傳輝感慨道。
03從技術層面解讀原生分布式架構
對于 OceanBase CEO 楊冰曾在多個場合提及的“把簡單留給使用者，把複雜留給資料庫”，楊傳輝也此從技術層面作了解讀。
OceanBase 的原生分布式架構涉及三個關鍵特性：堅持強一緻、堅持動态擴充、堅持單機性能。 OceanBase 的強同步配置可以做到事務送出沒有資料丢失，且當伺服器發生故障是也能自動容錯，保證持續高可用，這也是真正的原生分布式資料庫的理念，我們也不會在 PoC 的時候做一種配置，在正式生産的時候用另一種配置。原生分布式架構對應的一個方案就是基于中間件分庫分表，二者最大的差别在于原生分布式架構支援動态按需擴充，基于中間件分庫分表方案隻能做人工靜态擴充。
從擴容方面來看，OceanBase 所有的擴容不是雙倍或四倍擴容，而是按需擴容；因為不是靜态擴容，是以不需要 DBA 做大量人工運維操作，隻需要增加伺服器就可以，所有擴容操作由資料庫背景自動處理，且可以確定擴容時不會影響線上服務。以支付寶雙十一實踐為例，雙十一峰值壓力是平常的幾十倍，通常需要在雙十一前幾天完成擴容，雙十一完成後盡快下線。這樣的操作涉及到上萬台資料庫節點和幾十萬個資料庫變更，OceanBase 都能在小時級自動完成，不需要人為變更，大大提高了效率。
正如楊傳輝提到的：“OceanBase 堅持核心場景，走從 OLAP 到 HTAP 的發展路線，始終相信應用才是資料庫技術的第一推動力，一個資料庫最終能不能做好，有沒有很多應用來使用，關鍵要看有沒有核心場景打磨。OceanBase 在不斷實踐中進一步觸及到金融、網際網路等其他行業，在這個過程中，我們最大的競争力就是穩定可靠，這不是某一個技術名額可以衡量，而是通過多年打磨的核心掌控能力。今天很多核心場景已經開始使用我們的國産資料庫，毫無疑問，面對新場景不可能不出問題，但我們的團隊有信心可以解決這些問題。”
而怎麼做出穩定可靠的系統，需要涉及的點很多，從架構設計，到研發，到寫代碼都需要兼顧，因為任何環節出現問題，都可能導緻核心場景的重大故障，從設計角度來看，兩個技術點需要特别關注——資料的正确性和運作的連續性。
楊傳輝在分析 OceanBase 的天然優勢也提到：唯一一個在資料庫核心裡面持續校驗資料正确性的系統。即使出現 bug，也可以線上下模拟運作時通過校驗能力發現風險及時完善。OceanBase 在生産環境中經曆過極端異常場景的長時間檢驗，每年雙十一大促都會有多台伺服器發生各種類型的故障，OceanBase 總是能夠自動處理。業内某個非常大型的商業銀行的某次 PoC 測試專門模拟了網絡時斷時續的極端異常場景，最終隻有 OceanBase 通過了該項測試。
04核心場景持續運作 助力使用者平滑遷移
今天的資料庫，都有三個基本子產品：存儲子產品、事務子產品和 SQL 子產品。我們談到的一體化架構是相對分離架構來說的，為了實作分布式擴充性，一種比較簡單的做法就是分離架構，把事務和存儲分離開來，隻需要在存儲層實作分布式的擴充性和高可用，不涉及事務層。這種方式的好處是實作簡單，問題在于額外增加了事務層與存儲層的一次 RPC 調用，且分布式事務的 overhead 大幅增加，在架構上犧牲了性能和延遲，無法應用到核心場景。一體化架構把存儲和事務有機地融合起來，在事務層實作分布式的擴充性。這種做法的好處是架構上沒有犧牲性能，通過代碼實作的不斷追求極緻，最終能夠做到單機性能與集中式資料庫基本相當，能夠應用到核心場景，問題在于實作複雜度較高。
核心場景持續運作的成長程序中，經常有伺服器發生故障。盡管經典資料庫一般會有主備模式做高可用，但這種模式理論上無法同時保證強一緻和高可用。而 OceanBase 的原生分布式資料庫系統在支付寶交易業務上，首次把 Paxos 協定引入了金融級資料庫，并最終做到 RPO 等于0，RTO 小于30秒。目前，螞蟻集團已經實作了三地五中心的部署，而這個部署正是應用驅動出來的，螞蟻集團早期在杭州部署三個機房，突然有一次施工同時挖斷了兩條離得比較近的光纖，兩個機房同時中斷，造成服務不可用，于是後來我們把架構變成了三地五中心。
此外，OceanBase 還可以通過分區技術實作線上擴容不停服務，當我們處理能力不足的時候可以動态增加伺服器，以分區粒度把資料遷移到新增的空閑伺服器上，最終做到按需擴容，不影響業務。雙十一的時候也不需要人為操作，可自動實作在雲上做彈性擴容。
OceanBase 實作了 DataBase as a Service（DBaaS）架構，在資料庫内部實作多租戶之間的隔離，進而提升部署密度，降低運維成本。OceanBase 的存儲成本很低，通過線上極緻壓縮技術，最終在螞蟻做到存儲成本隻有 MySQL/Oracle 的1/3。另外，與經典資料庫不同點在于，所有節點都是可讀可寫，避免了資源浪費。OceanBase 每年都會持續做性能優化，最新的3.2版本相比上一個2.x大版本sysbench讀寫性能提升了61%，延遲降低了34%，其它隻讀、隻寫等各個場景也有不同程度的提升。
為了實作平滑遷移，除了透明分布式跟文法相容能力以外，楊傳輝提到了一站式遷移工具，包含兩個工具：一個是資料庫遷移服務OMS，提供遷移能力的同時支援資料的回流，一鍵切流，反向同步資料，發生任何問題可以切換回原系統。另外一個是OMA評估源資料庫的SQL、存儲過程、對象、Schema等文法相容性。我們在某個大型客戶遷移了上千萬行存儲過程的代碼，基本做到了平滑遷移、無縫替代。
在演講的結尾，楊傳輝宣布 OceanBase 3.2版本正式釋出，作為 3.0釋出會之後第一個大的商業版本，主要包含五大核心技術更新。（詳情可跳轉
《OceanBase 3.2 正式釋出 | 更硬核的 HTAP，TPC-H 性能提升6倍！》）
正如楊傳輝所說：面向未來，我們還是會堅持将原生分布式資料庫應用到核心場景，并且在核心場景基礎之上拓展更多場景，最終提供分布式資料庫堅實技術底座。一方面，針對核心場景，提升并發性能降低延遲，增強 MySQL/Oracle 相容性；針對通用場景，持續提升 HTAP 能力，支援列存，适配更多 OLAP 生态工具。另一方面，通過開源發展更多使用者，堅持把核心完全開源作為我們的長期方向。最終的目标是讓每一個使用者都能簡單地使用 OceanBase，讓每一個使用者都可以快速擷取螞蟻集團11年資料庫技術積累。