資料庫是資訊社會的基礎設施，透過開放開源助力資料庫技術的快速發展，
構建新一代資料基礎設施是大勢所趨！在“2021雲棲大會 . OceanBase 原生分散式資料庫論壇” 上，OceanBase CTO 楊傳輝為大家帶來了一場主題為
《OceanBase 一體化架構助力核心系統升級》
的演講。
演講開始，楊傳輝從核心場景背後的一體化架構技術談起，
列舉了使用者使用分散式資料庫時的兩類需求並做了解釋。
第
一種是分散式、擴充套件性、高可用需求，第二種是對資料庫本身功能和效能的要求
。
當前，很多客戶業務發展很快，因此每隔一段時間就需要對資料庫進行擴容。儘管經典資料庫採用 IOE 架構，基於高可靠硬體做容錯，但是即使使用大機也可能發生故障，且發生故障時只能等待廠商恢復。另一方面，經典資料庫中的備庫只是用來做讀取，甚至某些備庫只做故障恢復沒有辦法做寫入，造成了大量的資源浪費。
而大多客戶只想要一個資料庫，在一套系統裡一併支援 OLAP 和 OLTP ，並保證資料分析操作不會影響線上交易的業務。同時在一家公司的多個部門之間，資料庫不會產生干擾。當某個部門資料庫出現問題時，比如說寫的SQL 不穩定，不會影響其它部門。
在對客戶需求進行分析以後，楊傳輝談到
當前資料庫領域最大的趨勢——融合。這裡的融合指的是分散式和資料庫的融合，
當下的分散式資料庫已經進入了第三次迭代期。
最早一次迭代是分散式儲存系統，當時被叫做 NoSQL。因為很難保證跨機分散式事務的高效性和強一致，
所以最早的做法就是犧牲一致性，犧牲 SQL 來換取分散式的擴充套件性和高可用能力，那時候只支援 NoSQL。當 NoSQL 發展到一定階段，大家發現它不再好用，還是 SQL 更符合人類思維，
此時第二代分散式資料庫誕生，
本質是在第一代 NoSQL 的基礎之上，引入了 SQL 語法支援，支援一些基本的 SQL 功能，
也被稱為可擴充套件的 S
QL 處理，但犧牲了單機效能和成本，且很難應用到核心場景。
發展到第三代時，最大差別就在於兼顧了分散式的擴充套件性和單機效能。儘管第三次迭代的底層還是原生分散式架構，但是它對外體現的是與經典關係型資料庫相同的使用方式，追求單機效能極致，最終做到單機效能和延遲與經典集中式資料庫基本相當，並且
對“ HTAP ”進行了深度挖掘，
從而滿足了
核心系統要求。
最早的資料庫沒有區分 OLTP 和 OLAP，無論是關係模型、事務模型還是代價最佳化器，都沒有針對 OLTP 或者 OLAP 場景。
然而，早期資料庫採用集中式架構，隨著使用者和應用場景不斷增多，資料庫的處理能力成為瓶頸，於是有了把資料分析從資料庫中拆分出來的做法，並引入了 OLAP 和資料倉儲這兩個概念。
隨著雲端計算和分散式計算的不斷髮展，可以透過分散式架構不斷提升資料庫的處理能力，於是又有了把 OLTP 和 OLAP 融合在一起的趨勢，
這也就需要把國外提出的HTAP 理念在中國作進一步創新結合。
楊傳輝進一步闡述了一體化架構充分融合分散式和集中式架構的優勢。
一方面它的底層仍然是原生分散式架構，可以永遠線上無限擴充套件，且不需要考慮容量和伺服器故障，所有硬體問題都由軟體做處理和容錯，基於分散式架構之上對外體現更加符合使用者使用習慣。與經典資料庫相容的 HTAP 架構、單機效能和延遲與經典資料庫也基本相當。
對於一體化架構的核心理念，需要開發者開放心態充分把分散式、雲端計算最新技術融入到我們的資料庫裡面，同時站在資料庫幾十年的發展基礎之上再做創新。楊傳輝進一步強調了
OceanBase 的核心技術理念：堅持完全自研、堅持原生分散式、堅持核心場景。
因為原生分散式一定要
重視效能，完全掌控核心，應用到核心場景才可以代表未來。
目前，國內的資料庫產品主要有兩條研發路線：第一是基於開源做二次開發的主流路線；第二則是完全自主研發的路線。
兩條路線各有優劣，基於開源做二次開發，其好處是剛開始投入成本比較低，但後期發展會面臨瓶頸，完全自研則可以完全百分之百掌控核心，做出有靈魂的資料庫，但前期投入成本特別高，週期甚至長達十年二十年。
楊傳輝以 OceanBase 現身說法：“剛開始的初心是要做比 Oracle 更為強大的下一代分散式資料庫，那麼走開源路線肯定做不到。開源資料庫離 Oracle 這樣的商業資料庫有很大的差距，也不具備分散式能力，
要做出比 Oracle 更加強大的企業級分散式資料庫，開發必須要完全掌控核心。
”
“時至今日，回過頭來看很幸運，因為自研這條路線很正確。2017年，螞蟻集團將所有資料庫完完全全由 Oracle 遷移到 OceanBase，那個時間點也正是 OceanBase 自研系統的能力開始超過開源資料庫的轉折點，OceanBase 數十年成長曆程積累的核心掌控能力，正在不斷拉開與基於開源做二次開發的資料庫的技術代差。”楊傳輝感慨道。
對於 OceanBase CEO 楊冰曾在多個場合提及的“把簡單留給使用者，把複雜留給資料庫”，楊傳輝也此從技術層面作了解讀。
OceanBase 的原生分散式架構涉及三個關鍵特性：堅持強一致、堅持動態擴充套件、堅持單機效能。
OceanBase 的強同步配置可以做到事務提交沒有資料丟失，且當伺服器發生故障是也能自動容錯，保證持續高可用，這也是真正的原生分散式資料庫的理念，我們也不會在 PoC 的時候做一種配置，在正式生產的時候用另一種配置。
原生分散式架構對應的一個方案就是基於中介軟體分庫分表，二者最大的差別在於原生分散式架構支援動態按需擴充套件，基於中介軟體分庫分表方案只能做人工靜態擴充套件。
從擴容方面來看，OceanBase 所有的擴容不是雙倍或四倍擴容，而是按需擴容；
因為不是靜態擴容，所以不需要 DBA 做大量人工運維操作，只需要增加伺服器就可以，所有擴容操作由資料庫後臺自動處理，且可以確保擴容時不會影響線上服務。
以支付寶雙十一實踐為例，雙十一峰值壓力是平常的幾十倍，通常需要在雙十一前幾天完成擴容，雙十一完成後儘快下線。
這樣的操作涉及到上萬臺資料庫節點和幾十萬個資料庫變更，OceanBase 都能在小時級自動完成，不需要人為變更，大大提高了效率。
正如楊傳輝提到的：“
OceanBase 堅持核心場景，走從 OLAP 到 HTAP 的發展路線，始終相信應用才是資料庫技術的第一推動力，一個資料庫最終能不能做好，有沒有很多應用來使用，關鍵要看有沒有核心場景打磨。
OceanBase 在不斷實踐中進一步觸及到金融、網際網路等其他行業，在這個過程中，我們最大的競爭力就是穩定可靠，這不是某一個技術指標可以衡量，而是透過多年打磨的核心掌控能力。今天很多核心場景已經開始使用我們的國產資料庫，毫無疑問，面對新場景不可能不出問題，但我們的團隊有信心可以解決這些問題。”
而怎麼做出穩定可靠的系統，需要涉及的點很多，從架構設計，到研發，到寫程式碼都需要兼顧，因為任何環節出現問題，都可能導致核心場景的重大故障，從設計角度來看，兩個技術點需要特別關注——資料的正確性和執行的連續性。
楊傳輝在分析 OceanBase 的天然優勢也提到：
唯一一個在資料庫核心裡面持續校驗資料正確性的系統。
即使出現 bug，也可以線上下模擬執行時透過校驗能力發現風險及時完善。OceanBase 在生產環境中經歷過極端異常場景的長時間檢驗，每年雙十一大促都會有多臺伺服器發生各種型別的故障，OceanBase 總是能夠自動處理。業內某個非常大型的商業銀行的某次 PoC 測試專門模擬了網路時斷時續的極端異常場景，最終只有 OceanBase 透過了該項測試。
今天的資料庫，都有三個基本模組：
儲存模組、事務模組和 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年資料庫技術積累。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69909943/viewspace-2841619/，如需轉載，請註明出處，否則將追究法律責任。
