隨著用戶數(shù)據(jù)量的不斷增長，基于傳統(tǒng)共享存儲(chǔ)的縱向擴(kuò)展能力漸漸變得力不從心，分布式存儲(chǔ)成為應(yīng)對(duì)用戶海量數(shù)據(jù)的標(biāo)配。
作為一位架構(gòu)師，在設(shè)計(jì)系統(tǒng)的分布式存儲(chǔ)架構(gòu)時(shí)，需要關(guān)注哪些方面呢？或者我們換句話說，對(duì)于客戶來說，一個(gè)理想中的分布式存儲(chǔ)產(chǎn)品應(yīng)該具有哪些特性呢？

我們認(rèn)為完善的分布式存儲(chǔ)架構(gòu)應(yīng)該關(guān)注這五個(gè)方面：

• 擴(kuò)展性：擴(kuò)展性可謂是分布式存儲(chǔ)有別于單機(jī)存儲(chǔ)的重要特征，分布式存儲(chǔ)的擴(kuò)展性遠(yuǎn)遠(yuǎn)好于單機(jī)存儲(chǔ)，但是不同分布式存儲(chǔ)系統(tǒng)的擴(kuò)展性之間仍然有著非常大的差異。某些分布式系統(tǒng)在幾十個(gè)節(jié)點(diǎn)的量級(jí)上可能運(yùn)行的很好，但是節(jié)點(diǎn)如果再多下去，到了上百個(gè)乃至上千個(gè)的時(shí)候可能就會(huì)面臨很大的問題。用戶數(shù)據(jù)的增長沒有止境，如果不能做到線性擴(kuò)展，那么今天能夠支撐業(yè)務(wù)的系統(tǒng)到了明天可能就會(huì)成為業(yè)務(wù)進(jìn)一步發(fā)展的阻礙。
• 高可用：在分布式系統(tǒng)中出現(xiàn)節(jié)點(diǎn)故障是很常見的事情，分布式系統(tǒng)中的節(jié)點(diǎn)越多，出現(xiàn)節(jié)點(diǎn)故障的頻率也就會(huì)越高。在發(fā)生節(jié)點(diǎn)故障時(shí)是否能夠保證系統(tǒng)仍然可用，對(duì)于很多業(yè)務(wù)來說至關(guān)重要。根據(jù)故障類型和恢復(fù)時(shí)間的不同，高可用也分有不同的級(jí)別，系統(tǒng)是否可以容單點(diǎn)故障、多點(diǎn)故障、單機(jī)房故障、多機(jī)房故障、單城市故障、多城市故障？系統(tǒng)恢復(fù)是否可以做到天級(jí)恢復(fù)、小時(shí)級(jí)恢復(fù)、分鐘級(jí)恢復(fù)、秒級(jí)恢復(fù)？不同業(yè)務(wù)場(chǎng)景可能會(huì)對(duì)高可用有不同的要求。
• 一致性：一致性其實(shí)是一個(gè)被濫用的概念，很多同學(xué)會(huì)將其和數(shù)據(jù)庫事務(wù)特性中ACID中的C相混淆，在這里我們特指分布式系統(tǒng)的一致性。那么分布式系統(tǒng)的一致性指的是什么？如果用一句話進(jìn)行概括，我們認(rèn)為一致性指的是在一個(gè)分布式的讀寫系統(tǒng)中，用戶是否總能讀到最新寫入的數(shù)據(jù)。如果總是能讀到，那么這個(gè)系統(tǒng)就是強(qiáng)一致的，否則則是弱一致的。最終一致性則是弱一致的一種特例，指的是盡管不能總是讀到最新的數(shù)據(jù)，但隨著寫入操作的終止，最終還是可以讀到最新的數(shù)據(jù)。盡管很多分布式系統(tǒng)都宣稱提供一致性，但很多時(shí)候它們只是提供弱一致或者最終一致。強(qiáng)一致對(duì)于一些業(yè)務(wù)特別是和交易相關(guān)的金融業(yè)務(wù)來說至關(guān)重要，如果不能保證總是讀到最新的數(shù)據(jù)，那么就會(huì)有發(fā)生資損的可能。
• 低成本：分布式存儲(chǔ)系統(tǒng)可以使用更加廉價(jià)的PC服務(wù)器來代替高端的小機(jī)及大機(jī)，在成本上具有顯著的優(yōu)勢(shì)。但低成本并不意味著低性能，事實(shí)上由于分布式系統(tǒng)下有著非常多的節(jié)點(diǎn)，同時(shí)使用這些節(jié)點(diǎn)的能力可以為我們帶來相比大型服務(wù)器更高的性能。低成本高性能可以為我們的用戶節(jié)省更多的系統(tǒng)成本。
• 易用性：低成本特性通常關(guān)注于硬件成本，易用性則關(guān)系到人力成本。對(duì)于開發(fā)同學(xué)來說，易用性意味著簡單易上手的使用接口，最好學(xué)習(xí)和遷移成本為零，同時(shí)功能強(qiáng)大，能夠滿足各式各樣的需求；對(duì)于運(yùn)維同學(xué)來說，易用性則意味著系統(tǒng)穩(wěn)定健壯，系統(tǒng)監(jiān)控及運(yùn)維手段完善，學(xué)習(xí)及使用門檻低。

