編者按：在國(guó)產(chǎn)替代浪潮下，國(guó)產(chǎn)自主數(shù)據(jù)庫(kù)正在快速崛起。在眾多頭部國(guó)產(chǎn)數(shù)據(jù)庫(kù)玩家中，低調(diào)耕耘多年的螞蟻 OceanBase 一直是“掃地僧”一般的存在。OceanBase 生于大數(shù)據(jù)時(shí)代，2010 年支付寶正式成立 OceanBase，當(dāng)時(shí)云計(jì)算方興未艾，互聯(lián)網(wǎng)正高速發(fā)展。OceanBase 創(chuàng)建初心是要解決“海量數(shù)據(jù)管理的難題”，真正做一個(gè)“頂天立地”的通用性產(chǎn)品，如今 OceanBase 已成為國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)的代表產(chǎn)品。螞蟻 OceanBase 作為一家獨(dú)立的數(shù)據(jù)庫(kù)廠商，也一直穩(wěn)居國(guó)產(chǎn)數(shù)據(jù)庫(kù)市場(chǎng)第一梯隊(duì)。此前羅超頻道對(duì)OceanBase 也有多次專(zhuān)題報(bào)道。

那么，OceanBase 的架構(gòu)是如何演進(jìn)的？OceanBase 的架構(gòu)設(shè)計(jì)背后有什么技術(shù)考量？其獨(dú)創(chuàng)的“單機(jī)分布式一體化”架構(gòu)會(huì)不會(huì)成為數(shù)據(jù)庫(kù)未來(lái)？今天分享一篇干貨筆記，作者為現(xiàn)任螞蟻OceanBase CTO楊傳輝，他時(shí)也是中國(guó)計(jì)算機(jī)學(xué)會(huì)（CCF）數(shù)據(jù)庫(kù)專(zhuān)委會(huì)執(zhí)行委員，他帶領(lǐng) OceanBase 技術(shù)團(tuán)隊(duì)成功打造了下一代企業(yè)級(jí)分布式數(shù)據(jù)庫(kù)。

以下為正文：

我從07年開(kāi)始研究大規(guī)模分布式系統(tǒng)，剛開(kāi)始參照Google三駕馬車(chē)（GFS/MapReduce/Bigtable），10年開(kāi)始加入當(dāng)時(shí)的淘寶做OceanBase。OceanBase最初是一個(gè)分布式架構(gòu)，支持的SQL功能非常有限，后來(lái)逐步加入SQL功能并通用化。

剛開(kāi)始接觸大規(guī)模分布式系統(tǒng)的時(shí)候，我覺(jué)得這個(gè)領(lǐng)域特別高大上，當(dāng)年的分布式系統(tǒng)有點(diǎn)像今天的ChatGPT，涉及的技術(shù)很前沿，而且有些協(xié)議非常難，我記得當(dāng)時(shí)僅僅理解Paxos協(xié)議就花費(fèi)了一年多的時(shí)間，看了十幾篇相關(guān)論文且和小伙伴們做了大量的技術(shù)討論。

曾經(jīng)有一段時(shí)間，我覺(jué)得分布式是IT軟件技術(shù)皇冠上的明珠，所有系統(tǒng)只有做成分布式才顯檔次。但是，當(dāng)我們將OceanBase早期版本應(yīng)用到淘寶和支付寶時(shí)，用戶(hù)和DBA給我們提出的都是SQL兼容性和性能成本相關(guān)的需求，把我們和單機(jī)的MySQL數(shù)據(jù)庫(kù)做比較，只有完全兼容且性?xún)r(jià)比更高才會(huì)選擇OceanBase。他們告訴我，OceanBase的擴(kuò)展性和無(wú)損容災(zāi)確實(shí)很好，也認(rèn)同分布式這個(gè)方向，但是對(duì)不起，老板說(shuō)今年業(yè)務(wù)發(fā)展太快，不能投入額外人力做數(shù)據(jù)庫(kù)改造，也不能投入額外的數(shù)據(jù)庫(kù)服務(wù)器。阿里有一句土話叫“既要也要還要”，小孩才做選擇，用戶(hù)和DBA想要的就是一個(gè)不要做選擇的“成年人的數(shù)據(jù)庫(kù)”。我記得當(dāng)時(shí)還和Google Spanner的研發(fā)人員做過(guò)一次技術(shù)討論，我問(wèn)他們?yōu)槭裁碐oogle內(nèi)部能夠接受Spanner很差的單機(jī)性能，他們告訴我Google內(nèi)部的程序員很強(qiáng)，大家都可以把應(yīng)用修改為異步程序。另外一點(diǎn)就是，Google有Jeff Dean，只要他想統(tǒng)一基礎(chǔ)架構(gòu)就可以自上而下推進(jìn)。我很羨慕Google內(nèi)部做基礎(chǔ)設(shè)施的研發(fā)人員，同時(shí)，我也意識(shí)到，這種模式是不可擴(kuò)展的。對(duì)于開(kāi)發(fā)者來(lái)講，一定要把單機(jī)的高性能低門(mén)檻融入到分布式的可擴(kuò)展高可用才能做出一個(gè)真正好用的分布式數(shù)據(jù)庫(kù)。

