NoSQL最初表示的“反SQL”運動，用新型的非關係型數據庫取代關係型數據庫。
現在NoSQL（Not only SQL）表示關係和非關係型數據庫各有優缺點，彼此都無法互相取代。
NoSQL的特點：
通常，NoSQL數據庫具有以下幾個特點：
- 靈活的可擴展性。
- 靈活的數據模型
- 與雲計算緊密融合。
現在有很多公司都使用了NoSQL數據庫：如Google，Facebook，百度，阿里等。
NoSQL興起的原因
原因一：關係型數據庫已經無法滿足Web2.0的需求
關係型數據庫無法滿足Web2.0的需求，主要表現在以下幾個方面：
- 無法滿足海量數據的管理需求。
- 無法滿足數據高併發的需求。
- 無法滿足高可擴展性和高可用性的需求。
在現在1分鐘的時間內：
- 新浪可以發送2萬條微博。
- 蘋果可以下載4.7萬次應用。
- 淘寶可以賣出6萬件商品。
- 人人網可以發送30萬次訪問。
- 百度可以產生90萬次搜索查詢。
MySQL集羣是否可以完全解決問題？
- 複雜性：部署、管理、配置很複雜。
- 數據庫複製：MySQL主備之間採用複製方式，只能是異步複製，當主庫壓力較大時可能產生較大延遲，主備切換可能會丟失最後一部分更新事務，這時往往需要人工介入，備份和恢復不方便。
- 擴容問題：如果系統壓力過大需要增加新的機器，這個過程涉及數據重新劃分，整個過程比較複雜，且容易出錯。
- 動態數據遷移問題：如果某個數據庫組壓力過大，需要將其中部分數據遷移出去，遷移過程需要總控節點整體協調，以及數據庫節點的配合。這個過程很難做到自動化。
原因二：“One size fits all”模式很難適用於截然不同的業務場景：
- 關係模型作爲統一的數據模型既被用於數據分析，也被用於在線業務。但這兩者一個強調高吞吐，一個強調低延時，已經演化出完全不同的架構。用同一套模型來抽象顯然是不合適的。
- Hadoop就是針對數據分析。
- MongoDB、Redis等是針對在線業務，兩者都拋棄了關係模型。
原因三：關係型數據庫的關鍵特性：
關係數據庫的關鍵特性包括完善的事務機制和高效的查詢機制。但是，關係數據庫引以爲傲的兩個關鍵特性，到了Web2.0時代卻成了雞肋，主要表現在以下幾個方面：
- Web2.0網站系統通常不要求嚴格的數據庫事務。
- Web2.0並不要求嚴格的讀寫實時性。
- Web2.0通常不包含大量複雜的SQL查詢（去結構化，存儲空間換取更好的查詢性能）。
NoSQL與關係型數據庫的比較
NoSQL和關係數據庫的簡單比較：
RDBMS即關係數據庫管理系統(Relational Database Management System)。
對比總結：
關係數據庫：
- 優勢：以完善的關係代數理論作爲基礎，有嚴格的標準，支持事務ACID四性，藉助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持 。
- 劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過於死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等。
NoSQL數據庫：
- 優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等 。
- 劣勢：缺乏數學理論基礎，複雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術尚不成熟，缺乏專業團隊的技術支持，維護較困難等。
關係數據庫和NoSQL數據庫各有優缺點，彼此無法取代。
- 關係數據庫應用場景：電信、銀行等領域的關鍵業務系統，需要保證強事務一致性。
NoSQL數據庫應用場景：互聯網企業、傳統企業的非關鍵業務（比如數據分析）。
採用混合架構：
案例：亞馬遜公司就使用不同類型的數據庫來支撐它的電子商務應用。
NoSQL的四大類型
四大類：
NoSQL數據庫雖然數量衆多，但是，歸結起來，典型的NoSQL數據庫通常包括鍵值數據庫、列族數據庫、文檔數據庫和圖形數據庫。
四大數據庫的主要產品：
鍵值數據庫：
相關產品：
- Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached。
數據模型：
- 鍵/值對
- 鍵是一個字符串對象
- 值可以是任意類型的數據，比如整型、字符型、數組、列表、集合等。
典型應用：
- 涉及頻繁讀寫、擁有簡單數據模型的應用
- 內容緩存，比如會話、配置文件、參數、購物車等
- 存儲配置和用戶數據信息的移動應用
優點：
- 擴展性好
- 靈活性好
- 大量寫操作時性能高
缺點：
- 無法存儲結構化信息，條件查詢效率較低
不適用情形：
- 不是通過鍵而是通過值來查：鍵值數據庫根本沒有通過值查詢的途徑。
- 需要存儲數據之間的關係：在鍵值數據庫中，不能通過兩個或兩個以上的鍵來關聯數據。
- 需要事務的支持：在一些鍵值數據庫中，產生故障時，不可以回滾。
使用者：
- 百度雲數據庫（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis和Memcached）、StackOverFlow（Redis）、Instagram （Redis）、Youtube（Memcached）、Wikipedia（Memcached）
Redis有時候會被人們稱爲“強化版的Memcached” 支持持久化、數據恢復、更多數據類型.
列族數據庫：
相關產品：
- BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
數據模型：列族
典型應用：
- 分佈式數據存儲與管理
- 數據在地理上分佈於多個數據中心的應用程序
- 可以容忍副本中存在短期不一致情況的應用程序
- 擁有動態字段的應用程序
- 擁有潛在大量數據的應用程序，大到幾百TB的數據
優點：
- 查找速度快
- 可擴展性強
- 容易進行分佈式擴展
- 複雜性低
缺點：
- 功能較少，大都不支持強事務一致性。
不適用情形：
- 需要ACID事務支持的情形，Cassandra等產品就不適用
使用者：
- Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、Yahoo!（HBase）
文檔數據庫：
“文檔”其實是一個數據記錄，這個記錄能夠對包含的數據類型和內容進行“自我描述”。XML文檔、HTML文檔和JSON 文檔就屬於這一類。SequoiaDB就是使用JSON格式的文檔數據庫，它的存儲的數據是這樣的：
文檔數據庫的特點：
- 數據是不規則的，每一條記錄包含了所有的有關“SequoiaDB”的信息而沒有任何外部的引用，這條記錄就是“自包含”的。
- 這使得記錄很容易完全移動到其他服務器，因爲這條記錄的所有信息都包含在裏面了，不需要考慮還有信息在別的表沒有一起遷移走。
- 同時，因爲在移動過程中，只有被移動的那一條記錄（文檔）需要操作，而不像關係型中每個有關聯的表都需要鎖住來保證一致性，這樣一來ACID的保證就會變得更快速，讀寫的速度也會有很大的提升。
文檔數據庫的相關產品：
- MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
數據模型：
- 鍵/值
- 值（value）是版本化的文檔
典型應用：
- 存儲、索引並管理面向文檔的數據或者類似的半結構化數據。
- 比如，用於後臺具有大量讀寫操作的網站、使用JSON數據結構的應用、使用嵌套結構等非規範化數據的應用程序。
優點：
- 性能好（高併發），靈活性高，複雜性低，數據結構靈活。
- 提供嵌入式文檔功能，將經常查詢的數據存儲在同一個文檔中。
- 既可以根據鍵來構建索引，也可以根據內容構建索引
缺點：缺乏統一的查詢語法。
不適用情形：
- 在不同的文檔上添加事務。文檔數據庫並不支持文檔間的事務，如果對這方面有需求，則不應該選用這個解決方案。
使用者：
- 百度雲數據庫（MongoDB）、SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）
圖形數據庫：
相關產品：
- Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
數據模型：圖結構
典型應用：
- 專門用於處理具有高度相互關聯關係的數據，比較適合於社交網絡、模式識別、依賴分析、推薦系統以及路徑尋找等問題
優點：
- 靈活性高，支持複雜的圖形算法，可用於構建複雜的關係圖譜。
缺點：複雜性高，只能支持一定的數據規模。
使用者：
- Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）
不同類型數據庫比較分析；
MySQL產生年代較早，而且隨着（Web應用軟件組合）LAMP（Linux+Apache+Mysql/MariaDB+Perl/PHP/Python）大潮得以成熟。儘管其沒有什麼大的改進，但是新興的互聯網使用的最多的數據庫。
MongoDB是個新生事物，提供更靈活的數據模型、異步提交、地理位置索引等五花十色的功能。
HBase是個“仗勢欺人”的大象兵。依仗着Hadoop的生態環境，可以有很好的擴展性。但是就像象兵一樣，使用者需要養一頭大象(Hadoop),才能驅使他。
Redis是鍵值存儲的代表，功能最簡單。提供隨機數據存儲。就像一根棒子一樣，沒有多餘的構造。但是也正是因此，它的伸縮性特別好。就像悟空手裏的金箍棒，大可捅破天，小能成縮成針。
NoSQL的三大基石
三大基石：CAP，BASE，最終一致性。
CAP：
所謂的CAP指的是：
- C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分佈式環境中，多點的數據是一致的，或者說，所有節點在同一時間具有相同的數據。
- A:（Availability）：可用性，是指快速獲取數據，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應；
- P（Tolerance of Network Partition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作。
CAP理論告訴我們，一個分佈式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多隻能同時滿足其中兩個，正所謂“魚和熊掌不可兼得”。
當處理CAP的問題時，可以有幾個明顯的選擇：
- CA：也就是強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一臺機器上。很顯然，這種做法會嚴重影響系統的可擴展性。傳統的關係數據庫（MySQL、SQL Server和PostgreSQL），都採用了這種設計原則，因此，擴展性都比較差
- CP：也就是強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網絡分區的情況時，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務
- AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據
BASE:
說起BASE（Basically Availble, Soft-state, Eventual consistency），不得不談到ACID。
一個數據庫事務具有ACID四性：
- A（Atomicity）：原子性，是指事務必須是原子工作單元，對於其數據修改，要麼全都執行，要麼全都不執行。
- C（Consistency）：一致性，是指事務在完成時，必須使所有的數據都保持一致狀態。
- I（Isolation）：隔離性，是指由併發事務所做的修改必須與任何其它併發事務所做的修改隔離。
- D（Durability）：持久性，是指事務完成之後，它對於系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持。
BASE的基本含義是基本可用（Basically Availble）、軟狀態（Soft-state）和最終一致性（Eventual consistency）：
基本可用：
基本可用，是指一個分佈式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現。
軟狀態：
“軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯後性。
最終一致性：
一致性的類型包括強一致性和弱一致性，二者的主要區別在於高併發的數據訪問操作下，後續操作是否能夠獲取最新的數據。對於強一致性而言，當執行完一次更新操作後，後續的其他讀操作就可以保證讀到更新後的最新數據；反之，如果不能保證後續訪問讀到的都是更新後的最新數據，那麼就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許後續的訪問操作可以暫時讀不到更新後的數據，但是經過一段時間之後，必須最終讀到更新後的數據。
最常見的實現最終一致性的系統是DNS（域名系統）。一個域名更新操作根據配置的形式被分發出去，並結合有過期機制的緩存；最終所有的客戶端可以看到最新的值。
最終一致性根據更新數據後各進程訪問到數據的時間和方式的不同，又可以區分爲：
- 因果一致性：如果進程A通知進程B它已更新了一個數據項，那麼進程B的後續訪問將獲得A寫入的最新值。而與進程A無因果關係的進程C的訪問，仍然遵守一般的最終一致性規則。
- “讀己之所寫”一致性：可以視爲因果一致性的一個特例。當進程A自己執行一個更新操作之後，它自己總是可以訪問到更新過的值，絕不會看到舊值。
- 單調讀一致性：如果進程已經看到過數據對象的某個值，那麼任何後續訪問都不會返回在那個值之前的值。
- 會話一致性：它把訪問存儲系統的進程放到會話（session）的上下文中，只要會話還存在，系統就保證“讀己之所寫”一致性。如果由於某些失敗情形令會話終止，就要建立新的會話，而且系統保證不會延續到新的會話。
- 單調寫一致性：系統保證來自同一個進程的寫操作順序執行。系統必須保證這種程度的一致性，否則就非常難以編程了。
如何實現各種類型的一致性？
對於分佈式數據系統：
- N — 數據複製的份數
- W — 更新數據是需要保證寫完成的節點數
R — 讀取數據的時候需要讀取的節點數
如果W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型數據庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的數據，都是一致的。一般設定是R＋W = N+1，這是保證強一致性的最小設定。
如果W+R<=N，則是弱一致性。例如對於一主一備異步複製的關係型數據庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的數據，所以是弱一致性。
對於分佈式系統，爲了保證高可用性，一般設置N>=3。不同的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。
如果N=W,R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由於數據分佈的N個節點是同步寫入的，因此可以保證強一致性。 實例：HBase是藉助其底層的HDFS來實現其數據冗餘備份的。HDFS採用的就是強一致性保證。在數據沒有完全同步到N個節點前，寫操作是不會返回成功的。也就是說它的W＝N，而讀操作只需要讀到一個值即可，也就是說它R＝1。
像Voldemort，Cassandra和Riak這些類Dynamo的系統，通常都允許用戶按需要設置N，R，W三個值，即使是設置成W＋R<= N也是可以的。也就是說他允許用戶在強一致性和最終一致性之間自由選擇。而在用戶選擇了最終一致性，或者是W
從NoSQL到NewSQL數據庫
文檔數據庫MongoDB
MongoDB簡介：
MongoDB 是由C++語言編寫的，是一個基於分佈式文件存儲的開源數據庫系統。
在高負載的情況下，添加更多的節點，可以保證服務器性能。
MongoDB 旨在爲WEB應用提供可擴展的高性能數據存儲解決方案。
MongoDB 將數據存儲爲一個文檔，數據結構由鍵值(key=>value)對組成。MongoDB 文檔類似於 JSON 對象。字段值可以包含其他文檔，數組及文檔數組。
MongoDB主要特點：
- 提供了一個面向文檔存儲，操作起來比較簡單和容易
- 可以設置任何屬性的索引來實現更快的排序
- 具有較好的水平可擴展性
- 支持豐富的查詢表達式，可輕易查詢文檔中內嵌的對象及數組
- 可以實現替換完成的文檔（數據）或者一些指定的數據字段
- MongoDB中的Map/Reduce主要是用來對數據進行批量處理和聚合操作
- 支持各種編程語言:RUBY，PYTHON，JAVA，C++，PHP，C#等語言
- MongoDB安裝簡單
MongoDB概念解析：
在mongodb中基本的概念是文檔、集合、數據庫。
通過下圖實例，我們也可以更直觀的的瞭解MongoDB中的一些概念：
舉例2：在一個關係型數據庫中，一篇博客（包含文章內容、評論、評論的投票）會被打散在多張數據表中。在文檔數據庫MongoDB中，能用一個文檔來表示一篇博客， 評論與投票作爲文檔數組，放在正文主文檔中。這樣數據更易於管理，消除了傳統關係型數據庫中影響性能和水平擴展性的“JOIN”操作。
數據庫
- 一個mongodb中可以建立多個數據庫。
- MongoDB的默認數據庫爲”db”，該數據庫存儲在data目錄中。
- MongoDB的單個實例可以容納多個獨立的數據庫，每一個都有自己的集合和權限，不同的數據庫也放置在不同的文件中。
文檔
文檔是一個鍵值(key-value)對(即BSON)。MongoDB 的文檔不需要設置相同的字段，並且相同的字段不需要相同的數據類型，這與關係型數據庫有很大的區別，也是 MongoDB 非常突出的特點。
一個簡單的文檔例子如下：
{"site":"dblab.xmu.edu.cn", "name":"廈門大學數據庫實驗室"}- 1
RDBMS與MongoDB對應術語：
集合
集合就是 MongoDB 文檔組，類似於 RDBMS （關係數據庫管理系統：Relational Database Management System)中的表格。
集合存在於數據庫中，集合沒有固定的結構，這意味着你在對集合可以插入不同格式和類型的數據，但通常情況下我們插入集合的數據都會有一定的關聯性。 比如，我們可以將以下不同數據結構的文檔插入到集合中：
{"site":"www.baidu.com"} {"site":"dblab.xmu.edu.cn", "name":"廈門大學數據庫實驗室"} {"site":"www.runoob.com","name":"菜鳥教程","num":5}- 1
MongoDB數據類型：
轉載來源：https://blog.csdn.net/qq_38265137/article/details/80382482