數(shù)據(jù)庫的歷史已經(jīng)有50多年了，似乎這50年里數(shù)據(jù)庫從一個輪回走向了另外一個輪回。最初的數(shù)據(jù)庫世界是碎片化的，每個硬件廠商都有自己的數(shù)據(jù)庫系統(tǒng)，我用過的最古老的數(shù)據(jù)庫系統(tǒng)是一臺ICL小型機(jī)上的記錄式數(shù)據(jù)庫系統(tǒng)，用COBOL來讀寫。

隨著計算機(jī)網(wǎng)絡(luò)的發(fā)展，特別是互聯(lián)網(wǎng)的普及，數(shù)據(jù)庫被幾大通用關(guān)系型數(shù)據(jù)庫壟斷了，數(shù)據(jù)庫世界有被Oracle等大廠一統(tǒng)天下的趨勢。有幾年，我甚至認(rèn)為關(guān)系型數(shù)據(jù)庫已經(jīng)沒有什么可以創(chuàng)新的了。不過這些年數(shù)據(jù)庫領(lǐng)域的發(fā)展讓我這個十分淺陋的想法變得如此的可笑。

隨著企業(yè)信息化對數(shù)據(jù)處理要求的不斷提高，我們有太多種類的數(shù)據(jù)需要處理了。應(yīng)用的類型也是豐富多彩。某些應(yīng)用程序需要同時訪問用于存儲結(jié)構(gòu)化數(shù)據(jù)的關(guān)系數(shù)據(jù)庫(例如 PostgreSQL)、用于內(nèi)容緩存的內(nèi)存數(shù)據(jù)庫(例如 Redis)、存儲海量物聯(lián)網(wǎng)數(shù)據(jù)的時間序列數(shù)據(jù)庫和用于分析的數(shù)據(jù)倉庫。現(xiàn)在僅在DB-ENGINES上就收錄了352種數(shù)據(jù)庫，其中147種是關(guān)系型數(shù)據(jù)庫(這些關(guān)系型數(shù)據(jù)庫中，很多還是多模數(shù)據(jù)庫)。

不同業(yè)務(wù)類別的企業(yè)，也可能更傾向于選擇某種不同的數(shù)據(jù)庫。比如銀行或金融機(jī)構(gòu)可能會選擇 Oracle 或 PostgreSQL 等關(guān)系 DBMS 來確保其結(jié)構(gòu)化數(shù)據(jù)的 ACID事務(wù);運(yùn)營大型在線多人游戲的互聯(lián)網(wǎng)服務(wù)商更喜歡使用 Redis 等鍵值 NoSQL 數(shù)據(jù)庫；

社交媒體分析企業(yè)通常會選擇圖數(shù)據(jù)庫;而物聯(lián)網(wǎng) 企業(yè)會選擇時間序列數(shù)據(jù)庫來支持其傳感器或網(wǎng)絡(luò)數(shù)據(jù)。這并不是完全出于應(yīng)用特點(diǎn)的選擇，而更多的是習(xí)慣與歷史傳承。對于一個企業(yè)來說，選對了數(shù)據(jù)庫，那么你的信息系統(tǒng)建設(shè)就成功了一小半了。

前幾天我在REDDIT上參與了一個帖子，有個朋友問了一個數(shù)據(jù)庫選型的問題，他在做一個市場項目，需要管理用戶、身份、產(chǎn)品、評論、點(diǎn)贊、標(biāo)簽、搜索等功能。他在PostgreSQL和Mongodb之間彷徨，希望得到大家的幫助。

如果按照應(yīng)用場景來劃分，這個系統(tǒng)主要是一個關(guān)系型數(shù)據(jù)為核心的系統(tǒng)，不過也會涉及到一部分文檔數(shù)據(jù)。從架構(gòu)師設(shè)計上來看，習(xí)慣于關(guān)系型數(shù)據(jù)庫的團(tuán)隊很可能會選擇PostgreSQL，再加上ES或者M(jìn)ongodb來存儲一些文檔類的數(shù)據(jù)。

而如果是一個受過比較多的互聯(lián)網(wǎng)思維熏陶的設(shè)計師，有可能會直接選擇Mongodb單一的解決方案來做這個項目了。當(dāng)然做出任何一種選擇，只要團(tuán)隊對數(shù)據(jù)庫以及相關(guān)的開發(fā)是擅長的，那么哪怕遇到一些問題，也是能解決的。不過如果一個對Mongodb知之甚少的團(tuán)隊，貿(mào)然選擇Mongodb，那么可能他們會吃很多苦頭。

