> **伴隨著雲端計算、大資料技術的發展，傳統資訊科技及應用受到了巨大沖擊，資料庫作為基礎軟體也迎來了新的挑戰和機遇。同樣資料使用場景呈現多元化趨勢，資料規模也隨之爆發式增長。海量異構資料的爆發式增長，對資料庫的儲存和計算能力提出了更高的要求。**

**未來，傳統的基於單物理伺服器節點的資料庫將在更多的場景下被分散式資料庫取代，分散式資料庫應用前景將越來越廣。**

**《對話ACE》第四期活動便圍繞“分散式資料庫未來發展的挑戰和機遇”為背景，邀請到極數雲舟創始人&CEO、Oracle ACE Director 周彥偉，OceanBase 產品和解決方案部高階總監王南共同探索“分散式資料庫未來發展”，以此推動分散式資料庫技術更好的發展。**

以下為對話實錄：
--------

### ?OceanBase產品和解決方案部高階總監 王南

### Q：OceanBase 完全自研的國產分散式資料庫，在設計之初，會有哪些難點？

對於 OceanBase 而言，並非從設計之初就考慮到要解決更長期階段的問題和難點。這其中有一個決策和立項的過程，包括能夠解決什麼問題，產生什麼樣的價值，需要多大的投入，需要多長的時間和代價才能解決這樣的問題。早期是基於場景和問題去逐步解決的，間接的分階段完成整個認知過程。

第一個階段源於淘寶的場景，解決的是核心資料規模和資料量，包括資料訪問的吞吐在不斷增長的情況下能夠應對業務增長。第一步解決的還是分散式的問題，是沒有關係模型的一個分散式的 NoSQL。隨著淘寶場景的問題解決後，更多的業務場景同樣存在擴充套件性的訴求。很多場景本就是基於關係型資料庫去做支撐的，對於資料庫的訴求，部分業務是可以透過應用層改造來解決，但大量的業務如果要走向通用場景的話，關係模型還是一個很必要的訴求。

第二個階段在解決分散式的問題後，逐漸完成關係模型，支援SQL能力。隨著 OceanBase 從螞蟻和支付寶內部開始走向通用市場，可以看到很多業務場景既有基於 MySQL 開源生態的，也有基於 Oracle 商業生態的，所以應用如何能夠遷移到新的分散式資料庫上來？其實有一個很大的問題。

第三個階段就是能做到很好的相容，對於使用者來講，在應用層包括遷移過程中的成本和代價是什麼樣的，OceanBase 在解決了 MySQL 相容性後又完成了 Oracle 的全面相容，包括語法、語義和儲存過程等等。

再之後會遇到關鍵問題和挑戰就是隨著資料量的增長達到一定規模後，對於 AP 的能力的訴求還是比較強的。HTAP 的能力在當前階段，是一個關鍵的難點和技術挑戰。同樣隨著雲端計算的發展，對於雲基礎設施甚至跨雲異構雲的支援，也會有很多客戶的訴求。

所以在設計之初包括髮展過程中的技術難點，其實是在支援和服務客戶的過程中逐步去發現的。

### Q  ：在銀行、保險等金融場景很多企業已經選擇分散式資料庫作為核心首選，那麼未來在哪些場景內還會存在類似的情況？

之前 OceanBase 在金融場景應用會更多一點，近兩年時間除了金融之外，我們已經在通用市場的很多企業裡面開始應用了。這個問題有比較多的影響因素，今天我主要從產品和技術這個視角來去探討和分享一下。

在目前已經大量應用的分散式資料庫的核心場景來看，他們選擇分佈資料庫。其實有幾大類的原因，大家都是基於幾大類的這種不同的訴求和考慮來去選擇的。

第一，有核心繫統遷移需求的使用者。這些使用者往往不是從業務訴求驅動，因為這種場景下，使用者選擇一個什麼樣的架構，是集中式還是分散式，不是特別強的一個強約束，而是更關心在 Oracle 的相容、切換和替代過程中，是否能夠高價效比的平滑遷移。

第二，解決連續性問題的使用者。對於資料庫的供應、購買、包括資料庫服務能力等面臨越來越多的這種挑戰，所以連續性可能也是重要原因之一。

第三，有真正業務訴求的使用者。因為選擇的本質最後還是要回到商業，或者回到市場，來選擇一個產品到底是不是經濟、划算、正確。從這個視角來看，無論是客戶業務量的迅速增長，然後導致的對於資料庫或者資料管理這一層擴容、擴充套件的訴求，還是因為資料量的過大，集中式的架構沒有辦法承擔未來業務訴求和資料量。這類使用者其實他的訴求是更剛需的，也是更迫切的，也是能夠觸動和驅動使用者真正下決心去做技術升級改造的很核心的因素。

