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