現在國產資料庫據說已經突破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基礎設施與資料庫本身的風險處置都納入到核心程式碼中，讓異常處置能力更強大了，分散式資料庫產品才能成為只有大企業才玩得轉的工程化產品變成通用型的老少咸宜的大路貨了。