### 導語

隨著資訊科技的迅猛發展，各行各業產生的資料量呈爆炸式增長，傳統集中式資料庫的侷限性在面對大規模資料處理中逐漸顯露，分散式資料庫應運而生。

分散式資料庫是在集中式資料庫的基礎上發展起來的，是分散式系統與傳統資料庫技術結合的產物，能夠突破傳統資料庫的瓶頸，具有透明性、資料冗餘性、易於擴充套件性等特點，還具備高可靠、高可用、低成本等優勢。

分散式資料庫目前已應用到金融、電信等大資料行業，未來將走向更廣闊的領域。上月，InfoQ 與 OceanBase 合辦的“資料庫 Talk Show”圓桌直播邀請到了**國家工業安全發展研究中心軟體所副所長李衛，OceanBase 產品和解決方案部高階總監王南，dbaplus 社群聯合發起人、OracleACE、競技世界資深 DBA 楊建榮，攜程資料庫總監劉博**四位專家，圍繞分散式資料庫技術路線和產業現狀，分析分散式資料庫的技術特點以及面臨的問題與挑戰，對企業如何進行資料庫選型以及行業熱議的十個問題展開了精彩的互動討論，以下為互動的 10 個問題。

1. 我國分散式資料庫的產業現狀如何？

2. 分散式資料庫最核心解決的問題是什麼？

3. 使用者如何判斷哪種技術路線更適合自己？

4. 為什麼近些年分散式資料庫逐漸成為主流商業資料庫的選擇？

5. 分散式資料庫有哪些安全方案可以聊聊？

6. 在國內，HTAP 被很多人提及，海外更多是 OLTP 或 OLAP，那麼真正的 HTAP 到底是怎樣的？

7. Hadoop 等於 HDFS 和 MapReduce，分散式資料庫裡邊的 MapReduce 可能是什麼樣子？

8. 分散式資料庫的學習門檻如何？

9. 分散式資料庫選型可以從哪幾個方面進行考慮？

10. 分散式資料庫的遷移過程中應該注意哪些問題？

------

## 我國分散式資料庫的產業現狀如何？

▍李衛：最近幾年，分散式資料庫在國內發展較快。一方面，豐富的資料庫應用場景，新一代資訊科技與實體經濟的深度融合，各行各業的數字化轉型，社會全面進入數字經濟時代，這些變化都給資料處理和儲存的主要核心技術帶來了非常好的發展機遇，尤其是隨著資料規模的增加，資料使用複雜程度的提升，原有的集中式資料庫已經漸漸不能滿足現在很多場景的需要，分散式資料庫成為很多企業必然的選擇。另一方面，分散式資料庫因為發展時間不是很長，落地實踐層面還存在不足。

目前來說，國內主要有三種技術路線可供選擇：**一是分散式中介軟體 + 單機資料庫，透過在單機資料庫系統上進行改造，主要解決了擴充套件性的問題；二是構建分散式共享儲存實現擴充套件，採用非對稱計算節點，大部分公有云資料庫是這條路線；三是原生分散式資料庫，從底層設計就採用分散式架構，是未來很重要的趨勢。**

當下，國內從事分散式資料庫的廠商非常多，這三種技術路線各自存在應用場景，未來隨著應用更廣泛的深入和推廣，路線還會進一步收斂，肯定會向著第三種路線推進。整體來說，國內的環境和技術需求還是給分散式資料庫帶來了非常好的機會，甚至未來在分散式資料庫領域，國內在世界上處於引領地位。

▍**楊建榮：**早期，分散式資料庫對業務的侵入性比較高，可能需要將一個業務拆分成多個業務模式，而後逐步演進到相對一體化的模式，出現了分散式中介軟體這種架構模式，如今又出現了越來越多的原生分散式資料庫，技術體系上發生了很大變化，也面臨著更多技術挑戰，包括技術生態構建以及技術體系迭代層面。