這個過程裡面，使用者關心的關鍵因素除了資料庫自身能力，包括功能、效能、規格、安全這些能力是否滿足之外，還有一個比較大的因素就是應用遷移的成本和代價。資料庫作為基礎軟體和應用有很大的差異，替換時對於比較複雜的各種業務系統，影響和代價比較大。

所以說對於什麼場景會選擇分散式和什麼場景會選擇一個新資料庫，其實是兩個概念。對於選擇資料庫，大家更多地考慮資料的安全性和規格是不是能滿足。但是對於是否選擇分散式，這裡面需要有一些核心訴求的：要麼是原有的單一金融系統沒有辦法能夠滿足訴求；要麼是我為未來做一些技術上的升級和儲備。最終未來可能還會有哪些場景會選擇分佈資料庫，還是要回到真正這個市場選擇本身這個話題上來。

### Q  ：關於分散式資料庫產品的運維或者大規模智慧化運維，有什麼好建議？

其實一個產品，它的應用規模越大，其訴求、挑戰會更高。因為產品沒有被規模應用的時候，無論他怎麼去做，哪怕是人肉支撐，也能夠把運維很好的支撐起來。但是一旦放量之後，這個運維就是很大的挑戰，特別是資料庫產品，它和普通的應用有很大的差異，在執行時會影響到各種因素的影響。比如軟硬體故障，這也是為什麼有 DBA 這樣一個專業方向的群體來去專門做這個資料庫的運維。傳統資料庫經過幾十年的發展，已經形成比較成熟的 DBA 群體，除此外，分佈資料庫相對於集中資料庫來講，其實還是有不同的挑戰的。

首先是技術架構，它本身就帶來了更高的複雜度，相對於集中式資料庫來講，分散式對於高可用故障恢復以及執行計劃的各種調優，它會有更高的對於能力上的訴求。對於一個新的產品和架構，要去學習理解，再形成普遍的認知，還有使用它的熟練度，其實需要很長的過程。這個可能不是說針對某一個資料庫，而是因為分散式的架構和技術特點決定了會有這樣的一個過程，而且其實我們在運維的問題上面，也有幾個層面在實踐和探索。

第一個層面是產品能力。除了資料庫的核心之外，要真正把一個產品用起來需要考慮產品化配套相關的各種工具，整個叢集管理運維監控、全鏈路的診斷，還有自動的最佳化器、功能調優、自助運維，所以用工具去解決這個問題非常關鍵。當然這裡面肯定是需要 DBA 和人去培養這樣的能力，但是如果你有比較好的工具或者比較完整的工具能力做支撐，有比較好的技術去提供這種支撐和查詢，其實是很大的一個幫助。所以從產品能力上來講，我們要去構建這樣的一些能力支撐和底座。

第二個層面是整個使用者層面的認知，包括運維人員體系的培養。OceanBase 現在正在透過開源去培養一些使用者，我們也建議大家都用起來，知道資料庫有什麼特徵，會遇到什麼問題。更多人去用，在運維上更多人才會去理解它、用它。同時參加一些培訓認證，像OceanBase 現在的 OBCA/OBCP/OBCE，針對不同的人群，不同的特點去打造全認證體系，讓更多人能夠快速學習、使用和了解的這個分散式資料庫。這不單單針對 OceanBase，而是想要對於整個分散式資料庫的運維、調優去培養這樣一些人才基礎。

第三個層面是我們在市場化和交付的過程中，慢慢體會和理解到整個資料庫的運維問題。這點只靠我們自己遠遠不夠，像 Oracle 這麼成熟的一個產品和公司，它的運維也是靠大量的第三方專業服務公司以及 DBA 群體一起去搞定的。對於分散式資料庫來講，OceanBase 屬於一家創業公司，現在規模不大，後續一旦規模應用到更多行業和使用者場景，僅靠原廠去支援服務很難。所以對於資料庫運維，我認為要把第三方的各種專業服務公司、生態、包括 DBA 的能力都綜合利用起來。

除此外大家也會有一些探索。像資質能力、包括 AI 也是未來我們的一個探索框架。我認為在目前這個階段，剛剛提到的三個層面是我們重點要去發力和投入關注的。

### Q  ：國內很多新興的資料庫產品研發參考 Google Spanner的論文，您覺得國內與國外在分散式資料庫技術上，還有哪些差距？

