技術真的是日新月異，關係型數據庫在數據庫存儲界稱霸這麼多年後，市面上各種數據庫如雨後春筍蓬勃發展，似乎關係型數據庫也地位不保，我前段時間和同事聊天，聽到他們經常說的現在市面上的noSql數據庫完全可以替代現有的關係型數據庫，可是事實真的如此嗎，我們一起就市面上現在比較流行的各類數據庫，做一個對比：
真正業務開發中，絕對不是拍腦袋定下來使用那種數據庫就使用那種數據庫的，選擇某種或者某幾種數據庫配合使用，一定是對改數據庫有一個比較全面的認識。
關係型數據警告過這麼多年的披荊斬棘，到現在依舊能夠屹立不倒，他的優勢一定是特別的顯眼，關係型數據庫優點表現在：
- 強大的SQL能力，應對各類複雜查詢有時候一個join就搞定了。
- 支持完整的
ACID屬性，這個屬性其實也是數據庫能夠大行其道的根本原因。- A(Atomicity)原子性: 一個事務的所有操作一起成功，一起失敗。
- C(Consistency)一致性:在事務開始之前和事務結束以後數據庫的完整性不被破壞。
- I(Isolation)隔離性:數據庫允許多個併發事務，擁有同時對數據進行讀寫的能力，隔離性可以保證多個事務併發或者交叉執行是導致的數據不一致性事務的隔離級別爲：讀未提交、讀已提交、可重複度、串行化。
- D(Durability)持久性：書屋結束後對數據的修改就是永久的，即使系統故障也不會丟失。
- 容易理解，數據庫的結構爲二維表格結構，最符合和貼近邏輯社會的概念。
雖然關係型數據庫擁有這麼多的優勢，但是爲什麼它的地位在有時也會被撼動呢？關係型數據擁有如此強大的功能的背後也有很多缺點主要表現在：
- 無法做數據結構的存儲，例如在一個社交產品關注的功能中，一個人的關注列表是一個list集合形式的列表，但是關係型數據庫只能表關聯或者基於多次查詢進行數據組裝後返回！
- 表結構強約束，擴展不方便！關係型數據庫是結構化存儲，在進行數據存儲時無法動態的增加列或者減少列，在更新表字段的時候往往會操作ddl語句。操作不存在的字段也會報錯！
- 大數據量的查詢中，讀寫性能低，IO開銷大！因爲關係型數據庫是行式存儲，所以在查詢某幾個字段時，關係型數據依舊會將整行存儲到內存中，所以內存開銷大！
- 關係型數據庫，全文檢索的更能較弱。
我們在業務開發中，一定要學會取長補短，取精華，去糟粕，針對以上缺點，我們來總結一下市面上比較好的開源實現的數據庫吧！
缺點一：無法做數據結構存儲：
**以redis爲例：**它可以解決關係型數據庫無法存儲數據結構的問題，其優點體現在：
- **支持多種數據結構，例如:
String、set、Hash、sortedSet、hyperloglog、geo、pub/sub**等 - 性能極高，內存型數據庫，對於數據的讀寫極快。
- 原子性，所有的操作全部都是原子性，支持對與福哦個操作的合併組裝成原子操作。
當然人無完人，他也有缺點：
- 數據量受機器內存大小的影響，在海量數據存儲中並不適用，但是適合小數據量下的快速查詢和計算。
- 不支持完成的ACID事務屬性，他提供的事務只保證一致性和隔離性。
因爲其事務完整性無法保證，所以適用場景時都事務要求並沒有那麼高，且讀寫頻率極高的場景！
缺點二：表結構強約束，擴展不方便：
**以MongoDB爲例：**它可以解決表結構強約束，擴展不方便的問題，其優點表現在：
- 沒有表結構的強約束，在使用時可以任意的增加或者減少字段，文檔結構的存儲方式，能夠更便捷的獲取數據。
- 支持大容量的存儲，海量數據下性能優越。
- 內置自動分片，支持雲級擴展。
- 支持複雜聚合
MongoDB缺點表現在：
- 不支持事務，不適合對事物要求嚴格的場景。
- 無法支持複雜查詢，如關係型數據的join操作。
- 事實上MongoDB的效率存在一定的波動性。
適用場景：不怎麼使用事務，數據相較而言不那麼重要，數據字段不確定！
缺點三：大數據量的查詢中，讀寫性能低，IO開銷大：
**以HBase爲例：**解決讀寫性能低，IO開銷大的問題，其優點表現在：
- Hbase適合存儲PB級別的海量數據，在PB級別的數據以及採用廉價PC存儲的情況下，能在幾十到百毫秒內返回數據。
- Hbase是根據列族來存儲數據的。其實這個時減少IO開銷的一個很重要的性能指標，因爲數據會按照列存儲，舉一個場景，在一年內，淘寶購買電腦的價格階梯是多少，如果使用行式存儲，我們會統計整個購買掉鬧的記錄，然後再篩選價格這個字段，事實上我們只需要一個價格字段；因爲Hbase是基於列存儲，查詢時只需要查詢這個類就OK，所以它的IO讀寫消耗小。
- 極易擴展Hbase的擴展性主要體現在兩個方面，一個是基於上層處理能力（RegionServer）的擴展，一個是基於存儲的擴展（HDFS）。
- 高併發：由於目前大部分使用Hbase的架構，都是採用的廉價PC，因此單個IO的延遲其實並不小，一般在幾十到上百ms之間。這裏說的高併發，主要是在併發的情況下，Hbase的單個IO延遲下降並不多。能獲得高併發、低延遲的服務。
hbase缺點表現在：
- 讀取多個列時，關係型數據庫因爲時按行存儲，所以再磁盤上的位置是連續的所以讀取速率較高，但是HBase是按照列存儲，不同的列存儲再磁盤上的不連續的空間，在讀取多個列時速度較慢。
- 再更新數據的時候，因爲行式存儲所有的列的再磁盤空間上的連續性，故而可以一次更新，但是HBase會慢很多！其次HBase在更新時需要對字段進行 解壓-更新-壓縮 操作所以也會出現性能瓶頸！
- 它不支持SQL。必須依賴開發進行代碼解決
- 權限，安全上存在隱患。只要知道ZK的IP和端口，你就能輕鬆訪問HBASE，甚至不需要任何權限校驗。
適用場景：離線大數據分析，這類場景一般都是對於單列操作且寫入後無需更新！
缺點四：關係型數據庫，全文檢索的更能較弱。
Elasticsearch 優點表現在：
- 全文檢索，基於分詞、倒排索引進行索引，查詢速度簡直不不要太快！
- 負載再平衡和路由在大多數情況下自動完成。客戶端發送請求到任意一個node，coordinate node對document進行路由，將請求轉發到對應的node，此時會使用round-robin隨機輪詢算法，在primary shard以及其所有replica中隨機選擇一個，讓讀請求負載均衡
- 可以擴展到上百臺服務器，處理PB級別的結構化或非結構化數據
缺點：
- 在需要添加新數據與新字段的時候，如果elasticSearch進行搜索是可能需要重新修改格式。之前的數據需要重新同步，對數據的管理有很多困難
從關係型數據庫的數據灌輸，一般是將數據庫內部數據轉換成json來適應全文檢索！
關於上述對於各類數據庫的介紹，相信你對他們都有了一個大概的認識，具體的使用場景，還是要結合業務來使用！下面是關於使用場景的一點建議！
關係型和NoSQL數據庫的選型。考慮幾個指標，數據量、併發量、實時性、一致性要求、讀寫分佈和類型、安全性、運維性等。根據這些指標，軟件系統可分成幾類。
- 管理型系統，如運營類系統，首選關係型。
- 大流量系統，如電商單品頁的某個服務，後臺選關係型，前臺選內存型。
- 日誌型系統，原始數據選列式，日誌搜索選倒排索引。
- 搜索型系統，指站內搜索，非通用搜索，如商品搜索，後臺選關係型，前臺選倒排索引。
- 事務型系統，如庫存、交易、記賬，選關係型+緩存+一致性協議，或新型關係數據庫。
- 離線計算，如大量數據分析，首選列式，關係型也可以。
- 實時計算，如實時監控，可以選時序數據庫，或列式數據庫。
才疏學淺，如果文章中理解有誤，歡迎大佬們私聊指正！歡迎關注作者的公衆號，一起進步，一起學習！