架構(gòu)演進(jìn)歷程

架構(gòu)設(shè)計(jì)服務(wù)于業(yè)務(wù)，再完美的系統(tǒng)架構(gòu)都需要有業(yè)務(wù)進(jìn)行使用才能創(chuàng)造價(jià)值。對(duì)于業(yè)務(wù)來說，當(dāng)然希望我們的產(chǎn)品能夠同時(shí)具備高擴(kuò)展、高可用、強(qiáng)一致、低成本以及零門檻的易用性，但對(duì)于系統(tǒng)架構(gòu)師和開發(fā)者來說，這五個(gè)特性之間存在相互矛盾的不少，同時(shí)在實(shí)現(xiàn)這些特性時(shí)也會(huì)面臨巨大的復(fù)雜性，這要求我們?cè)谧鱿到y(tǒng)設(shè)計(jì)及實(shí)現(xiàn)時(shí)需要有所權(quán)衡。

下面我們就OceanBase創(chuàng)立九年多以來存儲(chǔ)架構(gòu)的演進(jìn)歷程，來回顧每一次架構(gòu)變更背后的權(quán)衡與思考。

1）OceanBase 0.1版本（2010年）

OceanBase由陽振坤于2010年在淘寶創(chuàng)立，當(dāng)時(shí)淘寶大多數(shù)業(yè)務(wù)都已經(jīng)按照用戶維度做了分庫分表，一個(gè)全新的分布式存儲(chǔ)系統(tǒng)似乎很難有用武之地。最終我們找到了OceanBase的第一個(gè)業(yè)務(wù)：淘寶收藏夾，也就是我們今天打開手淘看到喜歡的商品點(diǎn)收藏時(shí)用到的收藏夾，直到今天它仍然跑在OceanBase數(shù)據(jù)庫上面。

當(dāng)時(shí)收藏夾面臨了一個(gè)分庫分表難以解決的問題，它的核心業(yè)務(wù)主要包括兩張表，一張是用戶表，記錄一個(gè)用戶收藏的商品條目，數(shù)量從幾條到幾千條不等；另一張是商品表，記錄一件商品的描述、價(jià)格等明細(xì)信息。如果一個(gè)用戶增加/刪除收藏，那么相應(yīng)的就向用戶表中插入/刪除數(shù)據(jù)就可以了；同時(shí)如果一個(gè)商家需要修改商品描述，例如修改商品價(jià)格等信息，那么相應(yīng)的更新商品表就可以了。

當(dāng)用戶打開收藏夾時(shí)，通過用戶表和商品表的連接查詢，就可以展現(xiàn)給用戶最新的商品信息。最開始的時(shí)候，這兩張表是在一個(gè)數(shù)據(jù)庫里面，也一直運(yùn)行地很好，但隨著用戶數(shù)據(jù)量的增長，單個(gè)數(shù)據(jù)庫放不下了，一般常用的做法是將表按照用戶維度進(jìn)行拆分，用戶表是可以這樣拆，但是商品表中沒有用戶字段，如果按照商品條目進(jìn)行拆分，那么在用戶打開收藏夾時(shí)，就需要對(duì)多個(gè)不同的庫進(jìn)行查詢并做連接，當(dāng)時(shí)的數(shù)據(jù)庫中間件并沒有這樣的能力，即使可以這么做，一次查詢也會(huì)耗費(fèi)非常長的時(shí)間，會(huì)極大的影響用戶體驗(yàn)，業(yè)務(wù)遇到了很大的困難。

