MongoDB理論基礎

介紹

MongoDB官網：https://www.mongodb.com/

MongoDB 是一個基于【分布式文件存儲】的數據庫，它屬于NoSQL數據庫。是最像關系型數據庫的一個NoSQL數據庫

MongoDB存儲數據是key-value結構的BSON(二進制json)文檔

概念

SQL術語/概念	MongoDB術語/概念	解釋/說明
database	database	數據庫
table	collection	數據庫表/集合
row	document	數據記錄行/文檔
column	field	數據字段/域
index	index	索引
table joins		表連接,MongoDB不支持
primary key	primary key	主鍵,MongoDB自動將_id字段設置為主鍵

通過下圖實例，我們也可以更直觀的了解Mongo中的一些概念：

數據庫（database）

一個mongodb中可以建立多個數據庫。
MongoDB的默認數據庫為db，該數據庫存儲在data目錄中（安裝時，可以默認或指定）。
MongoDB的單個實例可以容納多個獨立的數據庫，每一個都有自己的集合和權限，不同的數據庫也放置在不同的文件中。

數據庫命名規范

• 不能是空字符串（"")
• 不得含有’ '（空格)、.、$、/、\和\0 (空字符)
• 應全部小寫
• 最多64字節

集合（collection）

集合就是 MongoDB 文檔組，類似于關系數據庫中的表格。

集合存在于數據庫中，沒有固定的機構；比如我們可以向集合中插入不同數據結構的文檔

{"name":"christy"}
{"name":"christy","age":"18"}
{"name":"christy","age":"18","desc":"shuai"}

一旦有文檔插入，集合就會被創建

一個collection（集合）中的所有field（域）是collection（集合）中所有document（文檔）中包含的field（域）的并集

集合命名規范

• 集合名不能是空字符串""

• 集合名不能含有\0字符（空字符)，這個字符表示集合名的結尾

• 集合名不能以"system."開頭，這是為系統集合保留的前綴

• 用戶創建的集合名字不能含有保留字符。有些驅動程序的確支持在集合名里面包含，這是因為某些系統生成的集合中包含該字符。除非你要訪問這種系統創建的集合，否則千萬不要在名字里出現$

capped collections

Capped collections就是固定大小的collection。與標準的collection不同，你必須要顯式的創建一個capped collection，指定一個 collection 的大小，單位是字節。它的存儲空間值是提前分配的。
創建一個capped collection

db.createCollection("mycollection",{capped:true, szie:99999})

• 在 capped collection 中，你能添加新的對象
• 能進行更新，然而，對象不會增加存儲空間。如果增加，更新就會失敗
• 使用 Capped Collection 不能刪除一個文檔，但可以使用 drop() 方法刪除 collection 所有的行。
  刪除之后，你必須顯式的重新創建這個 collection
• 在32bit機器中，capped collection 最大存儲為 1e9( 1X10的9次方)個字節。

文檔（document）

文檔是一組鍵值(key-value)對(即 BSON)。MongoDB 的文檔不需要設置相同的字段，并且相同的字段并不需要相同的數據類型。

對于文檔，需要注意

• 文檔中的鍵/值對是有序的
• 文檔中的值不僅可以是在雙引號里面的字符串，還可以是其他幾種數據類型（甚至可以是整個嵌入的文檔)。
• MongoDB區分類型和大小寫
• MongoDB的文檔不能有重復的鍵
• 文檔的鍵是字符串。除了少數例外情況，鍵可以使用任意UTF-8字符

文檔鍵命名規范

• 鍵不能含有\0 (空字符)。這個字符用來表示鍵的結尾
• .和$有特別的意義，只有在特定環境下才能使用
• 以下劃線"_"開頭的鍵是保留的(不是嚴格要求的)

元數據

MongoDB數據庫中名字空間 .system.* 是包含多種系統信息的特殊集合(Collection)

集合命名空間	描述
dbname.system.namespaces	列出所有名字空間
dbname.system.indexes	列出所有索引
dbname.system.profile	列出數據庫概要(profile)信息
dbname.system.users	列出所有可訪問數據庫的用戶
dbname.system.sources	包含復制對端（slave）的服務器信息和狀態

對于修改系統集合中的對象有如下限制

• 在{{system.indexes}}插入數據，可以創建索引。但除此之外該表信息是不可變的(特殊的drop index命令將自動更新相關信息)
• {{system.users}}是可修改的
• {{system.profile}}是可刪除的

數據類型

MongoDB中常用的數據類型

數據類型	說明	解釋	舉例
String	字符串	UTF-8編碼的字符串才是合法的	{“name”:“Christy”}
Integer	整型數值	隨服務器不同（32|64位）	{“age”:18}
Boolean	布爾值	存儲布爾值：真|假	{“falg”:true}
Double	浮點數	存儲浮點值	{“π”:3.14}
ObjectId	對象Id	生成文檔的id	{“_id”:ObjectId(“123456”)}
Array	數組	將數組|列表|多個值存儲到一個鍵	{“value”:[“1”,“2”]}
Timestamp	時間戳	從紀元開始的毫秒數
Object	內嵌文檔	可以作為文檔中某個key的value	{“doc”:{“name”:“Christy”}}
Null	空值	表示空值或者未定義的對象	{“value”:null}
Date	日期	用Unix日期格式來存儲當前日期或時間	{“date”:new Date()}
Regular	正則表達式	文檔中的正則表達式遵循js語法
Code	代碼	可以包含js代碼	{“js”:function(){}}
File	文件	二進制轉碼(Base64)后存儲(<16M) GridFS(>16M)	GridFS 用兩個集合來存儲一個文件：fs.files與fs.chunks

