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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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