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

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

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

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

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

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

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

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

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

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

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

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

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

開發(fā)出一個分布式數(shù)據(jù)庫并不是太難的事情，國內(nèi)大量涌現(xiàn)的分布式數(shù)據(jù)庫廠商就已經(jīng)說明了這個問題了。不過要做好一款分布式數(shù)據(jù)庫產(chǎ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)險處置都納入到核心代碼中，讓異常處置能力更強大了，分布式數(shù)據(jù)庫產(chǎn)品才能成為只有大企業(yè)才玩得轉(zhuǎn)的工程化產(chǎn)品變成通用型的老少咸宜的大路貨了。?