我們?cè)?016年發(fā)布了全分布式架構(gòu)OceanBase 1.0版本，這個(gè)版本的所有節(jié)點(diǎn)都是可讀可寫(xiě)的，但是，有一個(gè)問(wèn)題，那就是每個(gè)節(jié)點(diǎn)用于分布式相關(guān)的overhead比較大，當(dāng)表格和分區(qū)較多時(shí)，即使系統(tǒng)空轉(zhuǎn)，也會(huì)消耗好幾個(gè)CPU核用于分布式相關(guān)操作。這個(gè)問(wèn)題使得OceanBase 1.x系列的版本只能幫助較大規(guī)模的企業(yè)解決數(shù)據(jù)庫(kù)的問(wèn)題，很難在中小企業(yè)做規(guī)?；瘡?fù)制。于是，我們?cè)?018年開(kāi)始討論如何降低分布式數(shù)據(jù)庫(kù)的門(mén)檻，讓分布式數(shù)據(jù)庫(kù)成為一個(gè)人人皆可觸達(dá)的東西。

數(shù)據(jù)庫(kù)底層架構(gòu)的調(diào)整需要非常慎重，我們足足花費(fèi)了兩年多的時(shí)間完成了技術(shù)討論和總體架構(gòu)的設(shè)計(jì)，并在2020年年中左右開(kāi)始做詳細(xì)設(shè)計(jì)和代碼開(kāi)發(fā)，再經(jīng)過(guò)兩年多的時(shí)間才在2022年8月份發(fā)布了第一個(gè)OceanBase 4.0版本，代號(hào)“小魚(yú)”。4.0版本奠定了單機(jī)分布式一體化架構(gòu)的底座，但是還有很多的遺留問(wèn)題，在3月份開(kāi)發(fā)者大會(huì)發(fā)布的4.1版本中解決。

我從2021年開(kāi)始對(duì)外鋪墊一體化架構(gòu)的概念，在2021年10月22日的云棲大會(huì)上分享了<<OceanBase一體化架構(gòu)助力核心系統(tǒng)>>。最早的一體化架構(gòu)叫做“集中式分布式一體化“，當(dāng)時(shí)我們認(rèn)為DBA更加熟悉集中式這個(gè)說(shuō)法。不過(guò)，市場(chǎng)品牌的負(fù)責(zé)人建議修改成 “單機(jī)分布式一體化”，這樣會(huì)更加形象直觀，能夠更好地表達(dá)OceanBase的技術(shù)特點(diǎn)，開(kāi)發(fā)者也更容易理解。

可行性分析，如何消除分布式帶來(lái)的overhead？

架構(gòu)設(shè)計(jì)首先要做的就是可行性分析。做技術(shù)的同學(xué)肯定都很熟悉，架構(gòu)設(shè)計(jì)的核心在于取舍，為什么能夠做到，背后的原理是什么，舍棄了什么。我們?cè)谠O(shè)計(jì)一體化架構(gòu)時(shí)，也做了一個(gè)設(shè)計(jì)假設(shè)，那就是：對(duì)于一個(gè)分布式數(shù)據(jù)庫(kù)，雖然數(shù)據(jù)量很大，但是大部分操作仍然為單機(jī)操作（>80%），少部分操作才是跨機(jī)操作（<20%）。