之前在傳統的資料庫的架構下邊面臨著業務的一些挑戰，如資料規模的快速爆發、分析類的訴求，在這樣的場景下面，給大家帶來了很多不同的在技術上創新性的思考,這種思維上的突破和啟蒙有很大的意義。以Google 為例，它起源於自身的業務，因為 Google 本身就是全球化、跨地域，又有非常大的業務規模，它基於自己的業務場景訴求，在解決自身問題的過程中積累了一些技術方案和能力，然後進行了一些輸出。

再比如說 Spanner 這樣的架構，就是解決這類問題的一個方向，但效果很難說，起碼現在看來可能還遠遠沒有到很完善的階段，包括Google 自身資料庫的市場化或者商業化能力，也很難說是比較成功的，就像他提到的一些核心技術，True-Time API 和全球化的這種能力，是不是適用於所有場景，其實也不一定。

不同企業的訴求和場景有很大差異，不管是國內還是全球範圍內對分散式資料庫的推動，背後主要還是幾個雲大廠。因為雲大廠的特徵和Google 自身的業務特徵有一定的共同性，即足夠大的規模和資料的大集中，這樣的場景會對於分散式資料庫有一些核心訴求，但是它會帶著濃厚的廠商色彩，如何滿足多元化場景，有很重要的現實意義。

所以是不是要基於雲廠商或者聚焦網際網路大廠的資料集中化訴求，或者說 all in cloud 來做分散式資料庫？其實不然，比如說在國內，它會有更好的土壤來促進和發展多元化的場景支援，而不是大家都聚集到一條路上去做這種全球化，或者是公有云原生的解決方案。

綜合來說，我們相對於國外的技術差距沒有那麼大，因為不同的場景都需要去解決，我們有我們的優勢，在早期他可能也有他的一些優勢。只能說現在這個階段，從技術先進性和技術實力、能力上來講，我們有足夠的自信來面對任何的場景，包括現在國內的大規模挑戰和全球化訴求的挑戰，我們都有足夠強的自信心來解決這些問題。

### Q  ：在當前雲原生大趨勢下，分散式資料庫技術的發展還有哪些突破點？

當下的資料庫是百花齊放的狀態，我們的堅持就是我們要做一款對於使用者應用透明的分散式關聯式資料庫。這句話聽起來很簡單，但實際上裡面有幾個關鍵要素。

第一，我們要去做應用透明。不需要在應用層去感知解決問題，也不是中介軟體的方案，而是要在資料庫層解決問題。換句話來說，就是把複雜留給資料庫，把簡單留給使用者。

第二，嚴格的 ACID 保證。資料庫一定要保證資料的正確性。換句話來說，就是 OceanBase 一直堅持立足於 HTAP，不斷地支援和擴充套件我們的 AP 分析能力，而不是說我們在 AP 的基礎上來去支援嚴格的 OLTP，這個是我們在分散式這個方向上堅持的核心要素之一。

除了支援這兩個技術挑戰之外，我更想講的是另一個話題，分散式資料庫在走向市場化應用的過程中，最大的問題和挑戰還是摸清客戶到底遇到了什麼問題，需要解決哪些問題，除了分散式資料庫在技術上的競爭力和優勢之外，產商真正要從天上回到人間，讓大家都用起來，這裡也有幾個關鍵點。

第一，對於大規模的分散式事務，能夠支援和保證事務的一致性。在正常的狀態下，我相信很多人能解決，但是在出現故障或者各種軟硬體故障異常的情況下，去做好恢復，同時恢復過程能夠不影響業務，這個對於生產系統來說是一個巨大的挑戰。從使用者視角來講，非常關注的就是分散式技術體系能不能解決這個問題。

第二，是否能夠平滑遷移。當大量的應用從原來的系統遷移到分散式的時候，是否能夠有一個通用的方案。另外的現實情況是我們要解決大量不同的行業、場景，海量應用的遷移，也是很多大型使用者關注的一個要素。

第三，如果我們把這個範圍擴充套件或者泛化來看，其實不同的使用者場景或者說同一個使用者它的應用場景非常複雜。它可能會有不同的基礎設施（私有云、公有云、混合雲），而且大量的系統不是一次全部切換，這個風險的代價太高了，所以肯定是漸進式的。有這樣的一個場景的話，就會帶來大量的這種不同的基礎設施的支撐、異構部署的訴求，這個也需要資料庫層提供一致的能力體驗和能力支撐來保障。

最後，我想說的是 HTAP，就是 TP 和 AP 的能力是不是能夠融合起來，一開始，其實二者沒有分離這個概念，後來隨著資料量的增大和分析訴求的增強。原有的資料庫能力無法滿足，所以才分離出來。現在的架構也帶來很多問題，包括使用者需要在這個應用上，去構建不同的業務系統，來做日常生產的交易，以及這種角色的分析。

