一、NoSQL介紹
NoSQL，泛指非關係型的數據庫。隨着互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題。NoSQL網站：http://www.nosql-database.org
1、NoSQL數據庫的四大分類
鍵值(Key-Value)存儲數據庫 ：這一類數據庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來說的優勢在於簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存儲數據庫：這部分數據庫通常是用來應對分佈式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.
文檔型數據庫 ：文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數據庫可 以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。
圖形(Graph)數據庫 ：圖形結構的數據庫同其他行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，並且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL)，因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。如：Neo4J, InfoGrid, Infinite Graph.
因此，我們總結NoSQL數據庫在以下的這幾種情況下比較適用：1、數據模型比較簡單；2、需要靈活性更強的IT系統；3、對數據庫性能要求較高；4、不需要高度的數據一致性；5、對於給定key，比較容易映射覆雜值的環境。
2、NoSQL數據庫的四大分類表格分析
3、共同特徵
對於NoSQL並沒有一個明確的範圍和定義，但是他們都普遍存在下面一些共同特徵：
不需要預定義模式：不需要事先定義數據模式，預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時，並不需要預先定義它們的模式。
無共享架構：相對於將所有數據存儲的存儲區域網絡中的全共享架構。NoSQL往往將數據劃分後存儲在各個本地服務器上。因爲從本地磁盤讀取數據的性能往往好於通過網絡傳輸讀取數據的性能，從而提高了系統的性能。
彈性可擴展：可以在系統運行的時候，動態增加或者刪除結點。不需要停機維護，數據可以自動遷移。
分區：相對於將數據存放於同一個節點，NoSQL數據庫需要將數據進行分區，將記錄分散在多個節點上面。並且通常分區的同時還要做複製。這樣既提高了並行性能，又能保證沒有單點失效的問題。
異步複製：和RAID存儲系統不同的是，NoSQL中的複製，往往是基於日誌的異步複製。這樣，數據就可以儘快地寫入一個節點，而不會被網絡傳輸引起遲延。缺點是並不總是能保證一致性，這樣的方式在出現故障的時候，可能會丟失少量的數據。
BASE：相對於事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。
NoSQL數據庫並沒有一個統一的架構，兩種NoSQL數據庫之間的不同，甚至遠遠超過兩種關係型數據庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用於某些場合或者某些應用，在這些場合中會遠遠勝過關係型數據庫和其他的NoSQL。
4、CAP理論
這個理論是由美國著名科學家，同時也是著名互聯網企業Inktomi的創始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大會上提出的，後來Seth Gilbert 和 Nancy lynch兩人也證明了CAP理論的正確性，雖然在後來近十年的時間很多人對CAP理論提出了很多異議，但是在NoSQL的世界中，它還是非常有參考價值的。它的意思是，一個分佈式系統不能同時滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時滿足兩個。
C: Consistency 一致性
A: Availability 可用性
P:Partition Tolerance分區容錯性
CAP理論的核心是：一個分佈式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時較好的滿足兩個。
C: Consistency 一致性
對於一致性，可以分爲從客戶端和服務端兩個不同的視角。從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。一致性是因爲有併發讀寫纔有的問題，因此在理解一致性的問題時，一定要注意結合考慮併發讀寫的場景。
從客戶端角度，多進程併發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。
A: Availability 可用性
對於一個可用性的分佈式系統，每一個非故障的節點必須對每一個請求作出響應。也就是，該系統使用的任何算法必須最終終止。當同時要求分區容忍性時，這是一個很強的定義：即使是嚴重的網絡錯誤，每個請求必須終止。
好的可用性主要是指系統能夠很好的爲用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。可用性通常情況下可用性和分佈式數據冗餘，負載均衡等有着很大的關聯。
P:Partition Tolerance分區容錯性
分區容錯性和擴展性緊密相關。在分佈式應用中，可能因爲一些分佈式的原因導致系統無法正常運轉。好的分區容錯性要求能夠使應用雖然是一個分佈式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分佈式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，或者是機器之間有網絡異常，將分佈式系統分隔未獨立的幾個部分，各個部分還能維持分佈式系統的運作，這樣就具有好的分區容錯性。
滿足一致性，可用性的系統，通常在可擴展性上不太強大：傳統關係型數據庫。
滿足一致性，分區容忍必的系統，通常用戶操作響應上不太穩定：Redis、MongoDB、HBase等
滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些：使用在DNS上。
5、ACID和BASE的比較
傳統關係型數據庫系統的事務都有ACID的屬性，即原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。
原子性: 整個事務中的所有操作，要麼全部完成，要麼全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
一致性: 在事務開始之前和事務結束以後，數據庫的完整性約束沒有被破壞。
隔離性: 兩個事務的執行是互不干擾的，一個事務不可能看到其他事務運行時，中間某一時刻的數據。 兩個事務不會發生交互。
持久性: 在事務完成以後，該事務所對數據庫所作的更改便持久的保存在數據庫之中，並不會被回滾。
由於CAP理論的存在，爲了提高性能，出現了ACID的一種變種BASE：
Basic Availability：基本可用
Soft-state ：軟狀態/柔性事務，可以理解爲”無連接”的, 而 “Hard state” 是”面向連接”的
Eventual consistency：最終一致性，最終整個系統（時間和系統的要求有關）看到的數據是一致的。
有趣的是，ACID的意思是酸，而BASE卻是鹼的意思，因此這是一個對立的東西。其實，從本質上來講，酸（ACID）強調的一致性（CAP中的C），而鹼（BASE）強調是可用性（CAP中的A）。
6、一致性模型
弱一致性（Weak）：當你寫入一個新值後，讀操作在各個數據副本上不保證能讀出最新值。比如：某些cache系統，網絡遊戲其它玩家的數據和你沒什麼關係。
最終一致性（Eventually）：Eventually 是 Weak 的一種特殊情況。當你寫入一個新值後，有可能讀不出來，但在某個時間窗口之後保證最終能讀出來。比如：DNS，電子郵件、Amazon S3，Google搜索引擎這樣的系統。
強一致性（Strong）：新的數據一旦寫入，在任意副本任意時刻都能讀到新值。比如：文件系統，RDBMS，Azure Table都是強一致性的。
從這三種一致型的模型上來說，我們可以看到，Weak 和 Eventually 一般來說是異步冗餘的，而Strong一般來說是同步冗餘的，異步的通常意味着更好的性能，但也意味着更復雜的狀態控制。同步意味着簡單，但也意味着性能下降。
7、數據一致性的實現技術
①Quorum 系統NWR 策略 ：
NWR是一種在分佈式存儲系統中用於控制一致性級別的策略，應用於 Amazon Dynamo。NWR 模型將 CAP 的選擇權交給了用戶，由用戶自己選擇 CAP 中的哪兩個。其中，N 代表 N 個備份，W 代表至少寫 W 份才認爲成功，R 代表至少要讀 R 份才認爲成功。
如果 W+R>N ，是可以保證強一致性的。因爲 W+R > N， 所以 R > N-W，什麼意思呢？就是讀取的份數必須要大於未成功寫的份數，這樣至少能讀到一份最新值。
如果 W+R<=N，則能夠保證最終一致性。
如果我們要高可寫的環境，我們可以配置 W=1 R=N。這個時候只要寫任何節點成功就認爲成功，但是讀的時候必須從所有的節點都讀出數據。
如果我們要求讀的高效率，我們可以配置 W=N R=1。這個時候任何一個節點讀成功就認爲成功，但是寫的時候必須寫所有三個節點成功才認爲成功。
②兩階段提交：
英文 Two Phase Commit，也叫 2PC。兩階段提交經常用於分佈式事務，是強一致性算法。簡要的說就是分兩階段：
第一階段，主控節點（協調者）詢問所有節點（參與者）是否可以提交操作，參與者迴應 yes or no。
第二階段，協調者根據收到的響應，如果所有參與者都回應 yes，則向所有參與者發送“正式提交”的命令。參與者完成後恢復“完成”消息，協調者收集齊各節點的迴應後結束這個 Global Transaction。如果有一個拒絕則給所有參與者發送“回滾操作”。參與者回滾成功後迴應“回滾完成”，協調者收集各結點的“回滾”迴應後，取消這個 Global Transaction。
2PC說白了就是第一階段做 Vote，第二階段做決定的一個算法，相對於單庫事務來說就是在提交之前多了準備的階段。但是也存在着問題，其中一個是同步阻塞操作，這個事情必然會非常大地影響性能。另一個主要的問題是在TimeOut上。因此出現了 3PC，主要是將提交過程分爲兩步，更多描述見 Wikipedia。
③Paxos 算法
④時間戳策略
⑤向量時鐘
二、MongoDB介紹
1、簡介
是一個開源的，基於分佈式的，面向文檔存儲的非關係型數據庫。是非關係型數據庫當中功能最豐富、最像關係數據庫的。
由C++編寫，其名字來源於"humongous"這個單詞，其宗旨在於處理大量數據。
可以運行在Windows、unix、OSX、Solaris系統上，支持32位和64位應用，提供多種編程語言的驅動程序。
支持的數據結構非常鬆散，是類似json的BSON格式，通過鍵值對的形式存儲數據，可以存儲複雜的數據類型。
支持的數據類型有：null、boolean、String、objectId、32位整數、64位整數、64位浮點數、日期、正則表達式、js代碼、二進制數據、數組、內嵌文檔、最大值、最小值、未定義類型。
其中，內嵌文檔我理解的並不是.doc.txt等文件，這裏所指的文檔是mongoDB的一個存儲單元(相當於關係型數據當中的記錄)，在mongoDB中的表現形式爲{key1:value1，key2：value2}，而內嵌文檔則是這樣的形式{key1:value1,key2:{key2.1:value2.1,key2.2:value2.2}}。
mongoDB最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。
2、mongoDB的特性
面向集合存儲。數據被分組到若干集合，每個集合可以包含無限個文檔，可以將集合想象成RDBMS的表，區別是集合不需要進行模式定義。
模式自由。集合中沒有行和列的概念，每個文檔可以有不同的key，key的值不要求一致的數據類型。
支持動態查詢。mongoDB支持豐富的查詢表達式，查詢指令使用json形式表達式。
完整的索引支持。mongoDB的查詢優化器會分析查詢表達式，並生成一個高效的查詢計劃。
高效的數據存儲，支持二進制數據及大型對象（圖片、視頻等）。
支持複製和故障恢復。
自動分片以支持雲級別的伸縮性，支持水平的數據庫集羣，可動態添加額外的服務器。
支持空間索引。
查詢性能剖析。
3、 mongoDB的適用場景
網站數據：Mongo非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的複製及高度伸縮性。
緩存：由於性能很高，Mongo也適合作爲信息基礎設施的緩存層。在系統重啓之後，由Mongo搭建的持久化緩存層可以避免下層的數據源 過載。
大尺寸，低價值的數據：使用傳統的關係型數據庫存儲一些數據時可能會比較昂貴，在此之前，很多時候程序員往往會選擇傳統的文件進行存儲。
高伸縮性的場景：Mongo非常適合由數十或數百臺服務器組成的數據庫。Mongo的路線圖中已經包含對MapReduce引擎的內置支持。
用於對象及JSON數據的存儲：Mongo的BSON數據格式非常適合文檔化格式的存儲及查詢。
4、mongoDB不適用場景
要求高度事務性的系統。例如對於銀行或會計等需要大量原子性複雜事物的應用程序來說，還是需要關係型數據庫的。
傳統的商業智能應用
複雜的表級聯查詢
5、與相關數據庫的對比