▍王南：如果從資料庫廠商和使用者，也就是供給端和消費端的角度來講，分散式資料庫的發展兩端並不同步。從資料庫廠商的角度來說，分散式資料庫已經走了很長時間，但使用者對分散式資料庫的認知、接受、使用及運維是有滯後的，當然這是一項技術或者產品發展的正常過程。隨著數字經濟的飛速發展，使用者對分散式的訴求將越來越強烈，資料庫廠商還需要在產品成熟化、產品能力、技術體系的完整易用以及生態建設層面花費更多時間。

▍**劉博：**技術的發展最終還是業務驅動的。以攜程為例，如今的資料量與 2003 年剛上市時相比增長了上百倍甚至上千倍。攜程 2018 年就開始嘗試分散式資料庫，發展路線也從最初的非核心業務逐漸過渡到核心業務。在過渡到核心業務時，我們也做了一些備份手段，比如資料雙寫等。根據 2019 年的資料統計，國內創業的資料庫廠商有 160 多家，資料庫產品可能有兩百多個，其中分散式產品大概佔 40%，處於野蠻生長的階段。但根據 IDC 的調查，目前真正在核心繫統中部署分散式資料庫的比例不是太高。

## 分散式資料庫核心要解決什麼？

▍**李衛：**第一，分散式資料庫解決了傳統集中式單機資料庫時期的問題，單機資料庫面對海量資料在處理能力、儲存能力、效能等方面都存在瓶頸；第二，分散式資料庫需要解決資料一致性的問題，資料跨的節點越多，風險就越高；第三，分散式資料庫的高可用能力保證不會因為單點故障而影響整體的可用性，這保障了金融、電信等對高可用需求較高業務的連續性；第四，應用存在波峰波谷，分散式資料庫透過靈活擴充套件的設計做到了成本最佳化。

▍**楊建榮：**隨著網際網路場景快速增長的資料量，我們需要資料庫系統支援水平擴充套件，這種支援可能是兩個方面：資料儲存和資料計算。在這個層面上來說，更多的是讓資料儲存實現水平擴充套件。實現此的前提則是保證整個分散式資料庫的效能、可靠性等有更好的表現。從我實際接觸的場景來看，更側重於解決水平擴充套件的問題，讓擴充套件方式更優雅。

▍**王南：**首先，分散式資料庫的本質還是資料庫，所以也會具備傳統資料庫的關鍵特徵；其次，分散式資料庫需要解決的核心問題之一是擴充套件，解決研發團隊按需擴容、不需要按照業務波峰額外準備硬體資源的問題；然後是高可用問題，集中式資料庫的系統可用性很大程度構建在可靠硬體的基礎上，分散式架構將高可用問題轉變為軟體解決；最後在上述問題基礎上，如何低成本地將現有應用平滑遷移至分散式資料庫，整個過程需要一些方法論。

相較於其他原生分散式資料庫，OceanBase 立足於 TP 領域，不斷強化 AP 能力，去走向更全面的場景，這是一個關鍵的立足點，也是我們堅持的設計理念，儘量把複雜性從使用者側向資料庫側轉移，對外呈現的是 OceanBase 對使用者的應用相容，包括語法、語義以及儲存過程等高階能力的相容，讓使用者快速、透明遷移到 OceanBase 。

▍**劉博：**從定義來看，分散式資料庫首要解決區域間資料的一致性，對映到網際網路行業主要是如下兩點：

**一是分散式資料庫內建 HA 功能。**以攜程為例，過去主要採用商業資料庫結合儲存的模式，靠高階硬體解決 HA 問題，後來這套架構逐漸在主流網際網路公司中消失，取而代之的是一些 MySQL 的高可用方案，但這與分散式原生資料庫提供的能力差別很大，切換時的中斷是業務可以感知到的，分散式資料庫本身就可以提供多機房或者異地機房等部署方式，提升了高可用性及資料安全性，切換過程可以做到業務無感知，攜程已經將 OceanBase 部署在了生產環境，採用了同城三機房的部署方式，可以抵禦同城單機房的故障，且三個機房對等，業務可就近訪問，故障時的切換不再需要人工參與，免去了複雜的切換邏輯和人工操作流程。

