那我就根據這兩三年的研究與工作經歷，說說如今的情況。
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才能追求到海量資料的並行處理能力，同時也能降低使用者替換導致的巨大升級成本。
備註：以上架構圖均來自資料庫官方網站或相關技術的權威網站。
可以閱讀另一篇關於分散式和大資料技術的詳細文章：
