?現(xiàn)在國產(chǎn)數(shù)據(jù)庫據(jù)說已經(jīng)突破300種了，廠家也有近200家，這些數(shù)據(jù)庫產(chǎn)品中，大多數(shù)都是分布式數(shù)據(jù)庫。不僅僅是中國，其實(shí)這些年國外的新數(shù)據(jù)庫產(chǎn)品中，分布式數(shù)據(jù)庫也占了很大的比例。這是為什么呢？分布式數(shù)據(jù)庫更容易開發(fā)嗎？還是用戶更需要分布式數(shù)據(jù)庫呢？

實(shí)際上我并不是用戶，用戶才是對這個(gè)問題最有發(fā)言權(quán)的。他們了解自己的應(yīng)用的痛點(diǎn)，提出的需求往往都是比較現(xiàn)實(shí)的。不過我們常年和數(shù)據(jù)庫的用戶在一起摸爬滾打，對用戶的需求還是有所了解的。

大概7、8年前吧，一個(gè)互聯(lián)網(wǎng)公司想研發(fā)一款商用數(shù)據(jù)庫產(chǎn)品，在一個(gè)聚會(huì)上，大家討論客戶需要什么樣的數(shù)據(jù)庫。我總結(jié)了三個(gè)詞：“簡單、穩(wěn)定、安全”，隨后根據(jù)這三個(gè)詞擴(kuò)展為能夠組建大型服務(wù)器集群，利用分布式架構(gòu)可以十分方便的動(dòng)態(tài)擴(kuò)展，無需備份，能夠?qū)崿F(xiàn)自動(dòng)容災(zāi)。同時(shí)數(shù)據(jù)庫可以永遠(yuǎn)在線，不會(huì)宕機(jī)，并且永不出錯(cuò)，于是大家決定開發(fā)一款分布式數(shù)據(jù)庫。

其實(shí)要實(shí)現(xiàn)最后兩點(diǎn)是十分困難的，一個(gè)BUG足以讓整個(gè)集群宕機(jī)，甚至出現(xiàn)數(shù)據(jù)錯(cuò)誤或者丟失。大概十年前，某國產(chǎn)分布式數(shù)據(jù)庫就出現(xiàn)過分區(qū)表數(shù)據(jù)寫錯(cuò)分區(qū)的BUG，導(dǎo)致部分?jǐn)?shù)據(jù)丟失。

根據(jù)上述的需求，對目標(biāo)數(shù)據(jù)庫產(chǎn)品提出的四個(gè)要求，一個(gè)是無限容量，無論客戶有多大的表，都能夠應(yīng)對自如，訪問快速是能夠提供高并發(fā)的快速相應(yīng)，永不停服是能夠自動(dòng)感知故障，自動(dòng)隔離故障，從而確保7*24穩(wěn)定服務(wù)。同時(shí)通過強(qiáng)一致性保障，異地多分?jǐn)?shù)據(jù)來確保數(shù)據(jù)庫的安全可靠。

數(shù)年過去了，后來和這個(gè)產(chǎn)品項(xiàng)目組的朋友交流，有個(gè)朋友說，當(dāng)時(shí)把數(shù)據(jù)庫想的有點(diǎn)簡單了。實(shí)際上這個(gè)目標(biāo)目前依然還是我們的數(shù)據(jù)庫廠商的追求目標(biāo)，可能已經(jīng)離得更近了，但是還是無法觸摸到這個(gè)目標(biāo)。這是因?yàn)閿?shù)據(jù)庫系統(tǒng)太復(fù)雜了，應(yīng)用場景太復(fù)雜了，IT基礎(chǔ)設(shè)施的可靠性也不像我們想象的那么強(qiáng)大，再加上我們?nèi)祟惖倪壿嬎季S能力太有局限性了。單單通過基礎(chǔ)架構(gòu)上的革命，想要實(shí)現(xiàn)我們設(shè)定的目標(biāo)，是遠(yuǎn)遠(yuǎn)不夠的。必須把IT基礎(chǔ)設(shè)施看成是數(shù)據(jù)庫的一部分，統(tǒng)一在核心代碼中進(jìn)行管理，才能真正的做到為用戶屏蔽大部分硬件故障。