在應用複雜度上和客戶的投入成本上來說，還是迴歸到 IT 的本質，就是對於算力和儲存的資源消耗，它都是不經濟的。所以有一個方案能夠同時解決 TP 和 AP 的融合，且有很好的負載資源的隔離，讓他們互相不受影響，這是有巨大的現實和經濟意義的，這也是 OceanBase 下一步要去重點投入和發力的關鍵突破點。

### ?極數雲舟創始人 周彥偉

### Q：如何快速理解什麼才是真正的分散式資料庫？

這個問題如果比較簡潔的回答，可以分兩段。分別是什麼是分散式和什麼是資料庫。

首先資料庫是解決資料儲存與計算的問題。其次分散式就是用多種資源去解決大規模的資料的儲存及計算，把它從原來單臺伺服器的資源和計算分攤到多臺伺服器，這是分散式資料庫的字面意思，但是這樣的產品是否就是真正的分散式呢？我覺得也不盡然，它只能算作一個學術理論類產品，並沒有從實際需求場景來考慮。

分散式資料庫除了要解決計算能力和儲存能力的資源分攤的問題之外，還要看實際需求中對於資料庫的能力與訴求等等，另外分散式可以認為是對於各種不同資源的分攤。比如說，非對稱分散式。大多數時候，大家關注的是在對等條件下，然後用分散式叢集進行資料的儲存和計算的分攤，但是在一些產品需求當中，例如對於邊端邊緣計算是需要在遠端直接計算結果，再把這些結果和中心端關聯起來，對於這麼一個場景，顯然資源的配比是不對等的，但還是需要把分散式資料庫的技術從遠端到終端的資料結合起來，然後進行某種運算並得出結論，這算不算一種分散式資料庫呢？如果設計好的話，當然算是一種分散式，這是第一個例子。第二個例子就是不對等計算的分散式，就像經常看到的 HTAP 這種多樣的計算型別，資料會存放在不同的儲存，不同的環境中採用不同的結構，有不同的計算需求或者演算法，那麼要做一個分散式系統的話，要解決計算能力和分攤的問題，不同運算及演算法的分攤，如果把系統設計的很好的話，這同樣應該也納入到分散式資料庫的範疇。

### Q：分散式資料庫近些年還挺火的，但是海外的一些主流資料庫廠商（Oracle，IBM）並沒有大肆推廣，也有一些言論指出，由於亞洲人口多，數量大，所以分散式資料庫對國內而言更適合，這點您怎麼看？

過往像 IBM，Oracle，SQL Server 主推的核心產品還是單機版，分散式資料庫並沒有作為他們的主流來推廣或研發。另外一個角度來講，關於資料量的大小，我認為主要不是來自於人，而是來自於機器和裝置。

分散式資料庫和資料量之間沒有本質的聯絡，那麼為什麼主流廠商不去做這件事（分散式），這點我也有過一些思考。聚焦做分散式資料庫大致來說可以分成兩類，一類偏學術型別的理想主義團隊，從理論的角度去提出，然後去做分散式資料庫，希望對資料庫未來會產生一個什麼樣的結果或更好的產品。另一類並不太懂資料庫或者叫初生牛犢不怕虎，先規劃遠景藍圖，並知道結果，同時燒的也是別人的錢。

為什麼這麼說？就是資料庫首先解決的是資料絕對正確的問題，其次才要考慮各種效能和能力的支撐，但是分散式就意味著要在各種跨網路的資源上，保證各種計算或資料的一致性，這些才是資料庫的基本要保證的能力，那麼主流的資料庫廠商，基於商業和社會責任的需要，首先要充分保證資料儲存的正確性，同時也要考慮到效能，投入產出比，再其次才是考慮是否做分散式，換句話說，如果用單機部署或叢集能夠在一定程度上解決資料的計算、儲存能力分攤等問題，或者在資料庫核心不包含分散式計算架構就能解決問題的話，也能為資料的安全性和一致性保證獲取更好的收益，那這樣也許是主流資料庫不去做分散式資料庫的一個重要原因。

隨著硬體和網路以及分散式資料庫儲存能力的不斷髮展，資源能力的分攤對於分散式也分成幾種。從計算能力來看，可以基於 CPU/GPU 分攤，但是由於摩爾定理的限制,計算能力在單機上的提升會慢慢地逐步降低，但跨網路的物理硬體的分散式會逐步加強。網路已經出現了這種類似於 RDMA 之類的高速訪問。我不知道未來會不會出現跨 CPU/GPU之間硬體的融合，但目前從儲存上已經看到了一些。原來我們用 RAID 把多個儲存盤連起來形成一塊，這樣資料庫直接部署在做了 RAID 之後的單機上，這是一種儲存擴充套件形式；還可以基於智慧網路卡把儲存從硬體角度直接擴大成一個跨網路和跨機器的一個統一硬儲存的範疇。

