1、MongoDB的應用場景及實現原理
2、MongoDB的經常使用命令及配置
3、手寫基於MongoDB的ORM框架
4、基於MongoDB實現網絡雲盤實戰
5、MongoDB 4.0新特性linux
MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。 MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品,是非關係數據庫當中功能最豐富,最像關係數據庫的。在這裏咱們有必要先簡單介紹一下非關係型數據庫(NoSQL)程序員
NoSQL,指的是非關係型的數據庫。NoSQL 有時也稱做 Not Only SQL 的縮寫,是對不一樣於傳統的關係型數據庫的數據庫管理系統的統稱。NoSQL 用於超大規模數據的存儲。(例如谷歌或Facebook 天天爲他們的用戶收集萬億比特的數據)。這些類型的數據存儲不須要固定的模式,無需多餘操做就能夠橫向擴展。正則表達式
關係型數據庫mongodb |
NoSQL 數據庫數據庫 |
高度組織化結構化數據json |
表明着不只僅是 SQL數組 |
結構化查詢語言(SQL)緩存 |
沒有聲明性查詢語言服務器 |
數據和關係都存儲在單獨的表中網絡 |
沒有預約義的模式 |
數據操做語言,數據定義語言 |
鍵-值對存儲,列存儲,文檔存儲,圖形數據庫 |
嚴格的一致性 |
最終一致性,而非 ACID 屬性 |
基礎事務 |
非結構化和不可預知的數據 |
|
CAP 定理 |
|
高性能,高可用性和可伸縮性 |
1.3 、NoSQL 數據庫分類
類型 |
典型表明 |
特色 |
列存儲 |
Hbase Cassandra Hypertable |
顧名思義,是按照列存儲數據的。最大的特色是方便存儲結構化和半結構化的數據,方便作數據壓 縮,對針對某一列或者某幾列的 |
|
|
查詢有很是大的 IO 優點 |
文檔存儲 |
MongoDB CounchDB |
文檔存儲通常用相似 json 的格式存儲,存儲的內容是文檔型的。這樣也就有機會對某些字段創建索引,實現關係數據庫的某些功 能。 |
Key-value 存儲 |
Tokyo Cabinet/Tyrant Berkelery DB Memcache Redis |
能夠經過 key 快速查詢到其value 。通常來講, 存儲無論value 的格式,照單全收。(Redis 包含了其餘功能) |
圖存儲 |
Neo4J FlockDB |
圖形關係的最佳存儲。使用傳統 關係數據庫來解決的話性能低下,並且設計使用不方便。 |
對象存儲 |
Db4o Versant |
經過相似面嚮對象語言的語法操做數據庫,經過對象的方式存儲 數據。 |
XML 數據庫 |
Berkeley DB XML BaseX |
高效的存儲XML 數據,並存儲 XML 的 內 部 查 詢 語 法 , 比 如 XQuery,Xpath。 |
關係型數據庫術語/概念 |
MongoDB 術語/概念 |
解釋/說明 |
Database |
Database |
數據庫 |
Table |
Collection |
數據庫表/集合 |
Row |
Document |
數據記錄行/文檔 |
Column |
Field |
數據列/數據字段 |
Index |
Index |
索引 |
Table joins |
|
表關聯/MongoDB 不支持 |
Primary Key |
Object ID |
主鍵/MongoDB 自動將_id 設置爲 主鍵 |
數據類型 |
說明 |
解釋 |
舉例 |
Null |
空值 |
表示空值或者未定義的 對象 |
{「x」:null} |
Boolean |
布爾值 |
真或者假: true 或者 false |
{「x」:true} |
Integer |
整數 |
整型數值。用於存儲數值。根據你所採用的服務器,可分爲 32 位或 64 位。 |
|
Double |
浮點數 |
雙精度浮點值。 |
{「x」:3.14,」y」: 3} |
String |
字符串 |
UTF-8 字符串 |
|
Symbol |
符號 |
符號。該數據類型基本上等同於字符串類型,但不一樣的是,它通常用於採用 特殊符號類型的語言。 |
|
ObjectID |
對象 ID |
對象 ID。用於建立文檔 的 ID。 |
{「id」: ObjectId()} |
Date |
日期 |
日期時間。用 UNIX 時 間格式來存儲當前日期或時間。 |
{「date」:new Date()} |
Timestamp |
時間戳 |
從標準紀元開始的毫秒 數 |
|
Regular |
正則表達式 |
文檔中能夠包含正則表達式,遵循 JavaScript 的語法 |
{「foo」:/testdb/i} |
Code |
代碼 |
能夠包含 JavaScript 代碼 |
{「x」:function() {}} |
Undefined |
未定義 |
已廢棄 |
|
Array |
數組 |
值的集合或者列表 |
{「arr」: [「a」,」b」]} |
Binary Data |
二進制 |
用於存儲二進制數據。 |
|
Object |
內嵌文檔 |
文檔能夠做爲文檔中某 |
{「x」:{「foo」:」bar」}} |
|
|
個 key 的 value |
|
Min/Max keys |
最小/大值 |
將一個值與 BSON(二進 制的 JSON)元素的最低值和最高值相對比。 |
|
MongoDB 的集羣部署方案中有三類角色:實際數據存儲結點、配置文件存儲結點和路由接入結點。
鏈接的客戶端直接與路由結點相連,從配置結點上查詢數據,根據查詢結果到實際的存儲結點上查詢和存儲數據。MongoDB 的部署方案有單機部署、複本集(主備)部署、分片部署、複本集與分片混合部署。混合的部署方式如圖:
混合部署方式下向 MongoDB 寫數據的流程如圖:
對於複本集,又有主和從兩種角色,寫數據和讀數據也是不一樣,寫數據的過程是隻寫到主結點中,由主結點以異步的方式同步到從結點中:
讀數據則只要從任一結點中讀取,具體到哪一個結點讀取是能夠指定的:
對於 MongoDB 的分片,假設咱們以某一索引鍵(ID)爲片鍵,ID 的區間[0,50],劃分紅 5 個 chunk, 分別存儲到 3 個片服務器中,如圖所示:
假如數據量很大,須要增長片服務器時能夠只要移動 chunk 來均分數據便可。配置結點:
存儲配置文件的服務器其實存儲的是片鍵與 chunk 以及 chunk 與 server 的映射關係,用上面的數據表示的配置結點存儲的數據模型以下表:
Map1
Key range |
chunk |
[0,10) |
chunk1 |
[10,20) |
chunk2 |
[20,30) |
chunk3 |
[30,40) |
chunk4 |
[40,50) |
chunk5 |
Map2
chunk |
shard |
chunk1 |
shard1 |
chunk2 |
shard1 |
chunk3 |
shard2 |
chunk4 |
shard2 |
chunk5 |
shard3 |
路由結點:
路由角色的結點在分片的狀況下起到負載均衡的做用。1.七、MongoDB 的應用場景和不適用場景
一、適用場景
對於 MongoDB 實際應用來說,是否使用 MongoDB 須要根據項目的特定特色進行一一甄別,這就要求我們對 MongoDB 適用和不適用的場景有必定的瞭解。
根據 MongoDB 官網的說明,MongoDB 的適用場景以下:
1) 網站實時數據:MongoDB 很是適合實時的插入,更新與查詢,並具有網站實時數據存儲所需的複製及高度伸縮性。
2) 數據緩存:因爲性能很高,MongoDB 也適合做爲信息基礎設施的緩存層。在系統重啓以後,由 MongoDB
搭建的持久化緩存層能夠避免下層的數據源過載。
3) 大尺寸、低價值數據存儲:使用傳統的關係型數據庫存儲一些數據時可能會比較昂貴,在此以前,不少時候程序員每每會選擇傳統的文件進行存儲。
4) 高伸縮性場景:MongoDB 很是適合由數十或數百臺服務器組成的數據庫。MongoDB 的路線圖中已經包含對 MapReduce 引擎的內置支持。
5) 對象或 JSON 數據存儲:MongoDB 的 BSON 數據格式很是適合文檔化格式的存儲及查詢。
二、不適用場景
瞭解了 MongoDB 適用場景以後,還須要瞭解哪些場景下不適合使用 MongoDB,具體以下:
1)高度事務性系統:例如銀行或會計系統。傳統的關係型數據庫目前仍是更適用於須要大量原子性復瑣事務的應用程序。
2)傳統的商業智能應用:針對特定問題的 BI 數據庫會對產生高度優化的查詢方式。對於此類應用, 數據倉庫多是更合適的選擇。
3)須要複雜 SQL 查詢的問題。
相信經過上面的說明,你已經大體瞭解了 MongoDB 的使用規則,須要說明一點的是,MongoDB 不只僅是數據庫,更多的使用是將 MongoDB 做爲一個數據庫中間件在實際應用中合理劃分使用細節,這一點對於 MongoDB 應用來說相當重要!
MySQL
memory 內存引擎
NoSQL最大的特色:
一、默認支持分佈式(內置分佈式解決方案)
二、高性能,高可用性和可伸縮性
在NoSQL界,
MongoDB是一個最像關係型數據庫的非關係型數據庫
MongoDB應用場景
適用範圍
1)網站實時數據: 例如:日誌、Timeline、用戶行爲(代替方案:用日誌)
2)數據緩存:緩存的數據,它必定是臨時的 (關係型數據有一份已經持久化)
3)大尺寸、低價值數據存儲: 搜索引擎的圖片文件、視頻文件(結構化),
一份存磁盤、一份存Mongo
4)高伸縮性場景:機器能夠任意的增減
5)對象或JSON數據存儲: 徹底能夠選擇用Redis
不適用範圍
1)高度事務性系統: 例如:金融系統的核心數據
高機密的用戶數據(只能選擇傳統關係型數據庫)
2)傳統的商業智能應用:結構化查詢要求很是高,常常作關聯查詢統計
(若是都是單表查詢,用Java程序來實現關聯)
Map,List (id_az_a)
MongoDB 4.0 支持事務操做(分佈式事務的一種解決方案)
學習,不要總是找亂七八糟的博客
看不懂,給你們補軟肋(新東方英語)
來自文藝界
勤奮、思考(萬變不離其宗)
mongo 客戶端
mongos 路由器
mongod 數據存儲
zookeeper 分佈式協調(路由)
把整個集羣下面的全部已經註冊機器的信息,人手持一份(區塊鏈)
leader選取(leader不存配置信息,監控)
套路差很少
mongos,協調全部的mongod
統一管理配置中心
Master
副本集,認爲就是一臺存儲數據的機器(mongo),
一個副本集數據必定是一個完整的總體
Image鏡像
高可用:把一個服務部署多份(一臺壞了,另外一臺能夠頂上)
M-S
M-A-S
數據熱點:
數據的平均存儲問題(傳一個視頻,切成四份分別存到四張表裏面去)
每張表存儲的極限(遇到瓶頸)
相似於Map(拆分)Reduce(歸併)(Hadoop裏面)
怎麼切,那是策略
P2P?原來要1個小時,只須要1分鐘
分表、分區?
微觀的維度(你看不到的一個維度)
chunk(塊)-->shard(片) --> Replica Set(副本) --> Data(數據)
宏觀的維度(你能看到的)
Field(字段) --> Document(文檔) --> Collection(集合) --> DataBase(數據庫)
mongodb自3.0版本後新增了wiredTiger的數據存儲引擎, 3.2版本後默認採用的wiredTiger, 可是linux32bit(注意本身linux的系統位數)不支持此引擎
既然默認的wiredTiger不能用, 那麼採用指定引擎爲mmapv1吧
mongod --dbpath=/root/mongodb/data --logpath=/root/mongodb/log/mongodb.log --storageEngine=mmapv1
後臺啓動
mongod --dbpath=/root/mongodb/data --fork --logpath=/root/mongodb/log/mongodb.log --storageEngine=mmapv1
本地客戶端鏈接linux的mongoDb服務 mongo 192.168.25.128