OceanBase接下了用戶的這個(gè)難題，如果我們分析擴(kuò)展性、高可用、一致性、低成本和易用性這五個(gè)特性，那么什么是業(yè)務(wù)的剛需，什么是業(yè)務(wù)可以放棄的呢？業(yè)務(wù)最強(qiáng)的剛需是擴(kuò)展性，因?yàn)閭鹘y(tǒng)的單機(jī)模式已經(jīng)走到了盡頭；最可以放棄的其實(shí)是易用性，因?yàn)闃I(yè)務(wù)對(duì)寫入查詢的使用非常簡單，提供簡單的讀寫接口就可以滿足業(yè)務(wù)需求，業(yè)務(wù)甚至不需要在表上構(gòu)建索引。同時(shí)我們也注意到業(yè)務(wù)對(duì)一致性也有一定的需求，業(yè)務(wù)可以容忍一定的弱一致讀，但不能容忍數(shù)據(jù)出錯(cuò)。這些特性決定了OceanBase從誕生的第一天起，就是一個(gè)支持在線事務(wù)處理的關(guān)系型分布式數(shù)據(jù)庫。

我們注意到收藏夾這個(gè)業(yè)務(wù)的特性，它的存量數(shù)據(jù)比較大，但是每天的增量并不大，畢竟每天新增收藏的用戶并不是特別多。它更關(guān)心數(shù)據(jù)存儲(chǔ)的擴(kuò)展性，而對(duì)寫入的擴(kuò)展性要求并不是很高。我們將數(shù)據(jù)分為兩部分：基線數(shù)據(jù)和增量數(shù)據(jù)?；€數(shù)據(jù)是靜態(tài)的，分布式地存儲(chǔ)在ChunkServer上。增量數(shù)據(jù)寫在UpdateServer上，通常是存儲(chǔ)在內(nèi)存里面，通過Redo Log支持在線事務(wù)，在每天的業(yè)務(wù)低峰期，UpdateServer上的數(shù)據(jù)會(huì)與ChunkServer上的數(shù)據(jù)做合并，我們稱之為“每日合并”。MergeServer是一個(gè)無狀態(tài)的Server，提供數(shù)據(jù)寫入的路由與數(shù)據(jù)查詢的歸并；RootServer負(fù)責(zé)整個(gè)集群的調(diào)度與負(fù)載均衡。這是一個(gè)類似于LSM Tree的存儲(chǔ)架構(gòu)，這也決定了今后OceanBase的存儲(chǔ)引擎都是基于LSM Tree的。

我們回過頭來看OceanBase0.1的架構(gòu)，它實(shí)際上具有很強(qiáng)的一致性，因?yàn)閷懭胧莻€(gè)單點(diǎn)，讀到的數(shù)據(jù)一定是最新寫入的數(shù)據(jù)，同時(shí)成本也并不高，也具有一定的擴(kuò)展性，存儲(chǔ)空間可以很容易地做擴(kuò)展，很好滿足了當(dāng)時(shí)業(yè)務(wù)的需求。

2）OceanBase 0.2-0.3版本（2011年）

很快OceanBase 0.1版本上線了，并為收藏夾業(yè)務(wù)提供了讀服務(wù)，但業(yè)務(wù)不能把所有流量都切到OceanBase上面來，因?yàn)镺ceanBase 0.1版本的架構(gòu)有著一個(gè)很大的缺陷：它不是高可用的。任何一臺(tái)服務(wù)器的宕機(jī)都會(huì)造成數(shù)據(jù)的不可訪問，這對(duì)于收藏夾這樣的業(yè)務(wù)是無法接受的。很快我們帶來了OceanBase 0.2版本的架構(gòu)，補(bǔ)上了高可用的短板。

在OceanBase 0.2版本中我們引入了主備庫模式，這也是當(dāng)時(shí)傳統(tǒng)數(shù)據(jù)庫常用的容災(zāi)模式，數(shù)據(jù)通過redo log從主庫同步到備庫，當(dāng)主庫發(fā)生問題時(shí)，可以把備庫切換為主庫繼續(xù)提供服務(wù)。redo log的同步是異步的，這意味著主備的切換是有損的，可能會(huì)丟失若干秒的數(shù)據(jù)。

