分散式資料庫怎樣才能叫好又賣座

這些年分散式資料庫的熱度很高，大家都在談分散式資料庫，很多人認為未來的資料庫必須是分散式的，甚至金融行業在一個行業標準裡把資料庫型別規定為核心系統必須用分散式資料庫。

不過在實際的應用場景上看，實際應用環境中，集中式資料庫還是用得比較多，哪怕在現在的去O浪潮中，用於替換Oracle資料庫的大多數還是集中式資料庫。分散式資料庫似乎有些叫好但是不賣座，為什麼會出現這種情況呢?

國內的分散式資料庫產業其實起步是比較晚的，大多數都是最近10年甚至最近5、6年才開始發展的，其成熟度當然沒有集中式資料庫高。甚至剛剛開始的時候，分散式資料庫在功能上遠遠不如集中式資料庫。早期的一些以SQL代理+MYSQL例項的分散式資料庫實際上並不是一個特別完整的資料庫產品，而只是一個工程化的東西。多表關聯，複雜的統計函式，視窗函式等都不支援，特別是不支援儲存過程，這讓資料庫的通用性大打折扣。應用開發商在使用這種分散式資料庫的時候感到十分難受。

既然分散式資料庫的功能還不如集中式資料庫，那麼近些年分散式資料庫為什麼還發展得這麼快呢?實際上分散式資料庫的發展是受到網際網路和物聯網應用發展的影響而發展起來的。這些業務的特點是資料量大，高併發，小交易，簡單業務。這種業務實際上是天生比較適合分散式資料庫的場景的。功能上簡單點沒關係，但是架不住我可以橫向擴充套件，能夠高併發寫入資料。

不過這種場景終歸是有限的，資料庫市場佔主流的還是管理系統類的業務，比如OA,財務，營銷，ERP等。這些場景併發量雖然比較高，但是還高不到不用分散式資料庫就搞不定的地步。另外一方面，這些業務系統的業務邏輯比較複雜，並且大部分業務邏輯都是透過SQL實現的，因此對複雜SQL的效能要求比較高。再加上開發團隊的水平也無法和網際網路企業相比，你給僅僅會用JAVA框架，寫一些SQL語句的碼農們制定一套編碼的清規戒律，就十分困難了。可能有些朋友不太認可這個觀點，認為應用開發不應該過度依賴於資料庫，而是應該與資料庫無關。既然這樣，那麼我們還費什麼勁來做資料庫選型呢?把錢投在研發上不就行了。事實上，不同的企業有著不同的特點，要求企業的資訊系統建設適應資料庫產品，是完全沒有道理的。

再加上分散式資料庫部署的門檻過高，動輒三五個節點甚至十多個節點，也會讓一些企業望而生畏。部署環境複雜必然帶來運維的複雜性，如果文件做的再差點，原廠服務我想肯定是指望不上的，第三方服務生態更是一塌糊塗，那麼使用者肯定寧可使用相對簡單的集中式資料庫也不會選擇分散式資料庫了。

分散式資料庫想要在這樣的場景中獲得較好的應用，不能總是吹噓自己的TPCC有多高，支援的資料量有多大，更重要的是把自己的產品做好。首先把集中式資料庫有的功能都實現了，在功能上沒有短板，然後再談分散式資料庫的可擴充套件性和高可用能力吧。如果分散式資料庫的功能與集中式資料庫相當，運維便捷性也並不差，可擴充套件性與效能還優於集中式資料庫，價格方面也不會太貴，那麼分散式資料庫叫好又叫座也就不難了。

總結一下，讓分散式資料庫叫好又叫座的根本因素還是在我們的資料庫廠商，他們是否真正傾聽客戶的心聲，根據客戶的需求與應用場景的需求來設計與研發產品。在功能上能夠滿足客戶的全方位需要，而不是附贈給客戶一堆開發規範;在易用性上可以讓客戶低門檻上手，便捷運維;在文件上豐富全面，讓使用者能夠看著文件用好資料庫產品;在生態建設上構建完善的服務體系，包括知識庫、售後服務網站、第三方服務能力等。

我想，不管哪個資料庫企業，能把這些做好了，就不怕客戶不買賬了，這比花多少錢在營銷上都要有效得多。