下面說明下幾種重要的數據類型。

ObjectId

ObjectId 類似唯一主鍵，可以很快的去生成和排序，包含 12 bytes，含義是：

• 前 4 個字節表示創建 unix 時間戳,格林尼治時間 UTC 時間，比北京時間晚了 8 個小時
• 接下來的 3 個字節是機器標識碼
• 緊接的兩個字節由進程 id 組成 PID
• 最后三個字節是隨機數

MongoDB 中存儲的文檔必須有一個 _id 鍵。這個鍵的值可以是任何類型的，默認是個 ObjectId 對象

由于 ObjectId 中保存了創建的時間戳，所以你不需要為你的文檔保存時間戳字段，你可以通過 getTimestamp 函數來獲取文檔的創建時間:

> var newObject = ObjectId()
> newObject.getTimestamp()
ISODate("2017-11-25T07:21:10Z")

ObjectId 轉為字符串

> newObject.str
5a1919e63df83ce79df8b38f

字符串

BSON 字符串都是 UTF-8 編碼。

時間戳

BSON 有一個特殊的時間戳類型用于 MongoDB 內部使用，與普通的 日期 類型不相關。 時間戳值是一個 64 位的值。其中：

• 前32位是一個 time_t 值（與Unix新紀元相差的秒數）
• 后32位是在某秒中操作的一個遞增的序數

在單個 mongod 實例中，時間戳值通常是唯一的。

在復制集中， oplog 有一個 ts 字段。這個字段中的值使用BSON時間戳表示了操作時間。

BSON 時間戳類型主要用于 MongoDB 內部使用。在大多數情況下的應用開發中，你可以使用 BSON 日期類型。

日期

表示當前距離 Unix新紀元（1970年1月1日）的毫秒數。日期類型是有符號的, 負數表示 1970 年之前的日期。

> var mydate1 = new Date()     //格林尼治時間
> mydate1
ISODate("2018-03-04T14:58:51.233Z")
> typeof mydate1
object
> var mydate2 = ISODate() //格林尼治時間
> mydate2
ISODate("2018-03-04T15:00:45.479Z")
> typeof mydate2
object

這樣創建的時間是日期類型，可以使用 JS 中的 Date 類型的方法。

返回一個時間類型的字符串：

> var mydate1str = mydate1.toString()
> mydate1str
Sun Mar 04 2018 14:58:51 GMT+0000 (UTC) 
> typeof mydate1str
string

或者

> Date()
Sun Mar 04 2018 15:02:59 GMT+0000 (UTC)   

MongoDB的應用場景

適用場景

更高的寫入負載

默認情況下，MongoDB更側重高數據寫入性能，而非事務安全，MongoDB很適合業務系統中有大量“低價值”數據的場景。但是應當避免在高事務安全性的系統中使用MongoDB，除非能從架構設計上保證事務安全

高可用性

MongoDB的副本集(Master-Slave)配置非常簡潔方便，此外，MongoDB可以快速響應的處理單節點故障，自動、安全的完成故障轉移。這些特性使得MongoDB能在一個相對不穩定（如云主機）的環境中，保持高可用性

數據量很大或者未來會變得很大

依賴數據庫(MySQL)自身的特性，完成數據的擴展是較困難的事，在MySQL中，當一個單表達到5-10GB時會出現明顯的性能降級，此時需要通過數據的水平和垂直拆分、庫的拆分完成擴展，使用MySQL通常需要借助驅動層或代理層完成這類需求。而MongoDB內建了多種數據分片的特性，可以很好的適應大數據量的需求

基于位置的數據查詢

MongoDB支持二維空間索引，因此可以快速及精確的從指定位置獲取數據

表結構不明確，且數據在不斷變大

在一些傳統關系型數據庫中，增加一個字段會鎖住整個數據庫/表，或者在執行一個重負載的請求時會明顯造成其它請求的性能降級。通常發生在數據表大于1G的時候（當大于1TB時更甚）。 但MongoDB是文檔型數據庫，為非結構貨的文檔增加一個新字段是很快速的操作，并且不會影響到已有數據。另外一個好處當業務數據發生變化時，是將不在需要由DBA修改表結構

沒有DBA支持

如果沒有專職的DBA，并且準備不使用標準的關系型思想（結構化、連接等）來處理數據，那么MongoDB將會是你的首選。MongoDB對于對像數據的存儲非常方便，類可以直接序列化成JSON存儲到MongoDB中。 但是需要先了解一些最佳實踐，避免當數據變大后，由于文檔設計問題而造成的性能缺陷

不適用場景

在某些場景下，MongoDB作為一個非關系型數據庫有其局限性。MongoDB不支持事務操作，所以需要用到事務的應用建議不用MongoDB，另外MongoDB目前不支持join操作，需要復雜查詢的應用也不建議使用MongoDB