**二是橫向擴充套件問題。**雖然攜程的業務峰值可能不如幾大主流電商平臺大促期間那麼高，但也是存在明顯的波峰波谷，例如暑假和春運火車票搶票。類似 K8s 這樣的技術已經很好地彌補了應用的彈性訴求，但資料庫層面的彈性一直是欠缺的，分散式資料庫提供的動態伸縮功能，解決了資料庫層的彈性問題。

## 如何判斷哪種技術路線更適合自己？

▍**李衛：**當前這個階段，我覺得三種路線都存在現實需求，現實需求導致每個應用方要根據自己的業務特點和現實的資源環境決定採用哪種路線，每一種路線都有優勢和劣勢。分散式中介軟體路線最大的劣勢是程式碼層級的改造量很大，因為中間加了一層分散式中介軟體；分散式儲存依賴於儲存的擴充套件，在擴充套件能力上存在侷限，尤其是跨地域等較長距離的擴充套件難度比較大，優勢是程式碼幾乎不需要改造；原生分散式的未來趨勢非常明顯，但因為發展時間相對較短，相較於前兩者在穩定性、生態等層面還存在短板，企業需要結合自己的業務進行抉擇。

▍**楊建榮：**我提煉了六個維度對技術棧進行對比：

**事務管理。**相對傳統模式，原生資料庫的事務管理有天然的優越性，因為業務都在一起。中介軟體的模式可能會放大事務風險或者隱患，原生模式因為是全新的體系，在事務管理層面有較大差異。

**發展週期。**原生分散式資料庫的週期相對來說更短一些，也是這些年非常流行的。中介軟體的模式，尤其銀行等企業，早期在方向上的沉澱，包括這樣的落地場景也會更多一點。

**遷移升級。**原生模式的遷移相對平滑，其他模式還需要配合做一些架構設計和拓撲擴充套件。

**高可用。**原生模式依賴雲平臺的能力在高可用層面具備天然優勢，但其他模式依賴底層的標準化模式會有一些短板。

**擴縮容。**中介軟體的模式是一個域定義的模式，在做 N+1 的擴充套件上存在諸多限制，雲原生分散式資料庫相對來說更加彈性和靈活。

**效能。**雲原生分散式資料庫推出早期也經歷了大量驗證，與其他模式相比，可能會有更多的成本消耗，但效能也有比較大的提升。

▍**王南：**我從場景的角度來聊，**首先是中介軟體方案，**當集中式資料庫無法滿足訴求，大家很自然地選擇用分庫分表的方式解決問題，將流量負載均衡到每個節點，該方案適用一些特定場景，比如對跨節點的分散式事務和一致性沒有強訴求，但也有很多問題無法解決，比如支付類場景或者其他需要跨節點事務的場景。

**其次是分散式共享儲存，**不同場景的儲存和計算負載要求不同，很可能存在擴充套件出來的計算和儲存資源有一個被浪費掉，該方案的存在很好地解決了這一問題，並且可以充分協同和發揮雲端儲存的優勢，這也是公有云廠商積極推動該方案的原因，廠商在公有云儲存基礎上做了一層封裝，可以提供不同型別、不同成本和價格的雲端儲存方案，這種方案需要使用者考慮的因素較多，比如資料庫架構設計層面如何與這種模式更好地融合。

**最後是雲原生分散式資料庫方案，**這對使用者來講是最簡單的，因為對使用者而言，其與集中式資料庫的使用體驗沒有差異，資料分佈、負載均衡以及故障自動恢復等資料庫都可以搞定，還免去了集中式場景下理解、學習及對應用改造的成本，但是產品成熟度以及當前積累的場景實踐案例是否可以很好地解決問題是企業比較擔心的，使用者可以場景的不同來選擇更合適的方案。