OceanBase早期在阿里系內(nèi)部推廣時(shí)，我自己就是內(nèi)部的BD/SA，我會(huì)主動(dòng)去和每個(gè)業(yè)務(wù)的開(kāi)發(fā)人員交流，最后發(fā)現(xiàn)，雖然阿里系的業(yè)務(wù)很復(fù)雜，有電商，金融，物流，本地生活，文娛，地圖，醫(yī)療健康，但是，所有的互聯(lián)網(wǎng)to C的在線業(yè)務(wù)基本都能夠按照用戶(hù)號(hào)(user_id)做sharding來(lái)實(shí)現(xiàn)分布式。按照user_id做完sharding之后，絕大部分操作都是單用戶(hù)內(nèi)部的操作，只有非常少數(shù)的跨用戶(hù)操作。

金融行業(yè)也是類(lèi)似的，我們都用過(guò)網(wǎng)銀系統(tǒng)，大部分時(shí)間都是在讀寫(xiě)自己的賬戶(hù)，少部分時(shí)間才是做轉(zhuǎn)賬這樣的跨賬戶(hù)操作。

于是，系統(tǒng)的優(yōu)化目標(biāo)就變成：首先確保80%的單機(jī)操作沒(méi)有任何分布式相關(guān)的overhead，這部分操作能夠和單機(jī)數(shù)據(jù)庫(kù)站在同一個(gè)起點(diǎn)上PK性能，接下來(lái)才是優(yōu)化另外20%跨機(jī)操作的性能，盡可能追求極致。

單機(jī)操作的分布式相關(guān)overhead主要來(lái)自于兩個(gè)方面：一個(gè)是高可用帶來(lái)的，一個(gè)是可擴(kuò)展性帶來(lái)的。

2013年的時(shí)候當(dāng)時(shí)的支付寶Oracle DBA告訴我一個(gè)經(jīng)驗(yàn)數(shù)據(jù)，當(dāng)Oracle打開(kāi)強(qiáng)同步的時(shí)候，性能降低至少30%以上。OceanBase為了實(shí)現(xiàn)無(wú)損容災(zāi)，底層采用了基于Paxos的強(qiáng)同步方案，如果不在架構(gòu)上有所變化，肯定做不到單機(jī)高性能。我們的做法是把數(shù)據(jù)庫(kù)中的redo日志提交給異步化，這樣就避免了數(shù)據(jù)庫(kù)內(nèi)部的工作線程等待日志提交返回結(jié)果，即使網(wǎng)絡(luò)和磁盤(pán)比較差，強(qiáng)同步帶來(lái)的開(kāi)銷(xiāo)也比較小。我們用sysbench對(duì)OceanBase三臺(tái)機(jī)器強(qiáng)同步做了性能評(píng)測(cè)，結(jié)果表明Paxos強(qiáng)同步對(duì)于OceanBase的性能損失只有8%左右。這個(gè)損失是完全可以接受的，可以通過(guò)其它模塊的優(yōu)化給彌補(bǔ)回來(lái)?？蓴U(kuò)展性帶來(lái)的性能損耗主要是數(shù)據(jù)分片導(dǎo)致的，每個(gè)數(shù)據(jù)分片都需要寫(xiě)單獨(dú)的redo日志，可以簡(jiǎn)單地把每個(gè)數(shù)據(jù)分片想象成一個(gè)mini數(shù)據(jù)庫(kù)，分片越多，每臺(tái)機(jī)器上分片管理相關(guān)的分布式overhead就越大。

4.0單機(jī)分布式一體化架構(gòu)的創(chuàng)新就在于動(dòng)態(tài)單日志流。每臺(tái)機(jī)器上的每個(gè)租戶(hù)只有一個(gè)日志流，這個(gè)租戶(hù)上的所有數(shù)據(jù)分區(qū)都動(dòng)態(tài)綁定都該日志流之上，從而避免了大量日志流導(dǎo)致的overhead。另外，分區(qū)到日志流是動(dòng)態(tài)綁定的，當(dāng)系統(tǒng)增加新的服務(wù)器時(shí)，可以把分區(qū)從源端的日志流動(dòng)態(tài)解綁并重新綁定到目的端的日志流，從而實(shí)現(xiàn)分區(qū)動(dòng)態(tài)遷移。

很多人可能會(huì)想，數(shù)據(jù)庫(kù)發(fā)展了這么多年，為什么OceanBase想到了這么做，其他人都沒(méi)有想到？這里面其實(shí)也沒(méi)有什么魔法，我認(rèn)為關(guān)鍵點(diǎn)在于全球分布式數(shù)據(jù)庫(kù)很少有像OceanBase，必須抗住支付寶雙十一這樣的極限業(yè)務(wù)場(chǎng)景，并且多年被業(yè)務(wù)方“既要也要還要”給逼出來(lái)的。

