題主要先明白兩種型別，

關係型就常見的oracle，MySQL，等等

非關係快取中用的多，而且有點像精簡版的關係型！

鍵值對形式或者文件形式儲存！

非關係不支援SQL，不支援事務，不過速度快啊，效能好！

至於選擇的Redis跟mongdb，要看場景進行選擇了！

相信大家在二級資料庫考試的時候都做過這麼一道題，關係型資料庫中的關係是什麼意思？答案是:資料模型符合滿足一定條件的二維表格式，即是這張二維表中的行都是一個個元素，而列是一個個的屬性，這種結構化的資料透過結構化的查詢語言(SQL)可以以不同的方式進行存取！

所以說，SQL的定義和執行就代表著關係型資料庫結構的資料存取，從where，groupby，order等命令，sum，count等函式就能一目瞭然的知道，關係型資料庫可以透過欄位方便的篩選，分組，統計和運算，並且效能十分高效！

總結來說，關係型資料庫不僅維護著一張二維表中行和列的關係，還維護著多張表中一對多，多對多的關係，並能透過SQL處理這種關係進行存取，還提供事務支援！

而非關係型資料庫是以key-value形式儲存資料，可認為是隻有一個主鍵(key)，加一個屬性(value)構成的二維表，其value中的屬性之間的關係無法體現，很難透過其中的某個屬性進行統計，分組等關係型資料庫中的常規操作！

非關係型資料庫更容易維護與擴充套件，關係型資料庫卻因為分表分庫等有一定難度！非關係型資料庫不支援事務，只能使用別的方式支援資料一致性！

mongodb和redis比較的話，redis更適合用做快取，訊息佇列等，而mongodb適用於文件結構(json等)等的大容量資料存取！

關係型資料庫和非關係型資料庫在不同的場景都大有所為，可根據實際情況擇優使用！

非關係型資料庫和關係型資料庫的區別就說到這，本人持續更新更多的技術分享，敬請關注！

關係型資料庫在關係代數為基礎建立起來的一種應用，經過嚴密的完備性證明。也就是說理論上關係型資料庫可用於所有場景。當然這僅僅是理論上的說法，實際上，很多文件和圖形資料很難採用統一的結構，而且這些資料通常都是海量的。為了提高這些資料的處理效率，人們針對不同的場景設計了不同的演算法，這就是非關係型資料庫。值得注意的是非關係型資料庫中保留了關係型資料庫的特徵，是對關係型資料庫應用的一種擴充套件。NoSQL=Not Only SQL，不僅僅是SQL。

只要是每行的列都相同的表格都是關係型資料表。這叫第一範型。每行資料都是唯一的關係表叫第二範型。每行資料唯一且能由特定欄位確定的關係表叫第三正規化，這些特定的欄位被稱為主鍵。通常所說的資料庫都滿足第三範型，也就是可用主鍵進行查詢。關係型資料庫有基本的四則運算可以增減列或增減行:選擇，投影，並，交。SQL就是根據這些規則設計出來的。

非關係型資料庫是根據特定的應用場景設計出來的，沒有明確的分類標準，但根據應用場景大致可分為:鍵值儲存，列儲存，文件型和圖型等幾類。題主所說的Redis是鍵值儲存型的，它不關心文件的內容，用雜湊表儲存了文件的特徵屬性，方便快速查詢文件，多用於檔案管理。MongoDb是文件型資料庫，管理結構化或者半結構化的格式文件，可對文件內容進行高速地全文檢索，也可以建立複雜的文件分類結構，是鍵值儲存的升級版。至於如何選擇，主要看需求，不需要檢索內容時可使用Redis，輕便易安裝。反之，用MongoDb功能強大。

關係型資料庫是一種基本的資料庫，非關係型資料庫是關係型資料庫的擴充套件應用。我個人很討厭非關係型資料庫這個叫法，它容易讓人產生誤解，以為NoSQL=No SQL。實際上，還有很多使用其他原理的資料庫，比如，在人工智慧領域用一定應用的邏輯型資料庫。這類資料庫比較小眾鮮為人知，稱它們為非關係型資料庫比較貼切。

先說說關係型資料庫和非關係型資料庫有什麼區別

這裡的關係型和非關係型，主要是資料儲存格式的區別，我們常見的關係型資料庫有Mysql、Oracle、DB2、SQL Server等，都是透過關係模型來組織資料，也就是二維表格模型。

而非關係型資料庫，就不是按照這個二維表格來儲存資料了，例如Redis是使用鍵值對（key-value）來組織資料，MongoDB是採用BSON的格式（可以想象成JSON）；並且不侷限於固定的結構。

關係型資料庫和非關係型資料庫之間的關係，也不是有你沒有，二者選其一，通常都是配合起來使用的。

關係型資料庫，容易理解，使用方便（透過SQL語言操作），易於維護；但是因為資料在磁碟上儲存，I/O會成為一個很大的瓶頸，如果在高併發的場景下，效能降低的很快；另外，對於關係型資料庫，當單表資料量增加到一定程度的時候，表的操作效率也會很低；表結構固定，當資料量比較大的時候，對錶結構的擴充套件會是災難性的。