大概是2017年吧，我和Yellowbrick的Nile交流的時(shí)候，他認(rèn)為分布式數(shù)據(jù)庫太復(fù)雜了，只有提供完全工程化的一體機(jī)才能確保他們的分布式數(shù)據(jù)庫高效、穩(wěn)定的運(yùn)行，因此他們只準(zhǔn)備出數(shù)據(jù)庫一體機(jī)，并不準(zhǔn)備提供通用軟件讓客戶自建數(shù)據(jù)庫系統(tǒng)。當(dāng)時(shí)我對這種商業(yè)模式提出了疑問，這種昂貴的軟硬一體產(chǎn)品是不是能夠獲得商業(yè)上的成功。在推出類似一體化解決方案的廠商中，目前來看只有兩個(gè)成功者，Oracle和Teradata，GreenPlum算半個(gè)成功者，SAP的HANA最終也只能向通用硬件妥協(xié)才能得到市場的認(rèn)可。

幾年前我們想要達(dá)成的目標(biāo)中，“更易于使用”這一點(diǎn)實(shí)際上至今仍然沒有達(dá)成。雖然說從整體架構(gòu)上的高可用性，冗余設(shè)計(jì)理論上能夠屏蔽部分硬件故障，但是這僅僅限于宕機(jī)，硬件完全損壞這種極端故障。對于忽好忽壞，忽快忽慢，性能毛刺這種問題的自動(dòng)容忍需要通過在數(shù)據(jù)庫核心代碼中做大量的處理，甚至優(yōu)化OS底層代碼才能夠真正實(shí)現(xiàn)，而我們的絕大多數(shù)分布式數(shù)據(jù)庫廠商十分流氓的把這些問題都?xì)w結(jié)為和數(shù)據(jù)庫無關(guān)的IT基礎(chǔ)設(shè)施問題，需要用戶自己去優(yōu)化IT基礎(chǔ)設(shè)施來解決這些問題。這實(shí)際上是把一些運(yùn)維上相對簡單的比較明顯的故障都處理了，而把運(yùn)維中最難解決的問題全部交給用戶了。

和集中式數(shù)據(jù)庫相比，現(xiàn)在的絕大多數(shù)分布式數(shù)據(jù)庫對IT基礎(chǔ)設(shè)施可靠性的要求并不是更低了，而是更高了。因?yàn)榇蟛糠址植际綌?shù)據(jù)庫的核心代碼中只是考慮了對SQL的實(shí)現(xiàn)和數(shù)據(jù)的存儲(chǔ)，并沒有能夠從底層自動(dòng)感知存在的各種對數(shù)據(jù)庫運(yùn)行穩(wěn)定性、性能、并發(fā)能力有極大影響的隱患故障，因此也無法在代碼中對這些問題從數(shù)據(jù)庫的角度進(jìn)行處理，從而實(shí)現(xiàn)自動(dòng)規(guī)避問題。在一些大廠的分布式數(shù)據(jù)庫產(chǎn)品的實(shí)現(xiàn)算法和代碼中，我們看到了不少這方面的容錯(cuò)設(shè)計(jì)，而對于大部分小廠產(chǎn)品來說，可能開發(fā)者都沒有很好的去考慮過這個(gè)問題。

分布式數(shù)據(jù)庫廠商總是喜歡用互聯(lián)網(wǎng)大廠的成功實(shí)踐來證明分布式數(shù)據(jù)庫的能力與使用分布式數(shù)據(jù)庫的必要性。很多數(shù)據(jù)庫廠商都喜歡說自己的產(chǎn)品設(shè)計(jì)靈感來自于谷歌的Spanner。實(shí)際上，我以前對Spanner沒有做什么分析研究。為了研究分布式數(shù)據(jù)庫，我稍微了解了一下他們的老祖宗Spanner。大家很有興趣討論Spanner實(shí)現(xiàn)GTM的True Time，說谷歌使用了昂貴的銫原子鐘來作為授時(shí)中心，所以很昂貴。聽到這里我大概就了解了他實(shí)際上并不太了解谷歌TRUE Time的實(shí)現(xiàn)方式。谷歌的全球數(shù)據(jù)中心是采用GPS授時(shí)的，銫原子鐘只是一個(gè)備胎，當(dāng)GPS授時(shí)失敗時(shí)接管而已。實(shí)際上保證谷歌Spanner“穩(wěn)定的慢”的并不是銫原子鐘，而是谷歌在廣域網(wǎng)上巨大的投資和強(qiáng)大的優(yōu)化能力，確保網(wǎng)絡(luò)延時(shí)低于7ms是谷歌Spanner的成功密碼。他們的TRUE Time不是一個(gè)確定的時(shí)間，而是一個(gè)7毫秒的時(shí)間區(qū)間。能夠具備這種強(qiáng)大的廣域網(wǎng)優(yōu)化能力的企業(yè)是屈指可數(shù)的，能夠花得起這個(gè)錢的企業(yè)更是鳳毛麟角。