也就是說分散式儲存可能從硬體角度去解決了，那麼你的資料庫還要不要去解決這個問題就需要慎重考慮一下了，因為資料庫的本質的還是要保證資料的儲存與計算，特別是資料儲存與計算的正確性。看起來上面說的 Oracle，IBM 等對分散式在軟體層面實現有惰性，可能有這麼一個考慮。

如果 CPU 和記憶體未來也能做成基於智慧網路、智慧交換機、跨主機的統一 CPU 和記憶體，將其都做成一個基於硬體的分散式。如果有這些資源的話，那麼只要關注儲存計算問題本身，就不一定需要考慮分散式。雖然現在還不成熟，但我已經看到有些科研在做了，未來可能還有這種產品出現。所以分散式我覺得還會去做，但我說的一樣，那種不對等、不同質化計算的需求，也許對於資料庫是一個新的挑戰。這就是我們實現的 Data Fabric 要解決的事情了，是跨環境維度，跨資料維度的廣義分散式系統。

這個爭論可能會再延續一段時間，軟硬體之間是相互迭代促進發展的，等硬體分散式做的足夠好了，再用軟體分散式說話，只不過範疇不同罷了。相信在不久的將來，會是廣義分散式一統天下的局面。

### Q：關於分散式資料庫有幾種形態（中介軟體、NewSQL、分散式架構+企業級核心、計算+儲存分離架構）？關於這幾種形態能否分析下他們優劣勢？

這是一個很基礎的話題，從我的角度來講，我們可以從分散式的幾個場景來分析優缺點。我個人認為分散式有三個層次，即使用者的互動、資料的計算、資料的儲存。我們可以從分散式發生的三個層次去看：

第一，路由層。當 SQL 寫進來，需要寫資料庫，如果做中介軟體的話，那是中介軟體的路由層要解決的事情，很早之前，我們做的分庫分表、中介軟體，甚至資料中臺，可能都有這麼一箇中介軟體的元件，用來解決這個 SQL 的分發、分攤、資料的快取計算以及重組，這是分散式發生在路由層的情況。

第二，計算層。如果說路由層是在隔靴搔癢，是最早期、最低端的形式，那麼在計算層的分散式就真正涉及到了資料庫的核心，它需要的技術能力、以及軟體的成熟的時間也會更長，這是一個體系。

第三，儲存層。剛才提到的共享儲存，或者是最早期的雲原生思想，比如那套基於AWS的理論體系，我認為它的難度介於路由層和計算層之間，但也是考量了各種安全性、效能平衡的結果。我們來分析一下這三種形態的特點。

路由層在以前，比方說十幾年前的人人網，淘寶等，以路由層為主要形式。最早期的開源中介軟體，也是由阿里開源出來的，這是一個最早的形式。到現在為止，還有一些商業化的中介軟體也是這樣的形式，但是我認為這種形式是早期技術發展過程中的一個產物，是為了解決當時的一些問題，但是又找不到更好的資源分攤的方法，然後做了一種以後端分庫分表，用中介軟體來協調，進而解決了這個資源分攤的問題。一旦我們的技術突破了當時遇到的技術壁壘的時候，這個方案很快就會被淘汰掉。因為中介軟體要解決各種資料的融合計算，要快取各種各樣的資料，要相容各種各樣的語法、以及資料的一致性，這些都是它的問題，並且有些問題根本解決不了，所以我們會陸續看到，基於這種架構的分散式到現在越來越少，或者慢慢的會被技術的大浪一點點給蓋過去。基於中介軟體的分散式是完全沒有未來的。

另外兩個主流應該是分散式領域的主要發展方向——分別是計算層的分散式與儲存層的分散式。在計算層執行分散式計算，底層可能是資料的分片儲存，這種形式可以說是一個分散式比較理想的形態，它很理想化的解決了各種資源分攤的問題。我覺得在這個層面上，OceanBase算是這種分散式的一個形態，這是它的優點，但它也有一些缺點，缺點在哪兒呢？其實我們可以考察一下資料庫對於資料的計算，因為剛才說解決的核心訴求是計算的正確性，資料的安全性以及計算的效率，其次是怎麼考慮資源分攤。