▍**劉博：**三種路線與時代發展有很強的關係。

**第一種中介軟體的方式對程式碼侵入性比較強，需要在單機版資料庫的基礎上增加分片規則。**以攜程為例，可以從使用者的維度進行分片，但有些資料無法找到合適的分片規則，例如：酒店資訊很難找到合適的維度，如果以城市為維度劃分，一線城市的酒店資源和三四線城市的酒店資源無法對等分片，這是該種方式的侷限性。該方式的好處是運維相對簡單，沒有引入新技術給基礎運維帶來負擔，但壓力就給到了業務側，程式碼需要做較大的改造。

**第二種是公有云廠商提供的方式。**好處是儲存資源基本做到無限擴充，使用者按量付費即可，缺點是計算資源有限，如果業務沒有明顯的讀寫分離場景，寫的計算節點資源受限於公有云的計算規格，這種路徑更適合讀的場景偏多的業務。

**第三種，從技術、架構層面來說是目前最好的選擇，且對業務沒有侵入性，擴縮容都比較彈性。**但目前觀察到的落地案例還不是特別多，我們比較期待這種方式更加成熟，因為對業務比較友好。

## 分散式資料庫逐漸成為主流商業資料庫選擇的原因？

▍**李衛：**一是上文提到的使用者需求的改變催生了分散式資料庫的發展；二是數字經濟時代，資料成為了最核心的生產要素，要想發揮資料價值，底層的核心技術運用也非常關鍵。如今的很多企業都在做數字化轉型，技術架構從集中式向分散式轉化，分散式資料庫的支援效果顯然更好。

▍**楊建榮：**我主要從四個方面回答該問題：

分散式資料庫相較商業資料庫發展更快主要得益於其他解決方案更耗成本，透過更高配的硬體或者高階儲存解決問題長期來看，成本是不容忽視的一個因素。

從使用體驗來看，分散式資料庫可以讓整個過程更加平滑。從研發模式來看，歷史債務較多的企業遷移到分散式是一個很大瓶頸。傳統的研發模式與當前越來越輕量化的方式是不相符的，分散式資料庫在這個方向上是可以做到相輔相成的。

效能，並不是說這種模式的效能一定比單機要好，但具有更強的擴充套件性，可以透過分散式平滑實現倍數的效能提升。

技術生態，國內的分散式資料庫廠商提供了完善的工具、文件包括配套的遷移工具，可以幫助企業實現無感遷移。

▍**王南：**這個話題的爭議度在幾年前還是比較大的，包括分散式是否是正確的方向都有比較大的爭議，當然這幾年好很多了。大家對分散式的接受度和訴求越來越強，但不代表已經成為主流，國內外也是有差異的，因此我不會輕易對這件事情下結論，但任何技術的發展都是需求驅動的，沒有普遍需求，這個觀點肯定是不成立的。

不論是市場佔有率還是使用者接受度來說，分散式資料庫目前距離主流肯定還有差距，但越來越多的場景對分散式是有強烈訴求的。在雲化的大趨勢下，我們相信這會是未來的主流方向之一。

▍**劉博：**目前業內很多創業公司和新型的資料庫產品都是以分散式的形態出現，這可以理解為時代的產物。從市場需求來看，業務的增長速度更快，對計算和儲存資源的要求更高。攜程的發展過程經歷了單機資料庫、單機資料庫加高階硬體、分庫分表（前文提到的第一種中介軟體的方式）時代，雖然分庫分表模式表面看起來沒有增加新的技術，但運維複雜度升高很多，因為分庫分表後，DB 規模和表規模越來越大。

