mongodb入門-關系型RDMS數據庫對比及適用場景
引言
最近工作接觸到了mongodb數據庫，記錄下個人對其的理解和使用情況。雖然mongodb 出來的時間已經不短，但是相對mysql mssql oracle 這樣傳統的關系型數據庫來說還是比較年輕，接觸其的程序員應該也很少，本文從僅作介紹用。
名字看MongoDB疑似Humongous Database（網絡資料看到）。中文意思就是巨大無比的數據庫，顧名思義，MongoDB就是為處理大數據而生，以解決海量數據的存儲和高效查詢使用為使命。
說道mongodb不得不說到nosql ，因為mongo就是nosql的一種。NoSQL是Not only SQL的縮寫，NoSQL不使用SQL作為查詢語言。其數據存儲可以不需要固定的表格模式，也經常避免使用SQL的join操作，一般有水平可擴展性的特征。
no sql出現原因：
隨著web2.0的興起，關系型數據庫本身無法克服的缺陷越來越明顯：
1、對海量數據的高效率存儲和訪問的需求。
2、對數據庫的高可擴展性和高可用性的需求。
3、數據庫寫實性和讀寫時性需求
這也是nosql 或者mongo可以解決的問題。
mongodb介紹
MongoDB 是一個可擴展的高性能，開源，模式自由，介於關系數據庫和非關系數據庫之間，面向文檔的數據庫。它使用C++編寫。MongoDB特點:
a.面向集合的存儲：適合存儲對象及JSON形式的數據。
b.動態查詢：mongo支持豐富的查詢表達方式，查詢指令使用JSON形式的標記，可輕易查詢文檔中的內嵌的對象及數組。
c.完整的索引支持:包括文檔內嵌對象及數組。mongo的查詢優化器會分析查詢表達式，並生成一個高效的查詢計劃。
d.查詢監視：mongo包含一個監視工具用於分析數據庫操作性能。
e.復制及自動故障轉移：mongo數據庫支持服務器之間的數據復制，支持主-從模式及服務器之間的相互復制。復制的主要目的是提供冗余及自動故障轉移。
f.高效的傳統存儲方式：支持二進制數據及大型對象（如照片或圖片）。
g.自動分片以支持雲級別的伸縮性：自動分片功能支持水平的數據庫集群，可動態添加額外的機器。語法有點類似於面向對象的查詢語言，幾乎可以實現類似關系數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。它的特點是高性能、易部署、易使用，存儲數據非常方便。
MongoDB的特點
1、非關系型
不適用復雜的多文檔（多表）的級聯查詢，如果有這樣的需求，我們還是用關系型數據庫吧，MongoDB不適合。不合適事物型系統如銀行系統
2、模型自由(模型高度可擴展性)
MongoDB一個數據庫實例可以有多個Collection（集合）（對應關系型數據庫的表Table），一個Collection裏有多個Document（對應關系型數據庫的行Row），所謂模型自由，用關系型數據庫的話說，就是表Table的列Column的數量和類型不確定。
對於存儲在MongoDB數據庫中的文件，我們不需要知道它任何結構定義。如果需要的話，你完全可以把不同結構的文件存儲在同一個數據庫裏。
3、副本集和分片集群（Replica Sets and Sharded Clusters）
MongoDB提供副本集和分片集群技術，從先天上支持數據庫的高擴展性和高伸縮性，可以簡單的是使用基於X86的小服務器集群，提供強大的處理能力，而且很容易擴展，目前3.0版本已經支持高達50個副本集。分片集群會讓不停增長的數據始終如一的提供初始的訪問性能，而不會隨著數據的增長，系統的訪問速度越來越慢。
4、支持完全索引，包含內部對象
5、文件存儲格式為BSON（一種json擴展）
BSON（Binary Serialized document Format）存儲形式是指：存儲在集合中的文檔，被存儲為鍵-值對的行式。鍵用於標識一個文檔，為字符串類型，而值則可以是各種復雜文件類型。高效的二進制數據存儲，包括大型對象（如視頻等）
6、豐富的查詢語言、函數
提供大部分關系型sql的查詢功能，如 where limit group by max min 等
mongo使用場景
mongodb的主要目標是在鍵/值存儲方式（提供了高性能和高度伸縮性）以及傳統的RDBMS系統（豐富的功能）架起一座橋梁，集兩者的優勢於一身。mongo適用於以下場景：
a.網站數據：mongo非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的復制及高度伸縮性。
b.緩存：由於性能很高，mongo也適合作為信息基礎設施的緩存層。在系統重啟之後，由mongo搭建的持久化緩存可以避免下層的數據源過載。
c.大尺寸、低價值的數據：使用傳統的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。
d.高伸縮性的場景：mongo非常適合由數十或者數百臺服務器組成的數據庫。
e.用於對象及JSON數據的存儲：mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。
不適合的場景：
a.高度事物性的系統：例如銀行或會計系統。傳統的關系型數據庫目前還是更適用於需要大量原子性復雜事務的應用程序。
b.傳統的商業智能應用：針對特定問題的BI數據庫會對產生高度優化的查詢方式。對於此類應用，數據倉庫可能是更合適的選擇。
c.需要SQL的問題。
案例1
- 用在應用服務器的日誌記錄，查找起來比文本靈活，導出也很方便。也是給應用練手，從外圍系統開始使用MongoDB。
- 用在一些第三方信息的獲取或者抓取，因為MongoDB的schema-less，所有格式靈活，不用為了各種格式不一樣的信息專門設計統一的格式，極大的減少開發的工作。
案例2
mongodb之前有用過，主要用來存儲一些監控數據，No schema 對開發人員來說，真的很方便，增加字段不用改表結構，而且學習成本極低。
案例3
使用MongoDB做了O2O快遞應用，·將送快遞騎手、快遞商家的信息（包含位置信息）存儲在 MongoDB，然後通過 MongoDB 的地理位置查詢，這樣很方便的實現了查找附近的商家、騎手等功能，使得快遞騎手能就近接單，目前在使用MongoDB 上沒遇到啥大的問題，官網的文檔比較詳細，很給力。
選型建議（網搜資料）
經常跟一些同學討論 MongoDB 業務場景時，會聽到類似『你這個場景 mysql 也能解決，沒必要一定用 MongoDB』的聲音，的確，並沒有某個業務場景必須要使用 MongoDB才能解決，但使用 MongoDB 通常能讓你以更低的成本解決問題（包括學習、開發、運維等成本），下面是 MongoDB 的主要特性，大家可以對照自己的業務需求看看，匹配的越多，用 MongoDB 就越合適。
| MongoDB 特性 | 優勢 |
|---|---|
| 事務支持 | MongoDB 目前只支持單文檔事務，需要復雜事務支持的場景暫時不適合 |
| 靈活的文檔模型 | JSON 格式存儲最接近真實對象模型，對開發者友好，方便快速開發叠代 |
| 高可用復制集 | 滿足數據高可靠、服務高可用的需求，運維簡單，故障自動切換 |
| 可擴展分片集群 | 海量數據存儲，服務能力水平擴展 |
| 高性能 | mmapv1、wiredtiger、mongorocks（rocksdb）、in-memory 等多引擎支持滿足各種場景需求 |
| 強大的索引支持 | 地理位置索引可用於構建 各種 O2O 應用、文本索引解決搜索的需求、TTL索引解決歷史數據自動過期的需求 |
| Gridfs | 解決文件存儲的需求 |
| aggregation & mapreduce | 解決數據分析場景需求，用戶可以自己寫查詢語句或腳本，將請求都分發到 MongoDB 上完成 |
從目前阿裏雲 MongoDB 雲數據庫上的用戶看，MongoDB 的應用已經滲透到各個領域，比如遊戲、物流、電商、內容管理、社交、物聯網、視頻直播等，以下是幾個實際的應用案例。
- 遊戲場景，使用 MongoDB 存儲遊戲用戶信息，用戶的裝備、積分等直接以內嵌文檔的形式存儲，方便查詢、更新
- 物流場景，使用 MongoDB 存儲訂單信息，訂單狀態在運送過程中會不斷更新，以 MongoDB 內嵌數組的形式來存儲，一次查詢就能將訂單所有的變更讀取出來。
- 社交場景，使用 MongoDB 存儲存儲用戶信息，以及用戶發表的朋友圈信息，通過地理位置索引實現附近的人、地點等功能
- 物聯網場景，使用 MongoDB 存儲所有接入的智能設備信息，以及設備匯報的日誌信息，並對這些信息進行多維度的分析
- 視頻直播，使用 MongoDB 存儲用戶信息、禮物信息等
- ......
如果你還在為是否應該使用 MongoDB，不如來做幾個選擇題來輔助決策（註：以下內容改編自 MongoDB 公司 TJ 同學的某次公開技術分享）。
| 應用特征 | Yes / No |
|---|---|
| 應用不需要事務及復雜 join 支持 | 必須 Yes |
| 新應用，需求會變，數據模型無法確定，想快速叠代開發 | ？ |
| 應用需要2000-3000以上的讀寫QPS（更高也可以） | ？ |
| 應用需要TB甚至 PB 級別數據存儲 | ? |
| 應用發展迅速，需要能快速水平擴展 | ? |
| 應用要求存儲的數據不丟失 | ? |
| 應用需要99.999%高可用 | ? |
| 應用需要大量的地理位置查詢、文本查詢 | ？ |
如果上述有1個 Yes，可以考慮 MongoDB，2個及以上的 Yes，選擇MongoDB絕不會後悔
mongodb入門-關系型RDMS數據庫對比及適用場景