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