MongoDB學習（一）初識NoSql及MongoDB
1.初識NoSql
1.1關係型資料庫
在認識NoSql之前先來簡單的瞭解下什麼是關係型資料庫。
關係型資料庫以行和列的二維表格形式來儲存資料，這一系列的行和列被稱為表，一組表組成了資料庫。表與表之間存在著關係，這種關係採用現實世界中實體與實體之間的關係模型。關係型資料庫並不是唯一的高階資料庫模型，也完全不是效能最優的模型，但是關係型資料庫確實是現今使用最廣泛、最容易理解和使用的資料庫模型。現在流行的大型關係型資料庫有Oracle、DB2、PostgreSQL、Microsoft SQL Server、Microsoft Access、MySQL等等。1.2非關係型資料庫
1.2.1概念
NoSql，Not only Sql，意為“不僅僅是sql”，泛指非關係型的資料庫。關係型資料庫中，表都是儲存格式化結構的資料，每個元組（可以理解為二維表中的一行，在資料庫中經常被稱為記錄）欄位的組成都是一樣的，即使不是每個元組都需要所有的欄位，但資料庫會為每個元組都分配所有的欄位，這樣的結構可以便於表與表之間進行連線等操作，但從另一個角度來說它也是關係資料庫效能瓶頸的一個因素。
而非關係資料庫以鍵值對儲存，它的結構不固定，每一個元組可以有不一樣的欄位，每個元組可以根據需要增加或減少一些自己的鍵值對，這樣就不會侷限於固定的結構，可以減少一些時間和空間的開銷。1.2.2發展
NoSQL一詞首先是CarloStrozzi在1998年提出來的，指的是他開發的一個沒有SQL功能，輕量級的，開源的關係型資料庫。這個定義跟我們現在對NoSQL的定義有很大的區別，它確確實實字如其名，指的就是“沒有SQL”的資料庫。但是NoSQL的發展慢慢偏離了初衷，我們要的不是“no sql”，而是“no relational”。
2009年初，JohanOskarsson舉辦了一場關於開源分散式資料庫的討論，Eric Evans在這次討論中再次提出了NoSQL一詞，用於指代那些非關係型的，分散式的，且一般不保證遵循ACID原則的資料儲存系統。Eric Evans使用NoSQL這個詞，並不是因為字面上的“沒有SQL”的意思，他只是覺得很多經典的關係型資料庫名字都叫“**SQL”,所以為了表示跟這些關係型資料庫在定位上的截然不同，就是用了“NoSQL“一詞。
1.2.3分類
NoSql又分為四大類資料庫：鍵值(Key-Value)儲存資料庫、列儲存資料庫、文件型資料庫、圖形(Graph)資料庫。它們的對比分析如下：|
分類 |
Examples舉例 |
典型應用場景 |
資料模型 |
優點 |
缺點 |
|
鍵值（key-value） |
Tokyo Cabinet/Tyrant， Redis， Voldemort， Oracle BDB |
內容快取，主要用於處理大量資料的高訪問負載，也用於一些日誌系統等等。 |
Key 指向 Value 的鍵值對，通常用hash table來實現 |
查詢速度快 |
資料無結構化，通常只被當作字串或者二進位制資料 |
|
列儲存資料庫 |
Cassandra, HBase, Riak |
分散式的檔案系統 |
以列簇式儲存，將同一列資料存在一起 |
查詢速度快，可擴充套件性強，更容易進行分散式擴充套件 |
功能相對侷限 |
|
文件型資料庫 |
CouchDB， MongoDB |
Web應用（與Key-Value類似，Value是結構化的，不同的是資料庫能夠了解Value的內容） |
Key-Value對應的鍵值對，Value為結構化資料 |
資料結構要求不嚴格，表結構可變，不需要像關係型資料庫一樣需要預先定義表結構 |
查詢效能不高，而且缺乏統一的查詢語法。 |
|
圖形(Graph)資料庫 |
Neo4J， InfoGrid， Infinite Graph |
社交網路，推薦系統等。專注於構建關係圖譜 |
圖結構 |
利用圖結構相關演算法。比如最短路徑定址，N度關係查詢等 |
很多時候需要對整個圖做計算才能得出需要的資訊，而且這種結構不太好做分散式的叢集方案。 |
1.2.4應用場景
1. 資料模型比較簡單
2. 需要靈活性更強的IT系統
3. 對資料庫效能要求較高
4. 不需要高度的資料一致性
5. 對於給定key，比較容易映射覆雜值的環境
1.3關係與非關係型資料庫的對比
關係型資料庫和非關係型資料庫的特性、優點、缺點及應用場景對比如下：
|
特性 |
優點 |
缺點 |
|
|
關係型資料庫 |
1.採用關係模型來組織資料 2.事務的一致性 3. 一個關係型資料庫是由關係模型（即二維表格模型）及其之間的關聯關係組成的一個數據組織 |
1.容易理解。二維表結構是非常貼近邏輯世界的一個概念，關係模型相對網狀、層次等其他模型來說更易理解 2.使用方便。標準的sql語言使得操作關係資料庫非常方便 3.易於維護。豐富的完整性（實體完整性、參照完整性和使用者定義的完整性）大大降低了資料冗餘和資料不一致的概率。 4.支援Sql及事務處理。可以進行復雜查詢，事務支援使得其能保證資料一致性 |
1.讀寫效能差。為了維護資料一致性所付出的巨大代價就是其讀寫效能比較差 2.高併發讀寫需求 3.海量資料高效率讀寫 4.固定的表結構。不擅長為有資料的表做索引或表結構的變更 |
|
非關係型(NoSql) |
1.以鍵值對儲存 2.分散式 3.一般不支援ACID特性（即資料庫事務特性：原子性、一致性、隔離性、永續性） 4.NoSql嚴格上講不是一種資料庫，應該是一種資料結構化儲存方法的集合 |
1.靈活的資料儲存模型。資料結構不固定 2.易擴充套件。資料之間無耦合，非常容易擴充套件 3. 高效能。能夠適應現代網路對資料庫高併發讀寫請求以及對海量資料的高速訪問能力，得益於它的無關係性 4.高可用。在不太影響效能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過複製模型也能實現高可用。 |
1. 不提供對SQL的支援。Sql是工業標準，不支援sql將對使用者產生一定的學習和遷移成本 2. 應用侷限性。大多數NoSql資料庫都不支援事務，現有產品功能不夠完善，附加功能如Bi和報表等也不支援 3.現有產品不成熟。缺乏類似關係型資料庫所具有的強有力的理論、技術、標準規範（如sql）等支援。 |
2.初識MongoDB
2.1簡介
通過上面的瞭解可以知道，MongoDB屬於NoSql的一種，且是屬於NoSql中的基於分散式檔案儲存的文件型資料庫。由C++語言編寫，旨在為WEB應用提供可擴充套件的高效能資料儲存解決方案。
MongoDB是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。它支援的資料結構非常鬆散，是類似json的bson（是一種類json的一種二進位制形式的儲存格式，簡稱Binary JSON）格式，因此可以儲存比較複雜的資料型別。Mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。2.2特點
它的特點是高效能、易部署、易使用，儲存資料非常方便。主要功能特性有：
* 面向集合儲存，易儲存物件型別的資料。
* 模式自由。
* 支援動態查詢。
* 支援完全索引，包含內部物件。
* 支援查詢。
* 支援複製和故障恢復。
* 使用高效的二進位制資料儲存，包括大型物件（如視訊等）。
* 自動處理碎片，以支援雲端計算層次的擴充套件性。
* 支援RUBY，PYTHON，JAVA，C++，PHP，C#等多種語言。
* 檔案儲存格式為BSON（一種JSON的擴充套件）。
* 可通過網路訪問。
2.3資料模型
一個MongoDB 例項可以包含一組資料庫，一個DataBase 可以包含一組Collection（集合），一個集合可以包含一組Document（文件）。一個Document包含一組field（欄位），每一個欄位都是一個key/value pair。
key: 必須為字串型別。
value：可以包含如下型別
1）基本型別，例如，string，int，float，timestamp，binary 等型別。
2）一個document。
3）陣列型別
2.4使用原理
所謂“面向集合”（Collection-Oriented），意思是資料被分組儲存在資料集中，被稱為一個集合（Collection)。每個集合在資料庫中都有一個唯一的標識名，並且可以包含無限數目的文件。集合的概念類似關係型資料庫（RDBMS）裡的表（table），不同的是它不需要定義任何模式（schema)。Nytro MegaRAID技術中的快閃記憶體快取記憶體演算法，能夠快速識別資料庫內大資料集中的熱資料，提供一致的效能改進。
模式自由（schema-free)，意味著對於儲存在MongoDB資料庫中的檔案，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的檔案儲存在同一個資料庫裡。儲存在集合中的文件，被儲存為鍵-值對的形式。鍵用於唯一標識一個文件，為字串型別，而值則可以是各種複雜的檔案型別。我們稱這種儲存形式為BSON（Binary Serialized Document Format）。
2.5應用場景
MongoDB 的主要目標是在鍵/值儲存方式（提供了高效能和高度伸縮性）和傳統的RDBMS 系統（具有豐富的功能）之間架起一座橋樑，它集兩者的優勢於一身，適用於以下場景：
1）網站資料：Mongo 非常適合實時的插入，更新與查詢，並具備網站實時資料儲存所需的複製及高度伸縮性。
2）快取：由於效能很高，Mongo也適合作為資訊基礎設施的快取層。在系統重啟之後，由Mongo 搭建的持久化快取層可以避免下層的資料來源過載。
3）大尺寸、低價值的資料：使用傳統的關係型資料庫儲存一些資料時可能會比較昂貴，在此之前，很多時候程式設計師往往會選擇傳統的檔案進行儲存。
4）高伸縮性的場景：Mongo非常適合由數十或數百臺伺服器組成的資料庫，Mongo 的路線圖中已經包含對MapReduce 引擎的內建支援。
5）用於物件及JSON 資料的儲存：Mongo 的BSON 資料格式非常適合文件化格式的儲存及查詢。
不適用場景：
1）高度事務性的系統：例如，銀行或會計系統。傳統的關係型資料庫目前還是更適用於需要大量原子性複雜事務的應用程式。
2）傳統的商業智慧應用：針對特定問題的BI 資料庫會產生高度優化的查詢方式。對於此類應用，資料倉庫可能是更合適的選擇。
3）需要SQL 的問題。
ps：本文知識體系由滷煮整理，術語知識來源於網路或百度百科，版權歸原作者所有，在此並無其他用途，僅為總結學習，特此宣告！