分散式的引入對業務更加友好，以維護視窗為例，原來凌晨三四點的時候，業務量很低，可以在這個視窗進行維護升級，如今的攜程業務逐步國際化，很難找到維護視窗，需要在不需要當機的情況下進行維護升級，這也是攜程自 2018 年開始使用分散式資料庫解決的問題之一。原來需要熬到凌晨三四點才可以做的維護，現在可以選擇白天任何一個業務低峰時段進行，這也算是分散式的紅利之一。

## 分散式資料庫有哪些安全方案可以聊一聊？

▍**王南：**從安全形度來看，我想到了幾個方面：一是分散式資料庫與集中式資料庫場景下的安全體系基本能力，如使用者決策許可權是一樣的，這些依然存在很強的訴求；二是分散式可能會帶來更多挑戰，畢竟涉及多節點及更復雜的底層基礎設施，OceanBase 目前可以同時物理機、虛擬化、私有云和公有云四種部署方式，未來也會支援多雲。除傳統的安全手段之外，分散式資料庫可能會需要解決資料全鏈路的安全、資料儲存加密等問題，目前也會透過雲平臺提供一些加解密的方式，安全不是一蹴而就的，未來會逐漸將這些產品能力補齊。

▍**劉博：**作為一款商業產品來說，OceanBase 也會遵循國際通用的安全標準，使用者可以從三個維度來看待安全問題：儲存、審計和傳輸。比如 OceanBase 可以開啟 SSL 功能，實現客戶端和伺服器之間資料的安全傳輸。也可以開啟透明加密，實現儲存的加密。OceanBase 提供的審計表，記錄了所有的 SQL 訪問。這裡提一下，攜程根據審計表做了一些功能開發，我們將審計表中的資料全部抽取出來，做了 SQL 的實時分析，用於訪問異常檢測和效能分析。

## 真正的 HTAP 到底是怎樣的？

**▍李衛：**HTAP 這兩年的討論熱度較高，當企業內部對 TP 和 AP 同時有需求的時候，結合肯定是價效比最高的方式，否則面臨著人力、資源等各方面的浪費，至少目前來看這種方式是存在實際需求的，但需要與場景相結合。

▍**楊建榮：**從儲存角度來看，AP 本身的儲存會佔用一部分成本，這需要從成本層面做出取捨，無論是底層壓縮還是針對性的熱點資料，儘量在不影響原有 TP 業務的情況下讓業務更加平滑。

從計算層面來說，可以做擴充套件或者說外掛模式，整個的 AP 計算不是放在一個大池子裡，還是需要做出一些取捨。長遠來看，HTAP 的方式可以解決大部分訴求，但肯定有一些更專業的方向或者更長曆史週期的資料需要專門的 OLAP 實現。

▍**王南：**HTAP 嚴格來說並沒有特別明確的定義，這是 Gartner 首次提出的概念，大家的理解或許有所差異。目前有一類實現方式是同一個產品部署 AP 和 TP 系統，雖然是兩個系統，但是同一個產品解決了兩類場景問題。這就進一步分化為兩套引擎（一套處理 TP，一套處理 AP）和一套引擎（既可以處理 AP，又可以處理 TP）兩種方式。

如果回到使用者的原始訴求上來，HTAP 對使用者來講就是既要解決業務交易負載，也要解決複雜查詢、報批、報表這樣分析類負載問題，無非是用一個系統還是建兩個系統來跑的問題。資料量較小的情況下，Oracle 或許就可以；資料量較大的情況下，目前普遍選擇透過兩套系統來解決問題。隨著分散式的發展，這個問題又出現了新的解決方案，OceanBase 目前的路線是一個系統、一套引擎可以同時解決 TP 和 AP 兩類問題，包括資料儲存層面的最佳化，我們正在嘗試執行幾十 TB 量級 TPC-DS 的負載，希望透過技術手段解決這個問題。