我們將OceanBase 0.2版本和OceanBase 0.1版本的架構(gòu)進(jìn)行對(duì)比，會(huì)發(fā)現(xiàn)OceanBase 0.2版本終于有了高可用這一重要特性，但高可用的獲得不是沒有代價(jià)的，首先系統(tǒng)不再是強(qiáng)一致的了，我們不能夠保證業(yè)務(wù)總是能夠讀到最新的數(shù)據(jù)，在宕機(jī)場(chǎng)景下，數(shù)據(jù)可能會(huì)有部分丟失；其次主備庫的引入極大地增加了成本，我們使用的機(jī)器數(shù)量翻番了。之后的OceanBase 0.3版本基于OceanBase 0.2版本做了很多代碼上的優(yōu)化，進(jìn)一步降低了系統(tǒng)成本，但從架構(gòu)上來說和OceanBase 0.2版本并沒有顯著的差別。

3）OceanBase 0.4版本（2012年）

隨著收藏夾業(yè)務(wù)的成功，很快我們接到了更多新的業(yè)務(wù)，淘寶直通車是一個(gè)面向商家的業(yè)務(wù)，也面臨著分庫分表難以解決的問題。首先淘寶直通車的數(shù)據(jù)量越來越大，單庫難以支撐，同時(shí)它又是一個(gè)OLAP類型的業(yè)務(wù)，有很多多表間的關(guān)聯(lián)查詢，每張表的維度又各不相同，無法統(tǒng)一按照用戶id進(jìn)行拆分。對(duì)于OceanBase的擴(kuò)展性、高可用以及低成本業(yè)務(wù)都很滿意，但是接口使用確實(shí)是太痛苦了。那么問題來了，什么是最好的接口語言？對(duì)于編程來說，可能不同的語言都有不同的擁躉，但對(duì)于數(shù)據(jù)操作來說，我們認(rèn)為SQL一定是最好的語言。對(duì)于簡單的KV查詢，你可能會(huì)覺得SQL過于沉重了，但當(dāng)你的業(yè)務(wù)慢慢復(fù)雜起來后，SQL一定是使用最簡單輕便的。

在OceanBase 0.4版本，我們對(duì)SQL有了初步的支持，用戶可以使用標(biāo)準(zhǔn)SQL來訪問OceanBase，支持簡單的增刪改查以及關(guān)聯(lián)查詢，但對(duì)SQL的支持并不完整。同時(shí)OceanBase 0.4版本也是我們最后一個(gè)開源版本。

對(duì)比OceanBase 0.4版本和OceanBase 0.2版本的架構(gòu)，在OceanBase 0.4版本我們最終補(bǔ)上了易用性的白板，開始慢慢有了一個(gè)標(biāo)準(zhǔn)分布式數(shù)據(jù)庫的樣子。

4）OceanBase 0.5版本（2014年）

2012年底的時(shí)候，OceanBase團(tuán)隊(duì)來到了支付寶。當(dāng)時(shí)支付寶面臨著全面去掉IOE的強(qiáng)烈需求，IOE的成本太高了，但PC服務(wù)器的穩(wěn)定性難以和高端存儲(chǔ)相比，如果我們使用MySQL這樣的開源數(shù)據(jù)庫基于PC服務(wù)器進(jìn)行替代，業(yè)務(wù)就面臨著可能會(huì)丟數(shù)據(jù)的潛在風(fēng)險(xiǎn)。當(dāng)時(shí)基于MySQL的容災(zāi)方案仍然只是主備同步，對(duì)于支付寶交易支付這樣的核心系統(tǒng)來說，丟失一筆訂單造成的損失難以估量。業(yè)務(wù)對(duì)數(shù)據(jù)庫的強(qiáng)一致和高可用提出了更高的要求，也使得我們搭建了OceanBase 0.5版本的新一代架構(gòu)。