業(yè)界對(duì)于可擴(kuò)展性也有不同的做法：經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)干脆就不支持可擴(kuò)展，想要分布式的時(shí)候讓?xiě)?yīng)用做改造；NewSQL系統(tǒng)的思路是把可擴(kuò)展性下沉到存儲(chǔ)層，將系統(tǒng)劃分為SQL層和存儲(chǔ)層，SQL層做功能，存儲(chǔ)層做可擴(kuò)展性，這種實(shí)現(xiàn)方式更加簡(jiǎn)單，但會(huì)帶來(lái)一個(gè)問(wèn)題，那就是每個(gè)SQL請(qǐng)求都需要一次額外的遠(yuǎn)程訪問(wèn)，即使是訪問(wèn)自己賬戶(hù)也是一樣；OceanBase的做法是先實(shí)現(xiàn)全分布式架構(gòu)1.x/2.x/3.x，再逐步演進(jìn)到單機(jī)分布式一體化架構(gòu)4.x。

單機(jī)分布式一體化架構(gòu)對(duì)開(kāi)發(fā)者意味著什么？

單機(jī)分布式一體化架構(gòu)看起來(lái)什么都行，既能做單機(jī)，又能分布式，現(xiàn)階段的側(cè)重點(diǎn)到底是什么？我認(rèn)為一方面，單機(jī)分布式一體化架構(gòu)是一種技術(shù)的升維，對(duì)于用戶(hù)和開(kāi)發(fā)者比之前更加友好，會(huì)逐步成為主流選擇。另一方面，新技術(shù)肯定有一段成熟期，尤其是用戶(hù)體驗(yàn)和生態(tài)一開(kāi)始不如單機(jī)數(shù)據(jù)庫(kù)，需要一段時(shí)間來(lái)打磨。短期來(lái)看，單機(jī)分布式一體化架構(gòu)對(duì)于開(kāi)發(fā)者的價(jià)值在于如下幾個(gè)方面：

1) 極大地降低分布式數(shù)據(jù)庫(kù)的門(mén)檻。原先的NewSQL單機(jī)性能太差，業(yè)界主流的NewSQL系統(tǒng)，比如CockroachDB和YugabyteDB的單機(jī)sysbench性能只有MySQL的1/5 ~ 1/10。隨著單機(jī)分布式一體化數(shù)據(jù)庫(kù)逐步成熟，這類(lèi)NewSQL會(huì)被逐步取代，我也確實(shí)看到很多用戶(hù)把原先使用的NewSQL系統(tǒng)換成OceanBase來(lái)實(shí)現(xiàn)降本增效。

2) 解決用戶(hù)從小到大擴(kuò)展的需求。我在和很多中小企業(yè)溝通的過(guò)程中發(fā)現(xiàn)，大多數(shù)中小企業(yè)都是很有追求的，雖然目前階段他們的數(shù)據(jù)量不大，單機(jī)數(shù)據(jù)庫(kù)也能支撐，但是他們也對(duì)未來(lái)幾年的業(yè)務(wù)發(fā)展充滿(mǎn)期待，不希望等到業(yè)務(wù)發(fā)展之后再修改應(yīng)用更換數(shù)據(jù)庫(kù)，他們?cè)敢庖婚_(kāi)始就選擇單機(jī)分布式一體化數(shù)據(jù)庫(kù)。

單機(jī)分布式一體化數(shù)據(jù)庫(kù)最終會(huì)不會(huì)取代單機(jī)數(shù)據(jù)庫(kù)？我認(rèn)為從技術(shù)趨勢(shì)上來(lái)看會(huì)逐步替代，但是整個(gè)過(guò)程比較長(zhǎng)，需要很長(zhǎng)一段時(shí)間。

聊聊核心技術(shù)原理

單機(jī)分布式一體化架構(gòu)的核心技術(shù)是動(dòng)態(tài)單日志流。為了真正實(shí)現(xiàn)一體化，需要解決如下幾個(gè)關(guān)鍵的技術(shù)問(wèn)題：

