資訊專欄INFORMATION COLUMN
摘要：和中存儲的文檔必須有一個鍵。這是的創(chuàng)建方式導(dǎo)致的。由于時間戳在前，這意味著大致會按照插入的順序排列。前字節(jié)保證了同一秒鐘不同機(jī)器不同進(jìn)程產(chǎn)生的是唯一的。如果驅(qū)動程序允許服務(wù)器生成，那么將需要多帶帶的查詢，以確定插入的文檔中的值。
_id和ObjectId
MongoDB 中存儲的文檔必須有一個"_id" 鍵。這個鍵的值可以是任何類型的，默認(rèn)是個ObjectId 對象。在一個集合里面，每個文檔都有唯一的"_id" 值，來確保集合里面每個文檔都能被唯一標(biāo)識。如果有兩個集合的話，兩個集合可以都有一個值為123 的"_id" 鍵，但是每個集合里面只能有一個"_id" 是123 的文檔。
ObjectIdObjectId 是"_id" 的默認(rèn)類型。它設(shè)計(jì)成輕量型的，不同的機(jī)器都能用全局唯一的同種方法方便地生成它。這是MongoDB 采用ObjectId，而不是其他比較常規(guī)的做法（比如自動增加的主鍵）的主要原因，因?yàn)樵诙鄠€服務(wù)器上同步自動增加主鍵值既費(fèi)力還費(fèi)時。MongoDB 從一開始就設(shè)計(jì)用來作為分布式數(shù)據(jù)庫，處理多個節(jié)點(diǎn)是一個核心要求。后面會看到ObjectId 類型在分片環(huán)境中要容易生成得多。
ObjectId 使用12 字節(jié)的存儲空間，每個字節(jié)兩位十六進(jìn)制數(shù)字，是一個24 位的字符串。由于看起來很長，不少人會覺得難以處理。但關(guān)鍵是要知道這個長長的ObjectId 是實(shí)際存儲數(shù)據(jù)的兩倍長。
如果快速連續(xù)創(chuàng)建多個ObjectId，會發(fā)現(xiàn)每次只有最后幾位數(shù)字有變化。另外，中間的幾位數(shù)字也會變化（要是在創(chuàng)建的過程中停頓幾秒鐘）。這是ObjectId 的創(chuàng)建方式導(dǎo)致的。12 字節(jié)按照如下方式生成：
前4 個字節(jié)是從標(biāo)準(zhǔn)紀(jì)元開始的時間戳，單位為秒。這會帶來一些有用的屬性。時間戳，與隨后的. 5 個字節(jié)組合起來，提供了秒級別的唯一性。由于時間戳在前，這意味著ObjectId 大致會按照插入的順序排列。這對于某些方面很有用，如將其作為索引提高效率，但是這個是沒有保證的，僅僅是“大致”。這4 個字節(jié)也隱含了文檔創(chuàng)建的時間。絕大多數(shù)驅(qū)動都會公開一個方法從ObjectId 獲取這個信息。因?yàn)槭褂玫氖钱?dāng)前時間，很多用戶擔(dān)心要對服務(wù)器進(jìn)行時間同步。其實(shí)沒有這個必要，因?yàn)闀r間戳的實(shí)際值并不重要，只要其總是不停增加就好了（每秒一次）。
接下來的3 字節(jié)是所在主機(jī)的唯一標(biāo)識符。通常是機(jī)器主機(jī)名的散列值。這樣就可以確保不同主機(jī)生成不同的ObjectId，不產(chǎn)生沖突。
為了確保在同一臺機(jī)器上并發(fā)的多個進(jìn)程產(chǎn)生的ObjectId 是唯一的，接下來的兩字節(jié)來自產(chǎn)生ObjectId 的進(jìn)程標(biāo)識符（PID）。
前9 字節(jié)保證了同一秒鐘不同機(jī)器不同進(jìn)程產(chǎn)生的ObjectId 是唯一的。后3 字節(jié)就是一個自動增加的計(jì)數(shù)器，確保相同進(jìn)程同一秒產(chǎn)生的ObjectId 也是不一樣的。同一秒鐘最多允許每個進(jìn)程擁有2563（16 777 216）個不同的ObjectId。
自動生成_id前面講到，如果插入文檔的時候沒有"_id" 鍵，系統(tǒng)會自動幫你創(chuàng)建一個?？梢杂蒑ongoDB 服務(wù)器來做這件事情，但通常會在客戶端由驅(qū)動程序完成。理由如下。
雖然ObjectId 設(shè)計(jì)成輕量型的，易于生成，但是畢竟生成的時候還是產(chǎn)生開銷。在客戶端生成體現(xiàn)了MongoDB 的設(shè)計(jì)理念：能從服務(wù)器端轉(zhuǎn)移到驅(qū)動程序來做的事，就盡量轉(zhuǎn)移。這種理念背后的原因是，即便是像MongoDB 這樣的可擴(kuò)展數(shù)據(jù)庫，擴(kuò)展應(yīng)用層也要比擴(kuò)展數(shù)據(jù)庫層容易得多。將事務(wù)交由客戶端來處理，就減輕了數(shù)據(jù)庫擴(kuò)展的負(fù)擔(dān)。
在客戶端生成ObjectId，驅(qū)動程序能夠提供更加豐富的API。例如，驅(qū)動程序可以有自己的insert 方法，可以返回生成的ObjectId，也可以直接將其插入文檔。如果驅(qū)動程序允許服務(wù)器生成ObjectId，那么將需要多帶帶的查詢，以確定插入的文檔中的"_id" 值。
原文：2.6.6 _id和ObjectId
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/18937.html
摘要：簡述與同為數(shù)據(jù)庫但是為數(shù)據(jù)庫而為文檔型數(shù)據(jù)庫存儲的是文檔的二進(jìn)制化內(nèi)部執(zhí)行引擎為解釋器把文檔存儲成結(jié)構(gòu)在查詢時轉(zhuǎn)換為對象并可以通過熟悉的語法來操作的安裝啟動在上直接下載解壓運(yùn)行即可本身是已編譯好的二進(jìn)制可執(zhí)行文件如果報錯說明你的服務(wù)器和 簡述 mongoDB與redis同為noSql數(shù)據(jù)庫,但是redis為kv數(shù)據(jù)庫(key/value),而mongoDB為文檔型數(shù)據(jù)庫存儲的是文檔(B...
摘要：反范式化與范式化相反將每個文檔所需的數(shù)據(jù)都嵌入在文檔內(nèi)部。決定何時采用范式化何時采用反范式化時比較困難的。范式化能夠提高數(shù)據(jù)寫入速度，反范式化能夠提高數(shù)據(jù)讀取速度。 原文地址：http://pwhack.me/post/2014-06-25-1 轉(zhuǎn)載注明出處 本文摘錄自《MongoDB權(quán)威指南》第八章，可以徹底回答以下兩個問題： http://segmentfault.com/...
摘要：使用可以實(shí)現(xiàn)在一個中填充其他的。表示關(guān)聯(lián)注意被關(guān)聯(lián)的的必須是和才有效。封裝了很多查詢的方法，使得對數(shù)據(jù)庫的操作變得簡單啦。這里分享一下方法用法。類型的時，格式如為表示不填充，為時表示填充。類型，可選，指定附加的查詢條件。 Mongoose 是 MongoDB 的 ODM(Object Document Mapper)。 什么是ODM? 其實(shí)和ORM(Object Relational...
閱讀 3937·2021-11-22 09:34
閱讀 1506·2021-11-04 16:10
閱讀 1739·2021-10-11 10:59
閱讀 3286·2019-08-30 15:44
閱讀 2049·2019-08-30 13:17
閱讀 3459·2019-08-30 11:05
閱讀 756·2019-08-29 14:02
閱讀 2631·2019-08-26 13:34