因此SPANNER只能是一個(gè)膜拜的對象，而不可能飛入尋常百姓家了。谷歌的這種超大型分布式數(shù)據(jù)庫是一個(gè)昂貴的工程化的產(chǎn)物，并不能作為一個(gè)通用的數(shù)據(jù)庫產(chǎn)品去銷售，這也是前些年驚呼狼來了的數(shù)據(jù)庫屆并沒有看到谷歌把Oracle趕下王座的主要原因。

因?yàn)榉植际綌?shù)據(jù)庫的IT基礎(chǔ)設(shè)施比集中式數(shù)據(jù)庫更為復(fù)雜，因此分布式數(shù)據(jù)庫需要有大量的基礎(chǔ)數(shù)據(jù)探測和分析能力，從而發(fā)現(xiàn)IT基礎(chǔ)設(shè)施中主機(jī)、網(wǎng)絡(luò)、存儲(chǔ)、時(shí)間、資源、負(fù)載等的一系列變化，并且隨時(shí)針對出現(xiàn)的異常隱患提前進(jìn)行處置，這樣才能實(shí)現(xiàn)真正的無需運(yùn)維人員過多干預(yù)的高效自治運(yùn)行。而實(shí)際上我們的分布式數(shù)據(jù)庫廠商大多數(shù)在這方面的能力并不足，甚至很多數(shù)據(jù)庫研發(fā)人員對網(wǎng)絡(luò)，OS的核心知之甚少。這樣就讓分布式數(shù)據(jù)庫成為了一個(gè)工程化的產(chǎn)品，不是開箱即用的，而是需要在IT基礎(chǔ)設(shè)施上做大量的工程化施工和優(yōu)化，這樣就讓分布式數(shù)據(jù)庫產(chǎn)品的應(yīng)用與運(yùn)維變得更復(fù)雜了。

我也和很多分布式數(shù)據(jù)庫的使用者做過交流，他們普遍都遇到過一些運(yùn)行問題。不像集中式數(shù)據(jù)庫出問題后能夠有一定的思路去分析和解決。實(shí)在不行，數(shù)據(jù)庫重啟一下，服務(wù)器重啟一下也就解決問題了。大數(shù)據(jù)分布式數(shù)據(jù)庫出現(xiàn)故障的時(shí)候，運(yùn)維人員是束手無策的，產(chǎn)品手冊上并沒有告訴你遇到這樣的問題是不是關(guān)閉一個(gè)故障節(jié)點(diǎn)就能解決問題，還是去殺掉一些會(huì)話就能恢復(fù)。因此運(yùn)維人員只能看這出問題的系統(tǒng)，等著故障消失，或者等著業(yè)務(wù)高峰快點(diǎn)過去。

開發(fā)出一個(gè)分布式數(shù)據(jù)庫并不是太難的事情，國內(nèi)大量涌現(xiàn)的分布式數(shù)據(jù)庫廠商就已經(jīng)說明了這個(gè)問題了。不過要做好一款分布式數(shù)據(jù)庫產(chǎn)品并不容易，要做出一款開箱即用，運(yùn)維簡便的分布式數(shù)據(jù)庫產(chǎn)品就更不容易了。我想，目前的大多數(shù)分布式數(shù)據(jù)庫產(chǎn)品可能還只是處于成熟度曲線的前期，只有當(dāng)我們的分布式數(shù)據(jù)庫產(chǎn)商能夠全面感知數(shù)據(jù)庫與IT基礎(chǔ)設(shè)施的各種變化，并把IT基礎(chǔ)設(shè)施與數(shù)據(jù)庫本身的風(fēng)險(xiǎn)處置都納入到核心代碼中，讓異常處置能力更強(qiáng)大了，分布式數(shù)據(jù)庫產(chǎn)品才能成為只有大企業(yè)才玩得轉(zhuǎn)的工程化產(chǎn)品變成通用型的老少咸宜的大路貨了。?