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

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

隨著企業(yè)信息化對(duì)數(shù)據(jù)處理要求的不斷提高，我們有太多種類的數(shù)據(jù)需要處理了。應(yīng)用的類型也是豐富多彩。某些應(yīng)用程序需要同時(shí)訪問用于存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)的關(guān)系數(shù)據(jù)庫(例如 PostgreSQL)、用于內(nèi)容緩存的內(nèi)存數(shù)據(jù)庫(例如 Redis)、存儲(chǔ)海量物聯(lián)網(wǎng)數(shù)據(jù)的時(shí)間序列數(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)可能會(huì)選擇 Oracle 或 PostgreSQL 等關(guān)系 DBMS 來確保其結(jié)構(gòu)化數(shù)據(jù)的 ACID事務(wù);運(yùn)營大型在線多人游戲的互聯(lián)網(wǎng)服務(wù)商更喜歡使用 Redis 等鍵值 NoSQL 數(shù)據(jù)庫；

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

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

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

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

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

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

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

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

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

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

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

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

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

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