應(yīng)用透明：從單機(jī)到多機(jī)不需要應(yīng)用做改造，需要客戶(hù)端支持動(dòng)態(tài)路由技術(shù)，當(dāng)后端數(shù)據(jù)庫(kù)發(fā)生分區(qū)遷移時(shí)，能夠動(dòng)態(tài)路由到目的服務(wù)器上。另外，不管是單機(jī)還是分布式，需要支持全部的SQL功能。

單機(jī)操作：單機(jī)只有一個(gè)redo日志，單機(jī)事務(wù)寫(xiě)redo日志的方式與經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)比較像。OceanBase還做了一項(xiàng)技術(shù)創(chuàng)新，經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)采用的是B+樹(shù)存儲(chǔ)引擎，OceanBase的做法是將B+樹(shù)數(shù)據(jù)分塊的思路融入到LSM樹(shù)存儲(chǔ)引擎，一方面能夠像LSM樹(shù)一樣具備高壓縮能力，并把熱點(diǎn)數(shù)據(jù)放在內(nèi)存中提供服務(wù)，另一方面通過(guò)類(lèi)似B+樹(shù)的數(shù)據(jù)分塊思路來(lái)減少LSM樹(shù)的寫(xiě)入放大。最終使得OceanBase 4.1即使在三臺(tái)機(jī)器做強(qiáng)同步的情況之下無(wú)論是單機(jī)的性能還是存儲(chǔ)成本都好于MySQL 8.0。

跨機(jī)操作：跨機(jī)操作通過(guò)底層的分布式架構(gòu)提供，上層的SQL功能不受影響。如果事務(wù)只涉及一臺(tái)機(jī)器，走單機(jī)事務(wù)；如果涉及多臺(tái)機(jī)器，通過(guò)兩階段提交實(shí)現(xiàn)分布式事務(wù)。另外，通過(guò)分布式、并行、異步化等技術(shù)手段盡可能地優(yōu)化性能。

遷移代價(jià)：遷移操作后臺(tái)進(jìn)行，實(shí)際運(yùn)行時(shí)一般會(huì)對(duì)遷移限速。假設(shè)遷移最大限速200MB/s，占用萬(wàn)兆網(wǎng)卡20%左右的帶寬，遷移操作只是拷貝數(shù)據(jù)，CPU占用比較少，只要不是在雙十一零點(diǎn)這樣的極端場(chǎng)景，后臺(tái)遷移都不會(huì)影響前臺(tái)的在線交易請(qǐng)求。假設(shè)數(shù)據(jù)量為1TB，遷移時(shí)間為1TB / 200MB/s = 5000s，大約1個(gè)半小時(shí)。

再聊聊實(shí)際效果

今年3月份我們?cè)陂_(kāi)發(fā)者大會(huì)分享了OceanBase的性能數(shù)據(jù)，過(guò)去也在TPC-C測(cè)試展示了OceanBase的擴(kuò)展能力：

單機(jī)性能：32C場(chǎng)景，OceanBase 4.1在sysbench所有場(chǎng)景(point select/read only/write only/read write/insert/update)都好于MySQL 8.0，在最為綜合的readwrite場(chǎng)景OceanBase 4.1比MySQL 8.0高39%。

公有云性?xún)r(jià)比：采用4C16G CPU，MySQL部署主備兩臺(tái)機(jī)器，OceanBase部署三臺(tái)機(jī)器，兩臺(tái)為全功能副本，一臺(tái)為日志副本。無(wú)論存儲(chǔ)多大，從100GB，300GB，500GB到1TB，OceanBase 4.1在阿里云和AWS的性?xún)r(jià)比都好于MySQL 8.0，且存儲(chǔ)容量越大，OceanBase的優(yōu)勢(shì)越明顯。整體上看，同樣的性能，相比云上的MySQL，OceanBase可以幫助用戶(hù)節(jié)省18.57%到42.05%整體擁有成本，且OceanBase還有更好的三副本無(wú)損容災(zāi)能力。

TPC-C擴(kuò)展性：OceanBase參加過(guò)兩次TPC-C測(cè)試，最后一次測(cè)試中采用了超過(guò)1500臺(tái)機(jī)器，TPC-C的workload里面有10%~15%分布式事務(wù)，本地事務(wù)85%-90%，與真實(shí)場(chǎng)景比較接近。通過(guò)TPC-C官網(wǎng)公布的報(bào)告可以看到，OceanBase的性能基本能夠做到隨著服務(wù)器的增加而線性增長(zhǎng)。