▍**劉博：**在實際的場景中，TP 和 AP 的邊界可能沒有那麼清晰，很多業務的響應可能是 TP 級的，資源消耗又是 AP 級的，這個邊界越來越模糊，我們很難定義。而且國內的生態基本還是基於 Hadoop 的生態來構建的 AP 系統，這就有可能出現資料延遲、資料重複儲存、運維成本上升（需要兩個團隊各自運維兩個系統）等問題，HTAP 可以很好地解決這些問題。

## 分散式資料庫裡的 MapReduce 可能是什麼樣？

▍**王南：**這可能還不太一樣。OceanBase 將問題拆分為不同的維度：分散式的問題、計算模型的問題和儲存的問題。OceanBase 之所以選擇用一個儲存引擎來解決問題，主要是充分利用了快閃記憶體等硬體 + 新架構來解決海量資料的併發更新問題。雖然從概念上來看，分散式和儲存是兩層，但實際是放在一起解決的，透過分散式的協議解決節點間的資料複製和儲存問題，同時保證資料強一致性和多核高可用。只要做好最佳化器和語法層，計算引擎和模型是可以比較快速地滿足業務訴求的。在不同的層次解決不同的問題，儲存層解決效率問題，分散式解決高可用和擴充套件問題，計算層解決並行、相容性和生態問題。

## 分散式資料庫的學習門檻如何？

▍**劉博：**學習成本可能分兩個層面：語法層面常用的 SQL 語句都是相容的，在 OceanBase 的測試中，攜程僅發現了極個別無法支援的語句，也是使用頻度較低的；運維層面複雜度確實高出幾個數量級，因為資料訪問涉及的路徑變多了。當然，學習途徑也變多了，社群有文件、影片等很多資料都可以翻閱。資料庫學習最重要的是需要實操，先把 OceanBase 的開源版本執行起來看看，自行編譯看看。

## 分散式資料庫選型可以從哪幾個方面進行考慮？

▍李衛：分散式資料庫選型需要與業務場景相結合。在國內，金融、電信等領域已經在分散式資料庫層面有了大量實踐。我們從上述兩大行業抽離出了一些與資料庫高度相關的系統，比如計費系統、客戶系統等，經過試驗證明分散式資料庫確實已經能夠很好地支撐起相關業務的執行，但與老牌商用資料庫的能力相比還存在差距，此外還需要關注未來的持續穩定執行能力。

▍楊建榮：資料庫選型的這個問題可以透過 BATD 模型來看。其中，B 指的是業務驅動；A 指的是架構演進的視角看待技術選型，比如中介軟體就是這樣一種技術；T 指的是技術生態，是否在某些場景中有足夠的沉澱；D 指的是多元化，資料庫選型不要做大一統，而是更多考慮多元化，從技術棧演進的層面做出取捨。

▍王南：使用者對資料庫選型是最有發言權，從我們這些年來和眾多已經上線核心業務的客戶在選型關心維度的反饋上，使用者期望在滿足以下基本要求再去談產品的各種特性：

首先，資料是企業的核心命脈，不管選擇什麼樣的資料庫，保障資料不丟、不錯、不亂是最基本的要求。

其次，如果選擇分散式架構的資料庫，如何確保永遠可信任的資料一致性，包括叢集和叢集之間、副本和副本之間，分割槽和分割槽之間，索引和索引之間甚至是宏塊和宏塊之間的資料一致性鏈式校驗，從而防止因磁碟靜默錯誤或者因為硬體故障導致的資料不一致。

再次，是否能夠對於異構晶片、作業系統等可以實現混合部署、灰度部署，形成逃生機制，確保在資料庫改造升級時實現業務逃生。

然後，是否支援 DB-Mesh 的資料中心的部署和建設以滿足業務的彈性，可以實現單元化、雲原生、全密態的部署。

最後，有專業的團隊和支撐可以兜底。

基於上述的基本要求，從功能上可以歸納為四大方向：

