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

實際上我并不是用戶，用戶才是對這個問題最有發言權的。他們了解自己的應用的痛點，提出的需求往往都是比較現實的。不過我們常年和數據庫的用戶在一起摸爬滾打，對用戶的需求還是有所了解的。

大概7、8年前吧，一個互聯網公司想研發一款商用數據庫產品，在一個聚會上，大家討論客戶需要什么樣的數據庫。我總結了三個詞：“簡單、穩定、安全”，隨后根據這三個詞擴展為能夠組建大型服務器集群，利用分布式架構可以十分方便的動態擴展，無需備份，能夠實現自動容災。同時數據庫可以永遠在線，不會宕機，并且永不出錯，于是大家決定開發一款分布式數據庫。

其實要實現最后兩點是十分困難的，一個BUG足以讓整個集群宕機，甚至出現數據錯誤或者丟失。大概十年前，某國產分布式數據庫就出現過分區表數據寫錯分區的BUG，導致部分數據丟失。

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

數年過去了，后來和這個產品項目組的朋友交流，有個朋友說，當時把數據庫想的有點簡單了。實際上這個目標目前依然還是我們的數據庫廠商的追求目標，可能已經離得更近了，但是還是無法觸摸到這個目標。這是因為數據庫系統太復雜了，應用場景太復雜了，IT基礎設施的可靠性也不像我們想象的那么強大，再加上我們人類的邏輯思維能力太有局限性了。單單通過基礎架構上的革命，想要實現我們設定的目標，是遠遠不夠的。必須把IT基礎設施看成是數據庫的一部分，統一在核心代碼中進行管理，才能真正的做到為用戶屏蔽大部分硬件故障。

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

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

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

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

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

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

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

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