在面對一般業務數據、大數據、海量數據，以及針對不同的業務場景如：訂單處理、業務統計、商業智能等，數據庫的選型至關重要，這篇文章我們來梳理一下，在業務的不同階段我們應該做怎樣的數據庫選型？

階段一：需要快速搭建的交易管理系統

這個階段，基于業務的需求，我們需要快速的構建一個滿足ACID的交易系統，我們需要選擇事務型數據庫，并保證能夠快速地結合我們的技術棧進行敏捷開發。

在這個網站可以看到實時的數據庫流行趨勢：https://db-engines.com/en/ranking/relational+dbms

我們來看看關系型數據庫的排名：

可以看到制霸的依舊是幾個老牌數據庫廠商，國內廠商華為gaussdb、阿里數據庫oceanbase，但是基本上對上國外老牌廠商還是打不了，撇開技術實力不談，生態是個最大的問題。

在進行技術選型的時候，我們應該考慮幾點：1、生態：比如業界使用的多嗎？我們常用ORM框架是否提供對該數據庫的支持？；會這種數據庫管理、運維的人才多嗎？2、費用：是否收費 3、性能上是否滿足業務需求；當然由于我們和A國的競爭，我們還需要考慮可持續性的問題。

?	mysql	postgresql	oracle	sqlserver
評價	廣泛使用；會的人多；絕大多數技術框架都提供支持；免費；性能一般單表500w行一下問題不大；有可能有可持續性問題	近年來上升趨勢人比較明顯；但是非常會的比較少；目前主流的技術框架都開始支持；性能據說能達到mysql的10倍，就個人使用體驗來講，性能絕對吊打mysql；全部開源，沒有政治風險	在性能和支持上，無疑oracle是最好的，但是他收費，有A國政治風險	微軟出品，確實是精品。但是它相對來說比較封閉，微軟系的在用

所以我的建議是

不缺錢oracle

缺錢但有人，并且在項目初期就預計有上千萬的數據量pgsql

數據量不大，業務緊急用mysql。

階段一：交易量快速上升

交易量的快速上升，讓我們對性能和并發提出了更大的要求。這個時候我們需要一個能夠提供高并發和低延時并且便宜的數據庫。我們這里討論的是因為IO瓶頸導致的性能問題。

業內多選擇內存數據庫，來保存一定種類的數據，我們使用這類數據的時候不需要磁盤尋址和強制的事務處理，就只要查出來就好。這個業界一般用redis，我們就不要自己去選型了，這個就是目前市面上最好的。

為什么用？可以參考我關于redis的文章

https://blog.csdn.net/qq_35789269/article/details/117633073

階段三：我需要對大量數據（不到TB級）進行檢索和統計

這個時候我們選elasticsearch搜索引擎，也可以說成的采用倒排索引的內存數據庫。關于elasticsearch可以查看我的這篇文章。促使我開始用es的原因，是因為一個簡單的函數count（），在五千萬以上的單表上無論是mysql和pgsql都做不到在1s內返回數據，但是es可以。并且es能夠在抽象層面和我們的關系型數據庫的表一一映射起來，能夠做到外在邏輯的一致性。

https://mp-new.csdn.net/mp_blog/creation/editor/110210127

階段四：我需要對海量數據進行存儲，并提供商業分析報表

這個時候建議采用hdoop技術棧，使用hive做數據倉庫，使用hbase做即時查詢，其實hbase和redis作用基本差不多，只不過光使用內存太貴了，海量數據存下來根本是天價。價格可以參考SAP的HANA數據庫，貴上天際。

關于這套技術棧，其實不亞于建立一個數據中臺：可以參考我寫的這篇文章。
https://mp-new.csdn.net/mp_blog/creation/editor/118073637

總結一下：

?	redis	mysql	elasticsearch	hbase	hive
容量/容量擴展	低	中	大	海量	海量
查詢時效性	極高	中等	較高	較高	低
查詢靈活性	較差	非常好	較好	較差	非常好
寫入速度	極快	中等	較快	較快	慢
一致性、事務	弱	強	弱	弱	弱

總結

以上是生活随笔為你收集整理的大数据概述（三）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。