一些關(guān)鍵問(wèn)題探討

當(dāng)然，單機(jī)分布式一體化架構(gòu)也不是完美的，有一些問(wèn)題仍然值得探討，也希望未來(lái)和開(kāi)發(fā)者用戶(hù)做更深入的探討：

1) 分布式到單機(jī) vs 單機(jī)到分布式

到底是選擇分布式到單機(jī)（先做分布式再做單機(jī)），還是單機(jī)到分布式（先做單機(jī)再做分布式）的技術(shù)路線？我認(rèn)為只有分布式到單機(jī)才是可行的。因?yàn)榉植际降募夹g(shù)難度比單機(jī)要高一個(gè)數(shù)量級(jí)，再加上單機(jī)的場(chǎng)景是主流場(chǎng)景。

從ROI的角度看，不太可能出現(xiàn)一個(gè)主流場(chǎng)景的單機(jī)數(shù)據(jù)庫(kù)，在已經(jīng)有大量技術(shù)債的前提之下，舍棄部分主流場(chǎng)景的支持，花費(fèi)更高一個(gè)量級(jí)的代價(jià)去支持一個(gè)規(guī)模更小的高端場(chǎng)景。這也是為什么所有的商業(yè)案例中，只有先做高端，再做低端的降維做法才能成功。

技術(shù)創(chuàng)新也往往在外部才會(huì)發(fā)生，比如電動(dòng)車(chē)領(lǐng)域的Tesla，分布式技術(shù)有點(diǎn)像電動(dòng)車(chē)的電池，并不是燃油汽車(chē)廠商在內(nèi)部實(shí)現(xiàn)了電動(dòng)化的變革，而是一個(gè)外部的Tesla先做好高端的Model X/Model S，再逐步通過(guò)大眾車(chē)Model 3去占領(lǐng)主流市場(chǎng)。

2) 全分布式場(chǎng)景

單機(jī)分布式一體化架構(gòu)有一個(gè)假設(shè)，那就是：在分布式數(shù)據(jù)庫(kù)中，大部分請(qǐng)求仍然是單機(jī)讀寫(xiě)，少部分請(qǐng)求才是跨機(jī)讀寫(xiě)。如果這個(gè)假設(shè)不成立，也就是大部分請(qǐng)求都是跨機(jī)讀寫(xiě)，那么，分布式數(shù)據(jù)庫(kù)性能的擴(kuò)展比會(huì)大幅下降。怎么看待這個(gè)問(wèn)題？

我認(rèn)為可以進(jìn)一步把全分布式的場(chǎng)景分為兩類(lèi)：

一類(lèi)是OLAP場(chǎng)景，OLAP場(chǎng)景單個(gè)用戶(hù)的數(shù)據(jù)量都很大，且維度會(huì)比較復(fù)雜，這個(gè)場(chǎng)景確實(shí)很難做到本地化。但是，這個(gè)場(chǎng)景的并發(fā)量很小，優(yōu)化的關(guān)鍵點(diǎn)在于盡可能地把所有機(jī)器的資源通過(guò)并行化、向量化等手段盡可能地利用起來(lái)。每次運(yùn)行的SQL都比較大，一次額外的網(wǎng)絡(luò)請(qǐng)求開(kāi)銷(xiāo)在整個(gè)SQL語(yǔ)句執(zhí)行過(guò)程中占比很少。

另外一類(lèi)是OLTP場(chǎng)景，假設(shè)某個(gè)OLTP業(yè)務(wù)全部都是跨用戶(hù)轉(zhuǎn)賬操作，那么，如果數(shù)據(jù)量比較小，單機(jī)分布式一體化架構(gòu)可以只部署單機(jī)，沒(méi)有額外的分布式開(kāi)銷(xiāo)；如果數(shù)據(jù)量比較大，必須采用多機(jī)部署，那么，性能的擴(kuò)展比雖然會(huì)大幅下降，但是，這是業(yè)務(wù)無(wú)法避免的，這種場(chǎng)景下單機(jī)分布式一體化數(shù)據(jù)庫(kù)相比其它的shared nothing數(shù)據(jù)庫(kù)在架構(gòu)上也沒(méi)有劣勢(shì)。

生成海報(bào)

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評(píng)論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個(gè)人觀點(diǎn)，與極客網(wǎng)無(wú)關(guān)。文章僅供讀者參考，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。