如果在把資源更好的分攤的情況下，為了保證資料的安全和效率，那麼我會犧牲一些東西。如果是做徹底的分散式事務，就意味著在某些極端效能上，應該不跟跟單機相比，就是不會高於單機。這是一個簡單的計算模型，比如MySQL會比分散式快，這是因為它簡單，所以它高效，可以做得更好。所以從這個角度而言，基於計算機硬體與計算形態的分佈，它可以達到一個比較理想狀態，但是它實現的複雜度會提升，大大提升了資料庫本身程式的複雜度以及資料庫成熟的難度，另外就是它對於一些資料的安全、計算效能可能都會有影響。

和上一個話題連起來，為什麼 Oracle 不會發展這樣的產品？為什麼 IBM 的 DB2 在這個產品都是以單一庫為主的，我認為真正做資料庫的人考慮的是絕對的資料安全和效能提升，以及在價效比之間擇優。

再說到儲存層分散式形態，這是一個現在看起來很理想，雖然不算是終極形態，但是是一個非常聰明的做法。也就是說如果我們要把資料庫能力分攤的話，那就要分成計算與儲存兩個方向，進而才有計算與儲存分離這樣的概念，因為他們確實可以拆開的。而且你要做真正的大規模資料支撐的話，就得首先實現計算儲存分離，只有實現計算儲存分離之後，才可以分別在儲存層和計算層分別考慮應該怎麼做。只有具備這樣的條件之後，我們才可以想，在儲存層做分散式儲存和原來單機一樣，我就不用考慮資料的安全性、即時性的問題了。

當然也不排除說我們要做更理想化的，更極端的產品。但是做技術研發要跟實際的需求結合起來，實際需求用得上我們就幹，反之產品很好，實際需求不大，它可能不排除作為一種科研產品持續存在，等待未來應用，但是從商業化角度來看，可能不只是追求技術完美，而是追求技術能不能覆蓋需求，保證高效、安全。我覺得這可能也是很多老牌資料庫廠商設計產品的思路。

另外，結合對未來硬體發展趨勢的預測，如果在硬體層面把分攤資源的問題解決了，那完全有理由不去自找麻煩，而是基於硬體的實現，把資料庫本職工作幹好。

對於分散式的幾種形態，我覺得很多應該超不出這三個層面。而且每個層面這樣來區分的話，每個層面的特點應該都比較鮮明、優缺點一目瞭然。所以說我們到底選型去部署、應用哪個產品，要根據實際的需求以及社會發展階段來去定義。

### Q：分散式資料庫的存算分離對於業務有哪些價值？

我對這個看法可能比較極端，所謂要做分散式資料庫，必須要做存算分離。存算分離是一種手段，它的目標是為了解決這個分散式的問題，只有存和算分開了才能在“存”的角度去考察分散式擴充套件、擴容，以及分散式的一些高用、副本之類的問題，以及在“算”的角度去考慮如何實現高彈性，提升資源使用率，按需所取，平行計算等問題。

對於儲存的是什麼內容我不用考慮，因為在做完存算分離之後，這部分對於使用者來講是透明的。另外還有對於整個系統的透明化、高可用的建設。對於一個傳統的資料庫架構，每一個節點都是帶著儲存和計算在一起的。你想要做個業務切換是很難的。在做了儲存與計算分離之後，幾乎可以做到一個 server-less 架構了，這樣對於切換的邏輯上是非常容易的，業務層完全無需考慮某個節點的切換情況。這一點對於業務的開發、運維、擴充套件都是非常有價值的，所以我的觀點比較極端——計算層和儲存層分離，分別做不同的分散式，才算一個真正的對於業務有價值的分散式。

### Q：分散式資料庫的學習與實踐，平時應注意哪些方面？

我覺得有兩點，第一，知其然，也要知其所以然；另外一點，實踐出真知。

知其然也要知其所以然，解釋一下就是如果是我們在用一套複雜系統的時候，系統做得越最佳化、越簡單，裡面隱藏的東西反而越多。因為所有個性化的東西都是做了包裝的，如果你一直停留在表面上去使用它的話，那你可能在它出問題的時候無法解決。

我舉個例子，我在去哪兒網的時候，比較瘋狂的推薦一個 MySQL 的元件叫 Galera。因為在一段時間之內，它用小而美的方式解決了多節點同步寫的問題，我覺得挺有價值，但這樣的產品，我也看到了很多人抱怨這個架構不好用、這個開源元件不好用、有什麼什麼的問題。但我線上上弄了幾百套都沒有問題，而且後來我還把它寫成書，放在了《MySQL 運維內參》裡。

為什麼會這樣呢？除了產品能力本身的問題之外，也要看使用者對它的理解，以及對它的掌握能力。如果你只是基於表面上去做一些事情，很難知其所以然地用好這個產品。所以我們在使用分散式資料庫這種極複雜、且經過封裝的情況下，還是要去了解本質。

