最近工做接觸到了mongodb數據庫,記錄下我的對其的理解和使用狀況。雖然mongodb 出來的時間已經不短,可是相對mysql mssql oracle 這樣傳統的關係型數據庫來講仍是比較年輕,接觸其的程序員應該也不多,本文從僅做介紹用。mysql
名字看MongoDB疑似Humongous Database(網絡資料看到)。中文意思就是巨大無比的數據庫,顧名思義,MongoDB就是爲處理大數據而生,以解決海量數據的存儲和高效查詢使用爲使命。程序員
說道mongodb不得不說到nosql ,由於mongo就是nosql的一種。NoSQL是Not only SQL的縮寫,NoSQL不使用SQL做爲查詢語言。其數據存儲能夠不須要固定的表格模式,也常常避免使用SQL的join操做,通常有水平可擴展性的特徵。web
no sql出現緣由:sql
隨着web2.0的興起,關係型數據庫自己沒法克服的缺陷愈來愈明顯:
一、對海量數據的高效率存儲和訪問的需求。
二、對數據庫的高可擴展性和高可用性的需求。
三、數據庫寫實性和讀寫時性需求mongodb
這也是nosql 或者mongo能夠解決的問題。數據庫
MongoDB 是一個可擴展的高性能,開源,模式自由,介於關係數據庫和非關係數據庫之間,面向文檔的數據庫。它使用C++編寫。MongoDB特色:
a.面向集合的存儲:適合存儲對象及JSON形式的數據。
b.動態查詢:mongo支持豐富的查詢表達方式,查詢指令使用JSON形式的標記,可輕易查詢文檔中的內嵌的對象及數組。
c.完整的索引支持:包括文檔內嵌對象及數組。mongo的查詢優化器會分析查詢表達式,並生成一個高效的查詢計劃。
d.查詢監視:mongo包含一個監視工具用於分析數據庫操做性能。
e.複製及自動故障轉移:mongo數據庫支持服務器之間的數據複製,支持主-從模式及服務器之間的相互複製。複製的主要目的是提供冗餘及自動故障轉移。
f.高效的傳統存儲方式:支持二進制數據及大型對象(如照片或圖片)。
g.自動分片以支持雲級別的伸縮性:自動分片功能支持水平的數據庫集羣,可動態添加額外的機器。語法有點相似於面向對象的查詢語言,幾乎能夠實現相似關係數據庫單表查詢的絕大部分功能,並且還支持對數據創建索引。它的特色是高性能、易部署、易使用,存儲數據很是方便。json
一、非關係型
不適用複雜的多文檔(多表)的級聯查詢,若是有這樣的需求,咱們仍是用關係型數據庫吧,MongoDB不適合。不合適事物型系統如銀行系統
二、模型自由(模型高度可擴展性)
MongoDB一個數據庫實例能夠有多個Collection(集合)(對應關係型數據庫的表Table),一個Collection裏有多個Document(對應關係型數據庫的行Row),所謂模型自由,用關係型數據庫的話說,就是表Table的列Column的數量和類型不肯定。
對於存儲在MongoDB數據庫中的文件,咱們不須要知道它任何結構定義。若是須要的話,你徹底能夠把不一樣結構的文件存儲在同一個數據庫裏。
三、副本集和分片集羣(Replica Sets and Sharded Clusters)
MongoDB提供副本集和分片集羣技術,從先天上支持數據庫的高擴展性和高伸縮性,能夠簡單的是使用基於X86的小服務器集羣,提供強大的處理能力,並且很容易擴展,目前3.0版本已經支持高達50個副本集。分片集羣會讓不停增加的數據始終如一的提供初始的訪問性能,而不會隨着數據的增加,系統的訪問速度愈來愈慢。
四、支持徹底索引,包含內部對象
五、文件存儲格式爲BSON(一種json擴展)
BSON(Binary Serialized document Format)存儲形式是指:存儲在集合中的文檔,被存儲爲鍵-值對的行式。鍵用於標識一個文檔,爲字符串類型,而值則能夠是各類複雜文件類型。高效的二進制數據存儲,包括大型對象(如視頻等)
六、豐富的查詢語言、函數
提供大部分關係型sql的查詢功能,如 where limit group by max min 等數組
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 格式存儲最接近真實對象模型,對開發者友好,方便快速開發迭代 |
高可用複製集 | 知足數據高可靠、服務高可用的需求,運維簡單,故障自動切換 |
可擴展分片集羣 | 海量數據存儲,服務能力水平擴展 |
高性能 | mmapv一、wiredtiger、mongorocks(rocksdb)、in-memory 等多引擎支持知足各類場景需求 |
強大的索引支持 | 地理位置索引可用於構建 各類 O2O 應用、文本索引解決搜索的需求、TTL索引解決歷史數據自動過時的需求 |
Gridfs | 解決文件存儲的需求 |
aggregation & mapreduce | 解決數據分析場景需求,用戶能夠本身寫查詢語句或腳本,將請求都分發到 MongoDB 上完成 |
從目前阿里雲 MongoDB 雲數據庫上的用戶看,MongoDB 的應用已經滲透到各個領域,好比遊戲、物流、電商、內容管理、社交、物聯網、視頻直播等,如下是幾個實際的應用案例。
若是你還在爲是否應該使用 MongoDB,不如來作幾個選擇題來輔助決策(注:如下內容改編自 MongoDB 公司 TJ 同窗的某次公開技術分享)。
應用特徵 | Yes / No |
---|---|
應用不須要事務及複雜 join 支持 | 必須 Yes |
新應用,需求會變,數據模型沒法肯定,想快速迭代開發 | ? |
應用須要2000-3000以上的讀寫QPS(更高也能夠) | ? |
應用須要TB甚至 PB 級別數據存儲 | ? |
應用發展迅速,須要能快速水平擴展 | ? |
應用要求存儲的數據不丟失 | ? |
應用須要99.999%高可用 | ? |
應用須要大量的地理位置查詢、文本查詢 | ? |
若是上述有1個 Yes,能夠考慮 MongoDB,2個及以上的 Yes,選擇MongoDB毫不會後悔