非慣性資料庫因為資料結構的“隨性”，使用者可以根據需要增加欄位，關係型資料習慣設計成多張表，然後透過表關聯查詢，而非關係型資料庫（文件性）會把所有欄位放到一個集合中，避免多表的關聯。不過缺點也非常明顯，“隨性”也就意味著沒有標準，單集合有好處也有壞處，沒有完整性約束，對於複雜的業務場景支援比較差。

Redis的資料儲存格式是key-value，支援持久化、 支援事務，經常用於快取、高併發下的讀寫（計數器、最新列表、秒殺），因為單執行緒的機制也會用於分散式鎖。

MongoDB的資料儲存格式為BSON（類似於JSON），支援快速讀寫，特別是大吞吐量的寫操作；如果表結構不明確，未來可能會發生很大的變化，非常適合使用MongoDB。

架構中可以同時包含關係型資料庫、Redis和MongoDB，各司其職。

相信不少人在工作中都遇到過以下對話：

程式設計師A：又要到流量高峰期了，感覺資料庫要崩。

程式設計師B：嗯嗯，趕緊擴容吧。

雖然資料庫很耳熟，但是它究竟是何方神聖呢？今天就給大家科普一下。

資料庫，其實就是網際網路業務儲存、查詢資料的倉庫。通過幾十年的發展歷史讓資料庫衍生出了各種不同的型別。

關係型資料庫，是指採用了關係模型來組織資料的資料庫。例如，某個學生的資訊——姓名：張三，性別：男，學號：12345，班級：二年級一班，每一個資訊之間是有聯絡的，而資料也是以表格形式儲存的。

這就是最早的資料庫形態，1970年IBM的研究員E.F.Codd博士首先提出關係模型，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流資料庫結構的主流模型。Oracle、DB2、Microsoft SQL Server、MySQL等都屬於這一範疇。

但是，這類資料庫的特點是一致性強，缺點是讀寫效能差。

顧名思義，非關係型資料庫是相對關係型資料庫的一個概念，起初指的是“沒有SQL”的資料庫，但現在已經公認為“no relational”（非關係型）。非關係型資料庫是根據特定的應用場景設計出來的，沒有明確的分類標準，但根據應用場景大致可分為幾類：1、文件資料庫，沒研究過定義，通常mongodb 就是文件資料庫，特點就是資料定義比較靈活。2、Kv資料庫，提供的是kv的資料表示模式。單機的rocksdb，分散式的tikv之類。3、圖資料庫。資料可以用圖來定義。4、列式資料庫。hbase之類，這裡可能有爭議，很多人把hbase 定義為列存。

非關係型資料庫的代表是MongoDB、Redis以及Hbase，其特點與關係型資料庫相反。

之前提到的資料庫都屬於傳統資料庫和開源資料庫，但到了雲計算時代，無論是雲服務提供商還是使用者，都需要一個完全為雲打造的資料庫，於是誕生了全新的產品形態——雲原生資料庫。

作為雲計算領域的先行者，亞馬遜在2014年11月召開的AWS re:Invent 年度大會上，釋出了雲原生資料庫Aurora, 讓資料庫行業發生了翻天覆地的變化。

如今，國際社會公認，與傳統商業資料庫相比，雲原生資料庫擁有以下幾個大優勢，是未來的大勢所趨。

1）價格更低

傳統商業資料庫按年、按CPU這樣的方式進行售賣，對大體量的企業而言，每年需要數百萬甚至千萬的費用。

雲原生資料庫按使用量付費，讓使用者可以以非常低的價格就享受到企業級資料庫的服務。使用者可以根據自己的業務實際發展情況，按需的購買，可以大大降低企業在早期發展過程的成本。

2）更強的效能

使用者使用傳統的資料庫需要單獨購買硬體，然而傳統的資料庫廠商則更傾向於去適配通用的硬體，對於一些特定的、前沿的硬體，不會去專門適配，所以傳統資料庫使用者無法享受新硬體的紅利。

而云原生資料庫的架構可以重複享受硬體變革帶來的紅利，從而實現更強的效能。

3）更快速的迭代，讓資料庫更安全穩定

雲原生資料庫可以做到以周，甚至以天為單位來迭代資料庫，這是傳統的資料庫不可能做到的。當系統出現問題時，雲原生資料庫可以快速進行升級，而傳統資料庫升級的週期通常是年，級別是出現了非常嚴重的漏洞，升級的週期也是以月為單位來計算的。

4）無需關注部署、運維等，全力專注業務開發

現在是一個快速創新的時代，每家企業都希望將重要的資源聚焦在自己的核心業務開發上。使用雲原生資料庫，讓企業不再需要關注資料庫的部署與運維，開箱即用，全力專注在自己的業務開發和使用者價值上。