第二，實踐出真知，強調的是要給自己犯錯的機會。也就是說只是紙上談兵沒有任何用，你要實際去做一兩年，如果有機會的話，也可以線上上環境去做。但是這個線上環境分幾種，需要選擇不會影響線上業務的。使用起來去了解資料庫產品的差異，它是動態的體系、是不斷運轉的過程，運轉之後，它或多或少的會出各種各樣的問題，只有帶著問題去爬，才能讓你瞭解的更深刻，才能讓你去讀原始碼的時候，該往哪讀，讓你對於產品或者系統本身有更深入的瞭解。

### Q&A

### Q：分散式資料庫對資料庫的可用性、完整性有沒有特別好的保障，能不能像 Oracle 那樣，被大量用於金融、運營商行業？

### 王南  
這個問題其實就是我們的理念和定位之一，我們的目標就是要去解決這個問題。簡單來說，OceanBase 就是要進入到這個企業核心場景裡面，然後把這種應用的帶來的各種訴求，包括功能、效能安全、資料的一致性、完整性、正確性的保障都在資料庫這一層去構建起來。

有很多用中介軟體的方案對於應用有依賴、約束，比如說跨節點的兩階段這種事物，在出現故障的時候，對於事物的一致性，包括回滾的殘留狀態沒有完整保障，需要在應用層做約束或處理，才能夠保證資料正確性，OceanBase 絕對不會將這種問題拋給使用者，而是在資料庫層面去解決。金融和運營商核心場景的關鍵技術就是對於資料的可靠性、安全性、正確性這裡的訴求，跟這種網際網路，這種場景，它的容納容忍度和成熟度是不一樣的。OceanBase 從資料庫的安裝部署、開發、運維、監控、故障的處理。

### Q：Arkcontrol 是否有計劃接入支援 OceanBase？

### 周彥偉  
Arkcontrol 是我們產品體系的一個元件，它存在的意義是兩個方向。

一是為了向使用者提供我們整個產品體系的一個管理層，他負責對於雲舟資料經緯平臺（DTArk）的運維，監控，資料備份等的管理。

二是為了滿足使用者的需求，建立在使用者需求之上，然後去解決使用者層面上多種資料庫的融合管理等問題。我的使用者可能除了自己的產品之外，在資料庫層面上還有MySQL、MongoDB、Oracle、Redis，我可以給他提供一個統一的平臺去做統一管理，它屬於一個便利化的工具，其核心意義是管理。

至於會不會去接受 OceanBase ，我想這需要回歸到市場，看使用者部署了什麼產品再去做決定，假設很多使用者的 IDC 裡面已經部署了很多 OceanBase產品的話，我們也希望為了方便使用者，去支援 OceanBase 的一些體系。我一直秉承一種觀點，就是要深入內部去做事情，而不是浮於表面與外圍。當然在支援的過程中希望 OceanBase 能給我們開放更多的介面，讓管理做得很好。

### Q：分散式資料庫的效能要求都很高，有沒有計劃說普通的 PC 或者是降低效能能夠跑起來的方案？

### 王南  
說實話，我們已經關注到，而且已經努力了一段時間。首先在公有云上，有大量這種中小客戶會有這樣的剛需，特別是對於小型客戶，他其實不太需要效能特別強勁的伺服器去解決當前的問題，或者說有很多這種開發者、個人使用者可能是想拿一個小的場景，甚至在自己的基礎上去測試或者使用一下。

這個問題我們現在有幾個方向在努力：首先是對於資源的消耗，接下來OceanBase會推出更低資源消耗的產品。目前應該是對於 8C 64G 這樣的記憶體訴求，在今年我們會把這個對於資源的開銷去降低到 4C，未來會推出 2C 甚至 1C。同時，為了更多的客戶可以更便捷的使用和體驗，對於單個節點的規格場景，我們現在也在做一些探索。

除此以外，公有云上可以考慮用多租去解決使用者的成本問題，因為大量的小的使用者如果都是獨佔這種方式，會帶來成本上的開銷。如果是對於非核心業務，客戶可以在資源上降低一些訴求，去得到經濟投入上的一些回報，這種多租比較好。我們現在在多租的核心能力已經具備，再去做儲存計算和記憶體的資源隔離能力，支付能力未來我們也會透過這個雲這種形態去釋出，讓使用者來快速體驗，對於這個問題我們再總結一下，就是對於這種小規格訴求，降低規格這種訴求已經在做，而且在今年我們就會看到很大的進步，未來 OceanBase 也會持續做這件事。

### Q：HTAP 中間狀態怎麼理解？