**第一，剛效能力和指標滿足度。**這可能涉及到很多問題，包括效能、功能、安全、可靠，相容、資質等，這是最基礎的。

**第二，產品成熟度。**是否已經在足夠多的不同行業進行了落地實踐，在不同的使用者量、不同的業務負載下進行了驗證，產品是否只有一個核心，還是上下游產品生態兼具。

**第三，資料庫的廠商。**也就是背後團隊的技術能力，以及這家公司對資料庫戰略的定力和穩定性，也是影響巨大的，特別是對於中大型企業而言，這關係到系統後續是否可以穩定持續執行。

**第四，成本和價效比。**這不僅僅是表面的價格，還包括穩定性的成本、遷移成本、服務成本、運維成本等各方面，甚至有些使用者考慮一旦出現問題，兜底方案的成本有多大。

從市場來看，如今的資料庫市場確實是百花齊放，好處是提供了更多樣化的能力，避免被單一供應商繫結；壞處是選擇的成本很高，也可能出現重複造輪子的現象。這就需要行業監管和標準化組織的引導，讓行業健康發展。

▍**劉博：**我也同意三位老師關於選型肯定需要與場景結合的看法。攜程在選擇分散式資料庫時主要考慮了功能完備度、與現有資料庫的相容性以及效能和支援等方面。OceanBase 目前也有社群版本，我們可能也會考慮社群的 star 數量、PR 數量、issue 數量等。

## 分散式資料庫的遷移過程中應該注意哪些問題？

▍**劉博：**遷移可能需要考慮是否平滑、相容性和效能等。我們之前針對 OceanBase 做過一些測試，比如同樣的語句在 MySQL 和 OceanBase 上等比例放上，看兩邊的響應程度等，也包括一些相容性測試。

此外，企業還需要考慮遷移過程的穩定性，對新的資料庫是否具備足夠的掌控力，一旦發生問題，是否有回退方案。**以 OceanBase 為例，我們透過 OceanBase 自身提供的 OMS 功能，搭了一條反向鏈路到 MySQL，一旦遇到緊急情況，可以平滑再切到 MySQL。**

▍**王南：**從橫向來看，可以分為遷移前、遷移中和遷移後三個階段。事前，我們提供了 OMA 這樣的工具，可以對業務負載進行分析，包括視覺化的報表告知使用者相容程度、建議使用的遷移方案和可能存在的風險。

事中，提供一個工具完成整個自動化遷移過程，這個後面詳細展開。

事後，需要檢驗遷移是否真的完成以及資料是否一致，這也不意味著萬事大吉了，還需要準備一些預案以應對執行後可能的突發情況。

從縱向的角度來看也就是上述提到的事中階段，這裡面有幾個核心問題需要考慮：一是原資料如何遷移，假設相容度極高，各種高階能力都可以直接運用，這是比較省心的。假設相容度不高，這可能需要大量的手工 SQL 轉換，甚至需要進行應用層的改寫，成本極高，OceanBase 本身的 OMS 中提供了大量工具可供選擇，比如靜態的全量資料遷移、增量的資料遷移，自定義過濾條件，甚至一些運算元轉換等。

此外，對於豐富的資料來源和目標端的支援，因為資料遷移不僅僅是從原來的集中式資料庫遷移到分散式資料庫，不同的使用者可能會有不同的訴求，比如對一些流、快取進行遷移等，這需要雲端支援的目標型別足夠豐富。

▍**楊建榮：**我在上述兩位的回答上補充一些細節，遷移過程中常用的一種方式是雙寫，透過這種模式驗證，相對來說整個遷移過程更平滑可控。另外，我們可能會在一些場景做資料同步，比如 A 到 B 的切換過程持續做資料同步，需要不斷地考慮資料的一些基礎訓練，包括 SQL 回放、效能驗證等。當然，從整個切換模式來說，業務方几乎是無感知或者閃斷。

十問分散式資料庫：技術趨勢、選型及標準思考

相關文章