實(shí)際上，在早期我們的數(shù)據(jù)庫選型并沒有那么麻煩，因為關(guān)系型數(shù)據(jù)庫主要就是做關(guān)系處理的，文檔數(shù)據(jù)庫也只是專注于文檔處理。而隨著數(shù)據(jù)庫產(chǎn)業(yè)的內(nèi)卷，一個功能單一的數(shù)據(jù)庫產(chǎn)品可能可以在開源社區(qū)獲得青睞，但是無法在商業(yè)上獲得成功。從DB-ENGINES上可以看到，排名前八位的數(shù)據(jù)庫無一不是多模數(shù)據(jù)庫。

經(jīng)過多年的發(fā)展，文檔數(shù)據(jù)庫MongoDB也變成了一種多模數(shù)據(jù)庫，甚至在一些簡單的事務(wù)的支持上也相對不錯。如果你的團(tuán)隊喜歡node.js,熟練掌握Mongoose組件，那么這個項目使用MongoDB也沒啥大問題。

不過從另外一個方面來說，PostgreSQL從出生起就是一個學(xué)院派的數(shù)據(jù)庫，其多模數(shù)據(jù)庫特性依然十分明顯。在內(nèi)卷和碎片化的數(shù)據(jù)庫領(lǐng)域演進(jìn)過程中，PostgreSQL在文檔數(shù)據(jù)支持方面也變得越來越出色，MongoDB能做的很多工作，PG做的也不賴。這也是目前我們出現(xiàn)數(shù)據(jù)庫選擇性障礙的主要因素之一。

如果這個項目今后的用戶不大，那么從數(shù)據(jù)庫選擇的角度上看，選任何一個都不算錯誤，選哪個要看開發(fā)團(tuán)隊對這兩種數(shù)據(jù)庫的掌握和熟悉程度了。不過如果這個項目最后要服務(wù)的用戶群體十分巨大，那么這個選擇將十分重要，這決定了今后項目開發(fā)的難度。如果這個項目今后的交易型功能十分復(fù)雜，那么如果選擇MongoDB，開發(fā)團(tuán)隊將會遇到很多mongoDB原生態(tài)功能無法支撐的處理。

雖然如此，只要研發(fā)團(tuán)隊夠強(qiáng)大，這些僅僅是會成為障礙，并不能成為決定項目成敗的關(guān)鍵。數(shù)據(jù)庫搞不定的事情，通過應(yīng)用代碼去搞定，就不會有任何問題了。

前兩年我有一個客戶上一個新系統(tǒng)，當(dāng)時整體框架設(shè)計就是采用微服務(wù)，于是引入了領(lǐng)域建模，將整個系統(tǒng)劃分為近30個領(lǐng)域。原本計劃應(yīng)用采用阿里云的微服務(wù)框架，數(shù)據(jù)庫使用RDS。不過開發(fā)過程中，研發(fā)團(tuán)隊發(fā)現(xiàn)開發(fā)人員能力不足，于是數(shù)據(jù)庫仍然恢復(fù)使用Oracle，并將30個領(lǐng)域數(shù)據(jù)庫合并為6個Oracle數(shù)據(jù)庫。

這種臨陣退縮導(dǎo)致了開發(fā)團(tuán)隊在微服務(wù)架構(gòu)下的大撤退，雖然應(yīng)用服務(wù)仍然按照30個領(lǐng)域跑在容器里，不過大量的業(yè)務(wù)邏輯依然下沉到了數(shù)據(jù)庫里。

因為微服務(wù)架構(gòu)下的IT技術(shù)政策不允許使用Oracle dblink，開發(fā)團(tuán)隊又沒有能力將很多數(shù)據(jù)關(guān)聯(lián)全部拆分為接口和服務(wù)調(diào)用，于是天才的架構(gòu)師想出了數(shù)據(jù)復(fù)制，在6套數(shù)據(jù)庫之間創(chuàng)建了上百條復(fù)制鏈路，確保每個微服務(wù)都不跨庫訪問。我想這樣的披著微服務(wù)外衣的集中式架構(gòu)的應(yīng)用系統(tǒng)，今后就是運(yùn)維的災(zāi)難。

在這個數(shù)據(jù)庫產(chǎn)業(yè)碎片化的內(nèi)卷時代，數(shù)據(jù)庫選擇確實(shí)不是一件十分簡單的事情，既然如此復(fù)制，有些時候甚至無法把它當(dāng)成一件事情，研發(fā)團(tuán)隊對數(shù)據(jù)庫的掌握能力才是最為關(guān)鍵的事情。

是選擇一個更合適的數(shù)據(jù)庫產(chǎn)品，還是提升開發(fā)團(tuán)隊駕馭微服務(wù)應(yīng)用的能力，抑或是請高水平的數(shù)據(jù)架構(gòu)師來做設(shè)計，這些都是解決問題的方法，具體用哪一種，每個企業(yè)的IT部門都有一把辛酸淚需要傾訴。有時候作為門外的人，是不一定看得清楚的。