### 周彥偉  
理解可能有很多種，作為產品設計人員，要從一個更高遠的目標去考量。什麼叫高遠的目標呢？HTAP——TP 與 AP 融合的形態，這也是資料庫的兩種基本能力的結合。如果你去設計一款這樣的產品的話，那麼你這個狀態是不是終極狀態呢？顯然不是的，因為資料的計算除了 TP、AP 以外，還有邊緣的計算、檢索的計算，圖的計算等，由於這種計算需求的存在，才使我們的市面上有著形形色色的資料庫。HTAP 可能是把原來 TP 型的和後來以大資料為主的 AP 打通，是 1+1 的模式，那能不能合三為一、合四為一呢？產品的設計決定了產品的實現，如果你只考慮 HTAP 的二維中間狀態，實現出來的產品以後想再擴充套件的話，就非常困難。

所以在產品設計思路上，如果能夠解決多維計算的產品形態，那可能反過來再看 HTAP，它就是個中間狀態，是我們從一維到二維邁出的很重要的一步。但這一步不是一個終點，它只是個起點，未來我們還有很多事情要做。我們站在這個角度去看，如果我們設計產品的時候，設計一種框架能夠去支撐二維、三維乃至多維那最好，所以做技術的人反過來再做產品經理，可以從產品的需求和產品實現的角度同步考慮。如果你的眼光只盯著這個維度去做的話，那麼未來我們再去看更高的一個產品需求的時候，可能你現在寫的很多程式碼就要推翻重來。我們又不願意這麼做，只好考慮得更全面，做更大的框架，能夠去把這個二維實現，同時也能夠去相容未來多維的需求，這樣才是最理想的場景。

我們的 DTArk 就是基於這樣的思考，目前已經實現了 TP/AP/FP 的融合計算，估計很快還會支援圖計算，這種多維可擴充套件的架構跟直接去思考實現一個 HTAP 是完全不同的，換句話說，現在的 HTAP 產品要進而實現更多維度的融合的話，可能都要推翻重來，程式碼重新寫過。

### Q：有全球同服的分散式資料庫推薦嗎？覆蓋亞、美、歐洲的那種？

### 王南  
我相信提問的同學可能不是在說有沒有一個資料庫能夠適配這些區域，“全球同服”可能在問公共雲上是不是有這樣的一個資料庫能夠在全球的不同區域分別提供一致效能力去支撐這種全球化應用和資料上的部署訴求，現在確實還是比較有挑戰的。

這裡面還有一個隱含的訴求：同一個雲在全球的區域都能夠提供這樣的能力？還是有很多客戶不想被某家雲繫結的訴求。簡單去看，有沒有分散式資料庫或者雲服務能夠在全球提供服務，這個其實還是比較多，可能能力上會有一些差異，包括幾個大的雲廠商，其實在全球各個區域的雲上，都有包括 RDS，共享儲存服務、AP 的產品，如果是跨雲訴求不被一家雲繫結，特別是大型客戶。

如果只能在一個雲上去做應用的基礎設施，其實存在很多風險。包括技術、業務安全上、成本上的風險。對於跨雲這塊的訴求目前有很多人提出，但不是所有人都能夠解決，因為雲廠商能夠解決的還是基於基礎設施如何提供全球跨區域的服務。但是對於跨雲，可能還是要靠獨立的資料庫產品、廠商去解決這個問題。OceanBase 現在正在考慮、解決，大家會很快能夠看到我們有一些產品和服務。

### 周彥偉  
如果從純技術的角度來回答，肯定有，比如依託網路的分散式，在不考慮效能容忍度、時間成本的話，分散式全球快速部署沒有問題。換句話說，全球部署的瓶頸，我認為在於網路和許可權，只要跨越這兩點都可以。

在實際操作上，真正既要考慮跨中心、跨雲、跨全球化，又要考慮效能的結合，現在看起來其實有難度，因為網路一定有時效，光速很難突破。所以退而求其次，在分散式上可以只做共享儲存，或者說既做分散式，也做共享儲存，主要看業務對你的計時或者是效能容忍的程度。我們在實現 DTArk 這樣的 Data Fabric 產品的時候，也提出了一種創新技術——資料飛梭。很簡單，你要做這件事，可能不需要全量的資料做大規模的同步，可能只需要某一批資料，然後傳來傳去，無需做成全世界的一致同步，浪費很多時間去等網路，而是可以在某些資料或業務、計算場景中做不同維度的資料跨域或者跨區間。此刻要考慮得就不是即時同步了，而是最終的一致性；不是即時計算，而是根據時間配置的時間視窗的計算。我覺得關鍵點還是在於網路的問題，就是網路延時是影響所有需求的本質問題。

對話ACE第四期：分散式資料庫未來發展的挑戰和機遇

相關文章