歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/
3 月 25 日，第一屆 OceanBase 開發者大會在北京舉行，《明說三人行》訪談欄目創始人兼主持人盧東明、沃趣科技創始人兼 CEO 陳棟、DBAplus 社群聯合創始人楊建榮、PostgreSQL 中文社群主席 張文升、OceanBase CTO 楊傳輝在主論壇進行了 《資料庫領域，有哪些最值得開發者和使用者關注的創新與技術》 的圓桌討論，共同探討了單機分散式一體化、HTAP、多雲原生等眾多關於分散式資料庫的熱門話題。
以下為圓桌實錄：
單機分散式一體化是未來趨勢
盧東明：請用一句話、三個標籤來介紹一下自己和所做的事情？
楊傳輝： 工程師/開發者；單機分佈一體化；價效比。
陳棟： DBA；創業；一體化。我們從資料庫、軟體、硬體，即整個系統一體化的方式給客戶提供開箱即用的解決方案。
楊建榮： DBA；技術社群；技術分享。
張文升： PostgreSQL；開源社群；佈道師。我最重要的標籤就是 PostgreSQL，我認為哪裡有 PostgreSQL，哪裡就有我。
從左到右依次為科技訪談欄目《明說三人行》創始人兼主持人盧東明，OceanBase CTO楊傳輝，沃趣科技CEO陳棟，dbaplus社群聯合創始人楊建榮，PostgreSQL中文社群主席張文升
盧東明：針對 OceanBase 最新提到的“單機分散式一體化”一詞，在大眾印象裡“單機”與“分散式”是割裂分開，為什麼 OceanBase 會將他們組合起來？
楊傳輝： 我很喜歡“單機分散式一體化”這個詞。其實最早在 2021 年年底，它叫集中式分散式一體化。但後面我們覺得不是特別直觀，所以改成了“單機分散式一體化”。
確實，很多人腦海裡覺得“單機就是單機，分散式就是分散式；主流就是單機，大規模就是分散式。 ”而單機分散式把兩類系統的產品特性以及技術優勢融入到一個系統裡面，對使用者來講很方便，使用者不需要做選擇。正如主持人所說，我們是成年人的資料庫，這個比喻我很喜歡。
但這裡有一個難點，有什麼樣的技術手段能夠達到這樣的效果。第一，當從單機到多機之後，功能不能損失，對使用者來講，它基本看起來沒區別，但是僅僅功能不損失也沒有用，如果效能一下子降下來的話，意味著一體化不成立。前面我在分享裡面也講了很多 NewSQL 的案例，一到分散式單機效能掉到原來的 1/5、1/10，這個沒有辦法既要也要。
OceanBase 能夠做到效能也不損失，並且保證功能和擴充套件性核心的原因，在於我們做到了分散式資料庫裡面的每臺機器沒有分散式相關的 overhead，動態的單日誌流技術，是動態繫結的模式。一開始每臺機器只有一個日誌流，資料動態繫結到這臺機器的單日誌流，可以做到單機效能不損失，這是我們講的核心概念，同時我又能做到功能完全無縫相容，效能沒有損失，這就是“成年人的資料庫”。
張文升： 根據過往的經驗，如果把分散式系統當作單機系統去用，比如部署到一個機器上，它的效能會有大幅度的降低。這個問題如何解決？或者怎麼突破這個瓶頸？
楊傳輝： 早期的支付寶，有很多 Oracle 的 DBA，他們表示：當 Oracle 開啟強同步時，效能降低 35%，這個資料是以前支付寶的 Oracle 的 DBA 測試出來的。而為什麼分散式應用到單機會出現效能損失？因為分散式要做高可用、強同步的容災開銷。分散式做可擴充套件，因為擴充套件性帶來的開銷、強同步帶來的開銷，採取非同步寫 Redo Log 的模式，使得 OceanBase 強同步的方案效能損失控制在 8% 以內，其它地方做一些最佳化，同時具備強同步，並且不損失效能，這在以前的單機資料庫基本做不到，因為底層的架構發生了變化。
採用單機分散式一體化的可擴充套件方案後，每臺機器只有一個日誌流，儘管後臺需要佔用一些網路、CPU 等，但對前臺的交易和 TP 效能沒有影響。
楊建榮：對 DBA 來說，從單機到分散式一體化這種層面來說，涉及到哪些操作上有什麼變化？對整個系統有什麼樣的影響？
楊傳輝： 我們很多開發者、DBA 等之所以提單機分散式一體化的概念，是因為在單機分散式一體化理念下，首先要求對開發者、對 DBA 是透明的，擴容操作由資料庫後臺實現，對以前的業務及應用協議沒有影響。雖然資料庫擴容了，但可以透過動態路由來自動找到機器原始資料。 因為底層架構是分散式，所以擴容後是全部支援上層功能的。 而原來單機的產品無法做一體化的原因是原來的 SQL 引擎是為單機設計的，換成多機的話很多功能支援不了。
陳棟： 我非常認同 OceanBase 對單機場景的關注。從我接觸的使用者需求來分析，單機場景更為大眾化。因為對於大部分的企業使用者而言，可能單機已經足夠業務所需。如果一上來就用分散式系統，那麼門檻相對較高， 在“軟硬一體化”趨勢下，硬體發展核數越來越多，可擴充套件性的記憶體、吞吐足夠大，結合硬體能力，再加上資料庫在單機上效能開銷的最佳化，未來在大眾化場景的適用面、接受度將更強。 因此我認為，OceanBase 往單機的思路上走是特別棒的。
陳棟：那麼在單機分散式一體化概念下，OceanBase 是更注重單機還是更注重單機到分散式的擴充套件性？
楊傳輝： 我們原來就是做分散式資料庫，已經把分散式架構都搭好了，每個開發者一開始想到分散式資料庫，肯定認為這個東西使用門檻比較高，我們想要做的一體化架構其實就是降低分散式資料庫的門檻，所以如果回答剛才的問題，我認為是第二種， OceanBase 更多還是考慮從單機怎麼擴充套件到分散式的擴充套件使用場景。
一個企業像它的發展旅程一樣從小到大，今天是單機，明天乃至未來可能會去擴充套件。當有了單機分散式架構之後，在需要去擴充套件的時候，無需把資料庫打包重來（應用重新寫一遍），我們只需要一開始就選擇像 OceanBase 這樣的單機分散式一體化架構就好，這是我們最早的初衷。我也認為這種架構以後的應用場景會越來越廣，成本降低的同時，做到了單機效能和分散式效能相當，與此同時又有一個額外的面向未來的能力。
陳棟：把方便留給使用者，把麻煩留給自己，這個思路是使用者思路，但從單機到分散式的過程是一個重大操作，不是一個高頻交易，但從資料庫的設計角度來說，這個投入是非常大的，你怎麼看這個投入回報？
楊傳輝： ROI 是 OceanBase 做單機分散式一體化架構設計裡非常重要的考慮因素。成年人的資料庫，沒有太多需要選擇的地方，OceanBase 一開始就是分散式架構，由高往低走去做最佳化，本來就是我們要去做的事情。但如果原來是單機資料庫，要變成分散式就需要增加一個數量級的複雜度，這個方式基本是不可能的， 一個小的場景投入更高數量級的複雜度，沒有任何人會做這樣的選擇。 比如特斯拉一開始是 Model X、Model S，後來 Model 3，從高到低這是不可能的。
分散式技術做起來的複雜度太高了，OceanBase 做了 13 年，但仍然還是有好多的使用者體驗需要不斷最佳化。
張文升：假設我是一個後端開發團隊現在要使用 OceanBase，在做資料庫規劃的時候，剛開始業務很小採用單機模式，等到業務發展到一定階段，我會把單機模式調整到分散式，這個調整過程如果照以往使用過的產品，有可能我得去換很多驅動和更改配置等，這中間會對業務造成很大影響， OceanBase 是否有更簡潔、更方便的切換方式？
楊傳輝： 關於這個問題有兩個方面：假設我使用資料庫不追求極致效能，驅動、應用都不需要改；假設要追求極致，理論上如果後端發生變化，有可能有一些調優空間。如果不做極限調優是一樣的，因為後面有更多的伺服器，連線是不是改大一點，或者原來沒有寫自適應的連線這樣的東西，可能需要做一些簡單的配置，如果不追求極致，沒有關係的。
一項技術它能解決很多問題，但是不會有一項技術把以前開發遇到的所有問題全部解決掉，當你想達到極致時仍然需要我們的 DBA，需要開發者對更高深的資料庫知識的掌握，才能將技術發揮得更好。
資料庫發展離不開場景需求
盧東明：OceanBase 已經在分散式資料庫的路上做了 13 年，但從分散式做回到單機，居然比傳統的單機資料庫 MySQL 效能做得好，這個能否解釋一下？
楊傳輝：當分散式往單機做的時候，首先要避免沒有分散式的額外開銷，得站在一個水平線上跟它比；接下來是在同一個水平線上，如何做得更好，這裡很多時候就是大家怎麼做 CPU、單機效能最佳化的問題。
第一，OceanBase 的儲存引擎相比 MySQL 有兩個比較好的點，MySQL 是 B+ 樹的儲存引擎，而 OceanBase 的儲存引擎是 LSM-Tree 引擎，並結合了 B+ 樹，可以說是站在 Oracle 和 MySQL 的基礎之上全新設計的引擎。這樣一來，儲存成本會比較低，甚至能在 OLTP 業務裡面做線上壓縮，以前的單機資料庫基本很少開啟線上壓縮，因為一開啟，效能就會下來。
第二，我可以把大部分最高頻的操作（LSM-Tree）全部在記憶體裡面進行，在 B+ 樹裡做資料分塊，使得我能將降低寫入放大的技術融合在一起，最終才能在引擎層面改變，增效降本，所以 OceanBase 的儲存引擎是 B+ 樹結合 LSM-Tree 發展起來的東西。
盧東明：有沒有跟 Oracle 去做對比？
楊傳輝：對於簡單的讀寫，MySQL 和 Oracle 在一個水平上，但在測 Sysbench 上，OceanBase 還是有優勢。Oracle 有些地方比 MySQL 做得更好，比如多核擴充套件能力，這部分 OceanBase 也做得不錯，兩者在可擴充套件性上，處於同一個水平。
另一方面，Oracle 在複雜查詢上做得非常好，坦率來講，雖然今天 OceanBase 的多核擴充套件能力、簡單的讀寫已經可以比肩 Oracle，有些地方甚至更好，但在複雜查詢上我們比 Oracle 有劣勢，在今年的 Q3，我們將花很大的精力最佳化複雜查詢的效能。在當下的開發者和 DBA 中，寫真正的複雜查詢的人少之又少，簡單查詢可以覆蓋大多數場景，但也不可避免很多需要進行復雜查詢的場景。
在中國的一些行業應用場景下，比如運營商場景，往往復雜查詢和高併發兼備，很多傳統集中式資料庫裡的複雜查詢的打磨，靠的就是中國的運營商場景，所以資料庫要做好，很多時候都要靠應用的打磨，靠應用驅動技術創新。 所以在原理上，OceanBase 跟單機資料庫在同一個水平上，在第一類最常見的場景上我們已經最佳化到較高的水平，但在其它更廣泛的場景下我們還需要時間，根據具體的業務需求來打磨最佳化，再過幾年，我們就能更有自信地說在很多場景都可以做的很好。
張文升：OceanBase 曾說站在巨人的肩膀上尊重經典架構，在新的產品 Roadmap 中也提到未來在 HTAP 概念上會往這個方向去走，如何讓多表、大表關聯查詢的最佳化器做得更好，這個是不是接下來非常挑戰的一件事？
楊傳輝： 大表查詢有兩個方面，一是像 Oracle 只在一臺機器上進行大表查詢，二是在多臺機器上的大表查詢，後者更麻煩。雖然 OceanBase 提了一些概念，比如單機分散式一體化、HTAP，但我們做 OceanBase 十幾年，想做的東西從來沒有變過。陽老師曾提了一個更簡單的說法—— 可擴充套件的 Oracle，一句話就把所有的今天我們講的單機分散式一體化、HTAP 都涵蓋進來了。
事實上，Oracle 在單機層面，就將簡單查詢、複雜查詢的問題都解決掉了，唯一沒做好的就是擴充套件性，以及成本還有可最佳化的空間。我們在它的基礎之上，把擴充套件性做好，原來的單機變成一體化，這個就是我們的理念。雖然我們在有些方面已經超過了 Oracle，但還有很多可以進步的空間。
OceanBase 的應用場景中，比如“雙 11”的高併發場景肯定比 Oracle 做得好，但 Oracle 在全球應用場景的豐富度以及一些比較少見場景的解決方案，是其它資料庫都達不到的。我們說可擴充套件的 Oracle，它的核心是分散式、可擴充套件，有點像是降維的意思。比如像特斯拉做了電動車，電動車裡面的電池就有點像分散式的技術。我們有了新的分散式引擎，能去做特斯拉的產品，但怎麼讓這個坐艙更好用、更好看、流線型等等，我們還是可以借鑑一些原來的做法。
盧東明： 真正能夠顛覆某 Oracle 的一定不是一個更好的 Oracle，很可能是一個更好的 OceanBase。按照 Oracle 的路徑去最佳化，試圖去超越它，這點是很難的，而 OceanBase 正在跳出它的框框，這值得我們期待。
做開發者喜歡的資料庫
盧東明：你認為開發者喜歡什麼樣的資料庫？
張文升： 我就說一個開發者可能會很喜歡的，功能夠用、簡單好用。
楊建榮： 我補充一點，社群前段時間做了一個調研，開發者對於整個分散式資料庫的需求，整合以後我們提煉出“4+1”模型。大家其實對於分散式資料庫的選型有四個點比較看重。一是切入點，開發者比較關注可擴充套件性，但是對於整個分散式資料庫的選型中第一看中的就是穩定性。
另外就是對於整體成本這塊也是比較看重的。不光是有硬體成本，還有對於整個研發接入使用成本。第三，對產品的功能還有易用性比較關注，儘可能跟主流的技術棧能做一個相容。第四，OceanBase 相對有優勢，對 SQL 的協議，很多公司有Oracle、MySQL 多種技術棧，如果有這樣一種協議的相容，對它的研發接入更簡單。
張文升：從我們接觸的客戶來說現在有一種趨勢，由於業務越來越複雜，客戶會傾向於不同的業務場景，在這個細分的業務場景下有沒有更好的資料庫功能或者資料庫解決方方面面所有的場景需求問題，比如像圖、時序、向量、多模態，在這方面 OceanBase 有什麼規劃嗎？
楊傳輝： 今天 OceanBase 的 HTAP 暫時還不能把離線分析 100% 解決掉。我比較認同周傲英教授講的觀點： 從“One size fits a bunch”做起，做得好再演進到“One Suite fits all”。 比如 HTAP 可能會設定 OLTP 加線上分析，但是如果在“圖”的場景下就不一定完全適合，也許可以基於 HTAP 做一些 key value、多模，但太遠的模型也做不了。當系統做得特別好的時候可能是一個套件，裡面有多個引擎共享的產品，HTAP、離線 AP 等等，此時借用分散式、高可用的能力一次性解決了所有的需求，從而避免了額外的研發投入。
陳棟： 您這邊是站在資料庫的視角，從我們的視角來看，為了解決客戶選型的問題，我們做資料庫的PaaS平臺，十幾種資料庫在這上面進行全生命週期管理，這也是一種方式。
楊傳輝： 是的，這個方式也非常好。技術包括產品一定是有很多不同的模式，只要能滿足使用者需求，理論上都是合理的，而且會共存。
盧東明：資料平臺這個概念提了好久，那麼各種各樣的資料庫或者技術怎麼樣有機地融合到一個平臺上？
陳棟： 從這個角度來講我們也是一個開發者，希望資料庫可以更加開放，可以包羅更多的 API、更好的文件，更友好，讓類似我們這種生態公司可以使用資料庫把客戶服務好。
楊傳輝： 資料庫的發展很多時候不只是廠商，而是 廠商+生態+開發者+使用者+應用 的場景。
盧東明：大家都知道開發者也好，DBA 也好，比較頭疼的是資料庫底層出故障，從開發者角度來看，別讓我去懂那麼多 DBA 的事，只要結果穩定、順心，這個也是我們所說的“成年人的資料庫”的一個需求，那麼你如何看待這種趨勢？
楊傳輝： 成年人的資料庫正在往多雲的方向發展，把一些複雜管控的工作交給後臺。多雲、混合雲未來肯定是一個趨勢，我非常看好多雲原生。
陳棟： 除了多模還有多雲部署的問題，客戶面臨的是多種資料庫和多雲的乘法複雜關係。相對傳統的單機非常簡單，現在又有分散式又有各種場景，非常複雜。我們作為平臺的開發者視角來說，希望資料庫更加友好，同時我們也想基於雲原生技術框架可以跟更多的雲廠商去做很好的適配，來幫助資料庫來解決多雲部署問題。
楊建榮：從研發的視角來看有一種困擾——事務，對於 SQL 來說，事務是很核心的點，事務對於研發有一種困擾，基於中介軟體的分散式叢集或者說一些 NewSQL，基於分片，業務又有可能多分片的需求，OceanBase 是單機分散式一體化的實現方式，在事務這塊的支援上和單機上是完全相容透明的模式嗎？
楊傳輝： 單機分散式一體化那個話題，剛才說的應用透明，不僅潛在路由、SQL 語句、語法是透明的，後面的事務處理也是透明的。當事務涉及到所有資料都在一臺機器上的時候，可以想象為一個單機資料庫的事務，當涉及到多臺機器時就走分散式事務的邏輯，有兩階段提交的操作，這是為什麼那另外 20% 有效能下降的原因，因為涉及到了遠端網路。
什麼才是真正的HTAP
盧東明：HTAP 是現在挺熱的一個詞，中國有將近 260 個資料庫品牌，叫各種各樣標籤的都有，HTAP 標籤的資料庫也很多，從 OceanBase 的角度來講，我們提的 HTAP 和廣泛意義上大家提的 HTAP 是不是一個概念？
楊傳輝： 今天我們說的 HTAP 甚至包括 OLAP 這個詞都沒有明確的定義。
我會把 HTAP 分成三類：第一類走極端的並集路線，TP 也行，AP 也行。第二類做交集，產品本身 TP 能力和 AP 能力單獨去看都比較弱，交集在一起時能做一開始沒有覆蓋到的一些場景。第三類就是 OceanBase，一種自然衍生的思路，有點像 OLTP+線上分析的能力，即 OLTP 加上 TP 與 AP 的交集，前者是應用系統核心，如果連應用的核心能力都沒有的話，這種 HTAP 不是真正的 HTAP。
盧東明：用 TP 強補足 AP 能力，或 AP 強補足 TP 能力，這兩種思路是合理的路徑嗎？
楊傳輝： 只有從 TP 開始才有可能成功，因為 TP 的門檻很高，且會涉及到核心場景，如果核心場景做好了的話，往 AP 是自然延伸，相當於由高打低；如果 AP 做好了，本身 AP 的重要程度、核心程度遠遠低於 TP，別人不會因為選了 AP 而選TP，但是別人可能因為選了 Oracle 的 TP 也選 Oracle 的 AP，這是一個自高往低的商業邏輯。
陳棟： Oracle 也是這樣的思路，把 TP 做到極致後再兼顧 AP 的能力，離線的也能處理一些，但不是特別專長的地方。OceanBase非常巧妙，從多副本里拿出一個副本，做列存，既省節空間，又做到資料的一致性，不需要單獨設計一個表格，這個還是挺期待的。
楊建榮： 我們現在有很多探索型的業務，它的模型會變化很快，整個邏輯相對複雜，如果像 OceanBase 這樣的分散式資料庫能夠原生地去支援，這種業務模型經過探索之後相對會固化下來，再演變成為 TP 的業務，可能是一個更無縫的方式。
楊傳輝： OceanBase 的探索性業務有幾個方面。第一，單機分散式一體化，擴充套件對使用者來說是透明的；第二，OceanBase 的 DDL 操作，我們會支援 Json、多模資料，DDL 線上操作無感知，對業務沒有影響。透過這樣的模式可以比較好得解決一些探索型業務的問題。
楊建榮：Oracle 在我們們認知裡面就是 HTAP 資料庫，但是在列存的方向上其實 Oracle 有一個 In-Memory 特性，NewSQL 體系中則是空間換時間的實現方式。OceanBase 在這方面能不能展開說一下？
楊傳輝： Oracle 走的是 In-Memory 的模式，OceanBase 走的是真正的列存路線。Oracle 之所以選擇這條路線是因為以前的技術債務太大了，儘管列存是更先進的方案，包括 Sybase 也是列存，Oracle 在那麼大的技術棧裡面只能選擇 In-Memory 的模式，從技術的角度有點像打補丁。而 OceanBase 相對來講沒有 Oracle 那麼重的技術債務，我們可以直接用最優的方式來做，目前，列存已經被業界證明，所以做 AP 肯定要做列存。
寫在最後
最後關於 OceanBase 的發展，我來做一個總結：非常感謝包括今天到現場的以及在網上參加直播的 OceanBase 開發者，這是 OceanBase 第一次面向開發者的大會，其實挺不容易，不管從籌備、組織，安排話題，我們花費了大量的精力，我們確實想把開發者大會辦好，想把我們的開發者社群做好。
對於 OceanBase 的產品而言，雖然我們今天說到全新的單機分散式一體化架構，但 OceanBase 有很多東西是不變的。
首先，對於穩定可靠的堅持，這個是 OceanBase 永遠不變的。第二，對效能、功能、對核心打磨的堅持。我們知道，僅僅把分散式資料庫底層的東西做好，就需要很長的一段時間。
今天，我們在一起做面向開發者的探討，當然也有一些希望去變的東西——那就是使用者體驗。
OceanBase 在 4.1 版本里，做了包括 OCP Express 輕量版開箱即用的工具、文件的重構、快速的安裝部署，大家只要去 OceanBase 官網或者去 Github 社群都可以看到，OceanBase 正在發生很大的變化，也相信每位開發者會對 OceanBase 的變與不變，會有更深刻的感受！感謝各位開發者一直支援 OceanBase，因為你們的支援，我們才能做得越來越好！
歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/