在OceanBase 0.5版本中，我們引入了Paxos一致性協(xié)議，通過多數(shù)派選舉來保障單點(diǎn)故障下的數(shù)據(jù)一致性。一般情況下，OceanBase 0.5版本的部署模式會(huì)是三副本，當(dāng)有一個(gè)副本出現(xiàn)問題時(shí)，另外兩個(gè)副本會(huì)補(bǔ)齊日志并重新選出一個(gè)主提供服務(wù)，我們可以做到單點(diǎn)故障下不丟失任何數(shù)據(jù)，同時(shí)故障恢復(fù)時(shí)間小于30s。同時(shí)為了更好地支撐業(yè)務(wù)，在OceanBase 0.5版本中，我們?nèi)婕嫒萘薓ySQL協(xié)議，支持了二級(jí)索引并有了基于規(guī)則的執(zhí)行計(jì)劃，用戶可以用MySQL的客戶端來無縫連接OceanBase，可以像使用MySQL一樣來使用OceanBase。

對(duì)比OceanBase 0.4版本和OceanBase 0.5版本的架構(gòu)，我們發(fā)現(xiàn)OceanBase 0.5版本基于Paxos，有了更強(qiáng)的高可用以及強(qiáng)一致，基于SQL有了更好的易用性，但代價(jià)是從兩副本變成三副本，系統(tǒng)成本進(jìn)一步增加了50%。

5）OceanBase 1.0版本（2016年）

在OceanBase 0.5版本的架構(gòu)下，業(yè)務(wù)對(duì)強(qiáng)一致、高可用以及易用性的需求都得到了很好的支持，痛點(diǎn)慢慢集中在擴(kuò)展性和成本上。隨著用戶寫入量的不斷增長，UpdateServer的寫入單點(diǎn)總是會(huì)成為瓶頸，同時(shí)三副本也帶來了過高的成本消耗。OceanBase 1.0版本帶來了全新的架構(gòu)，重點(diǎn)解決了擴(kuò)展性和成本的痛點(diǎn)。

在OceanBase 1.0版本中，我們支持了多點(diǎn)寫入，從架構(gòu)上將UpdateServer、ChunkServer、MergeServer和RootServer都合并為一個(gè)OBServer，每一個(gè)OBServer都可以承擔(dān)讀寫，整體架構(gòu)更加優(yōu)雅，運(yùn)維部署也更加簡單。一張表可以被劃分為多個(gè)分區(qū)，不同分區(qū)可以散布在不同的OBServer上，用戶的讀寫請(qǐng)求通過一層代理OBProxy路由到具體的OBServer上進(jìn)行執(zhí)行。對(duì)于每個(gè)分區(qū)都仍然通過Paxos協(xié)議做三副本高可用，當(dāng)有一臺(tái)OBServer出現(xiàn)故障時(shí)，這臺(tái)OBServer上的分區(qū)會(huì)自動(dòng)切到其他包含對(duì)應(yīng)分區(qū)的OBServer上提供服務(wù)。

在成本方面，我們注意到在Paxos協(xié)議中，需要三副本同步的只是日志，日志需要寫三份，但是數(shù)據(jù)并不是，和數(shù)據(jù)相比日志量總是小的。如果將日志和數(shù)據(jù)分開，我們就可以使用兩副本的存儲(chǔ)開銷實(shí)現(xiàn)三副本高可用。在OceanBase 1.0版本中，我們將副本分為兩種類型：全功能副本和日志副本，其中全功能副本既包含數(shù)據(jù)也包含日志，提供完整的用戶讀寫；日志副本只包含日志，只進(jìn)行Paxos投票。
同時(shí)在OceanBase 1.0版本中，我們引入了多租戶的概念，在同一個(gè)OceanBase集群中，可以支持多個(gè)不同的租戶，這些租戶共享整個(gè)集群資源，OceanBase會(huì)對(duì)不同租戶的CPU、內(nèi)存、IO及磁盤使用進(jìn)行資源隔離。租戶可以根據(jù)自己的需要配置不同的資源容量，集群會(huì)根據(jù)不同OBServer的負(fù)載做動(dòng)態(tài)的負(fù)載均衡。這使得我們可以把很多個(gè)小租戶部署到同一個(gè)大集群中來，降低整體的系統(tǒng)成本。

