MongoDB（一）

標籤：mongodb、nosql

一、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辦公軟體的，而且它同第一種KVStore for Redis相類似。該類型的資料模型是版本化的文檔，半結構化的文檔以特定的格式儲存，比如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資料庫的四大分類表格分析

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/74/1E/wKioL1YVKYDTcjXHAALjdtnURmM540.jpg" title="2.png" alt="wKioL1YVKYDTcjXHAALjdtnURmM540.jpg" />

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的世界中，它還是非常有參考價值的。它的意思是，一個分布式系統不能同時滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時滿足兩個。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/74/1E/wKioL1YVKbSBLn_-AABvrrtGzTc142.jpg" title="3.png" alt="wKioL1YVKbSBLn_-AABvrrtGzTc142.jpg" />

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）。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/74/21/wKiom1YVKbeDABLGAAKcYiPMU40310.jpg" title="4.png" alt="wKiom1YVKbeDABLGAAKcYiPMU40310.jpg" />

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位浮點數、日期、Regex、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、與相關資料庫的對比

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/74/1E/wKioL1YVKenRCU68AAJBJ_zWq7Y940.jpg" title="5.png" alt="wKioL1YVKenRCU68AAJBJ_zWq7Y940.jpg" />

本文出自 “粗茶淡飯” 部落格，請務必保留此出處http://cuchadanfan.blog.51cto.com/9940284/1700711

MongoDB（一）