那我就根據(jù)這兩三年的研究與工作經(jīng)歷，說說如今的情況。
1.Oracle：傳統(tǒng)行業(yè)，尤其是政府，醫(yī)療，學(xué)校和大企業(yè)，基本上還是Oracle應(yīng)用最廣，其次就是DB2。反而是WebLogic和WebSphere這些中間件基本上隨著經(jīng)典JAVAee的沒落，已經(jīng)逐步退出歷史舞臺，被富前端和微服務(wù)框架的輕量級組合所替代。
2.MySQL：傳統(tǒng)行業(yè)的很多新項目也大量開始應(yīng)用MySQL，因為輕量級數(shù)據(jù)庫的前期成本很低，可以保證項目預(yù)算夠用，所以主要是新項目居多，面向互聯(lián)網(wǎng)連接的項目也居多。這些系統(tǒng)一般不會像Oracle一樣承擔(dān)關(guān)鍵性業(yè)務(wù)的數(shù)據(jù)存儲，所以選擇什么樣的數(shù)據(jù)庫都是開發(fā)公司自己的選擇決定。
目前有大量企業(yè)都開始上云，大家買云服務(wù)以阿里云ecs為主，總體上阿里云還是比較穩(wěn)定，那么對于云上數(shù)據(jù)庫的穩(wěn)定有要求的企業(yè)一般都會選擇阿里云主打的的rds系列，MySQL居多，PostgreSQL也開始逐漸被認可。
3.PostgreSQL：說到PostgreSQL，的確這兩年P(guān)G風(fēng)頭正勁，以前我的文章也提到過我做過的互聯(lián)網(wǎng)醫(yī)療產(chǎn)品，其架構(gòu)設(shè)計就選擇采用了PostgreSQL，主要就是看中PostgreSQL在生產(chǎn)上的穩(wěn)定性極高，而且成本很低。尤其是精通linux服務(wù)的架構(gòu)師，對于PostgreSQL更容易掌握。
更具體地說就是使用PostgreSQL的關(guān)鍵因素主要還是業(yè)務(wù)數(shù)據(jù)很關(guān)鍵，因為我們當(dāng)時承載的是互聯(lián)網(wǎng)醫(yī)療數(shù)據(jù)，醫(yī)療數(shù)據(jù)自身屬性就很關(guān)鍵！所以穩(wěn)定和安全都是剛性要求，同時要平衡成本與互聯(lián)網(wǎng)方式的靈活性，所以才否定了MySQL方案，堅決執(zhí)行了PostgreSQL方案。
4.Hadoop HDFS：大數(shù)據(jù)類項目的主數(shù)據(jù)集還是以Hadoop HDFS作為基礎(chǔ)存儲設(shè)施。盡管現(xiàn)在很熱的討論就是Hadoop已經(jīng)是日落黃昏，可以選擇其他更快的NoSQL存儲方案。實際上，大數(shù)據(jù)工程師在最終落地的執(zhí)行上，還是很誠實的選擇了Hadoop，因為其成熟度，穩(wěn)定性是最終考量的標(biāo)準(zhǔn)。
5.Elasticsearch：ELK家族的Elasticsearch目前被大量作為日志監(jiān)測分析的主數(shù)據(jù)集去使用，甚至都忽視了它本身是搜索引擎的這個事實，在電子商務(wù)網(wǎng)站，內(nèi)容發(fā)布網(wǎng)站以及社交媒體網(wǎng)站，Elasticsearch作為專業(yè)搜索引擎，還是穩(wěn)坐第一把交椅。
6.實時/時序數(shù)據(jù)庫：工業(yè)能源以及其他物聯(lián)網(wǎng)行業(yè)，實時、時序數(shù)據(jù)庫正在逐步采用開源的解決方案，例如Druid.io、InfluxDB，OpenTSDB，還是目前存儲物聯(lián)網(wǎng)數(shù)據(jù)最好的開源選擇方案。Druid.io是實時與歷史一整套實時庫解決方案；InfluxDB目前熱度非常高的時序數(shù)據(jù)庫，自己獨立實現(xiàn)了一套原生的集群存儲結(jié)構(gòu)；OpenTSDB主要依賴HBase分布式數(shù)據(jù)庫與HDFS分布式文件系統(tǒng)。另外提一句，清華推出的開源時序數(shù)據(jù)庫IOTDB，目前已經(jīng)升級成Apache.org的頂級項目。
7. Hadoop HBase：Hadoop hbase作為列簇存儲，也是毫秒級的k-v存儲，越來越適應(yīng)通用場景下的實時數(shù)據(jù)分析了，可能哪個領(lǐng)域都有能用到它，支撐實時處理的聯(lián)機分析以及小型批處理業(yè)務(wù)。它的分布式一致性，存儲hdfs的穩(wěn)定性，都是關(guān)鍵性業(yè)務(wù)數(shù)據(jù)進行實時分析的極佳方案。
8.TiDB：在互聯(lián)網(wǎng)海量數(shù)據(jù)查詢，保證事務(wù)一致性以及大吞吐寫入并行的時代，就會形成兩種模式，一種是NewSQL對關(guān)系型數(shù)據(jù)庫的替代方案，以前我的文章也不斷提到TiDB對關(guān)系數(shù)據(jù)庫替代的必要性，這種替換行為一般會出現(xiàn)在基于關(guān)系數(shù)據(jù)庫的上層復(fù)雜業(yè)務(wù)不斷升級更新帶來的問題，導(dǎo)致運維過程中相關(guān)人員生無可戀的情況。那么NewSQL這種分布式一致性，滿足ACID，又帶有k-v水平伸縮存儲的方案就極為合適，不用在關(guān)系數(shù)據(jù)庫的分庫分表的泥潭中掙扎。
9.MongoDB：另一種是關(guān)系數(shù)據(jù)庫自身的改進或者引入MongoDB進行部分替代，例如電子商務(wù)的訂單業(yè)務(wù)數(shù)據(jù)，互聯(lián)網(wǎng)醫(yī)療的健康檔案數(shù)據(jù)，內(nèi)容發(fā)布的文章數(shù)據(jù)，都能實現(xiàn)MongoDB的文檔化替代，這不僅更符合業(yè)務(wù)的文檔化模型，而且能保證事務(wù)的前提下，實現(xiàn)海量數(shù)據(jù)的支撐。
10.關(guān)系數(shù)據(jù)庫并行能力：關(guān)系數(shù)據(jù)庫也是在不斷改進中前進，尤其是輕量級數(shù)據(jù)庫的改進，MySQL8的cluster特性，PostgreSQL11的并行特性，都是不同手段想要達到同一個目的：那就是關(guān)系庫都在想盡一切辦法，不必讓用戶脫離關(guān)系型數(shù)據(jù)庫，非得擁抱NoSQL才能追求到海量數(shù)據(jù)的并行處理能力，同時也能降低用戶替換導(dǎo)致的巨大升級成本。
備注：以上架構(gòu)圖均來自數(shù)據(jù)庫官方網(wǎng)站或相關(guān)技術(shù)的權(quán)威網(wǎng)站。