和OceanBase 0.5版本相比，OceanBase 1.0版本的擴(kuò)展性有了大幅提升，而且由于引入了日志副本和多租戶技術(shù)，在成本上有了大幅降低；但擴(kuò)展性的提升不是沒有代價(jià)的，多點(diǎn)寫入帶來了巨大的復(fù)雜性。首先用戶的寫入并不一定會(huì)只寫單個(gè)分區(qū)，對(duì)于多個(gè)分區(qū)的寫入不可避免會(huì)帶來分布式事務(wù)，我們使用兩階段提交協(xié)議來完成分布式事務(wù)。其次在一個(gè)分布式系統(tǒng)中獲取一個(gè)全局單調(diào)遞增的時(shí)間戳是極其困難的，由于沒有全局時(shí)鐘，我們基于局部時(shí)間戳做單分區(qū)內(nèi)的讀寫并發(fā)控制，這使得系統(tǒng)的一致性有了一定的限制，雖然單分區(qū)的查詢?nèi)匀皇菑?qiáng)一致的，但跨分區(qū)的查詢無法保證讀的強(qiáng)一致，這對(duì)于用戶而言會(huì)是一個(gè)不小的限制。同時(shí)由于分區(qū)的關(guān)系，二級(jí)索引成為了分區(qū)內(nèi)的局部索引，這要求索引鍵中一定需要包含分區(qū)鍵，無法支持全局的唯一索引，這對(duì)于用戶使用也造成了一定的不便。

6）OceanBase 2.0版本（2018年）

OceanBase 2.0版本的外部整體架構(gòu)與OceanBase 1.0版本沒有太大差別，仍然是一個(gè)share nothing的三副本架構(gòu)，但在內(nèi)部我們對(duì)擴(kuò)展性、高可用、一致性、低成本和易用性都做了極大的提升。

在擴(kuò)展性方面，我們實(shí)現(xiàn)了分區(qū)分裂的功能。在建表的時(shí)候，用戶對(duì)合適的分區(qū)數(shù)可能沒有很好的估計(jì)，當(dāng)分區(qū)過大時(shí)，可以通過分區(qū)分裂來使得分區(qū)數(shù)變多。盡管分區(qū)分裂是一個(gè)比較重的DDL操作，在OceanBase 2.0版本中，分區(qū)分裂是可以在線進(jìn)行的，對(duì)用戶的正常業(yè)務(wù)讀寫并不會(huì)造成太大影響。

在高可用方面，我們支持了主備庫功能，對(duì)于某些只有雙機(jī)房的用戶，可以在機(jī)房內(nèi)通過三副本做機(jī)房內(nèi)的無損容災(zāi)，通過主備庫做跨機(jī)房的有損容災(zāi)。

在一致性方面，我們支持了全局快照，真正意義上實(shí)現(xiàn)了分布式讀寫下的強(qiáng)一致?；谌挚煺?#xff0c;我們也完成了對(duì)全局索引以及外鍵的支持。

在低成本方面，我們?cè)谑聞?wù)層支持了TableGroup，允許把一組相近的表“綁定”在一起，減少分布式事務(wù)的開銷。在存儲(chǔ)層引入了數(shù)據(jù)編碼，通過字典、RLE、Const、差值、列間等值、列間前綴等算法進(jìn)一步壓縮存儲(chǔ)空間的占用，并且對(duì)于數(shù)據(jù)的編碼是自適應(yīng)的，會(huì)根據(jù)數(shù)據(jù)特征來自動(dòng)選擇合適的編碼算法。

在易用性方面，我們支持了Oracle租戶，允許用戶在同一套ObServer集群中同時(shí)使用MySQL租戶與Oracle租戶，并且支持存儲(chǔ)過程、窗口函數(shù)、層次查詢、表達(dá)式索引、全文索引、ACS、SPM、回收站等功能。

總結(jié)

盡管今天的OceanBase 2.0版本在擴(kuò)展性、高可用、一致性、低成本以及易用性方面做到了更好的平衡，但這樣的架構(gòu)并不是一蹴而就的，從OceanBase 0.1版本到OceanBase 2.0版本的發(fā)展歷程來看，OceanBase的架構(gòu)總是在一直進(jìn)化，為了能夠更好地服務(wù)于業(yè)務(wù)，很多事物總是面臨著許多權(quán)衡取舍，一項(xiàng)特性的提升會(huì)以其他特性的降低為代價(jià)。架構(gòu)的優(yōu)化演進(jìn)沒有終點(diǎn)，未來為了更好滿足業(yè)務(wù)的需求，OceanBase的架構(gòu)還會(huì)不斷進(jìn)行演化。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的首度公开！OceanBase存储系统架构的演进历程及工程实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。