MongoDBBSON格式問題有哪些

MongoDB BSON格式問題有哪些，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

增城網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),增城網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為增城千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的增城做網(wǎng)站的公司定做！

本文我們從幾個問題入手，分析和了解MongoDB的BSON格式的一些特性及使用時(shí)的注意事項(xiàng)。

MongoDB BSON格式有哪些問題

問題1：字符串與數(shù)字

{a:12}

{a:'12'}

哪個更占空間?

{a:1234}

{a:'1256'}

又是哪個更占空間?

對于第一個例子，應(yīng)該是前一個更占空間，而對于第二個例子，是后一個更占空間。具體原因是：MongoDB對數(shù)字的存儲分兩個級別，一個32位的，一是64位的，如我們上面的例子，都是在32位能表達(dá)的范圍內(nèi)，所以數(shù)字型的占用4個字節(jié)，而字符串型的占用空間為其長度加上最后一位結(jié)束符。所以第一個例子中字符串占用3個字節(jié)，第二個例子中字符串占用5個字節(jié)。

同樣的，在索引里也是一樣，不過值得注意的是，字符串與數(shù)字在排序方式上不一樣，所以在索引時(shí)，數(shù)字是按數(shù)字的方式比對大小，字符串是按字符串的方式比對大小，比如在字符串中，’12′是小于’2′的。

問題2：對象與數(shù)組

{a:1,b:2,c:3}

{d:[1,2,3]}

哪個更占空間?

可能你會覺得是第一個，因?yàn)樗雌饋黹L度更長，或者你還會覺得是因?yàn)樗嗣總€字段的key值。而實(shí)際上呢?

答案是第二個會占用更多空間，因?yàn)锽SON數(shù)據(jù)結(jié)構(gòu)在存儲數(shù)組類型時(shí)，是與對象類似的方法，比如第二條的存儲實(shí)際上相當(dāng)于這樣：

{d:{0:1,1:2,2:3}}

MongoDB BSON格式有哪些問題

問題3：_id與$natural的排序

MongoDB中有一個特殊的排序方法，叫$natural，當(dāng)你指定按$natural排序的時(shí)候，相當(dāng)于是按數(shù)據(jù)在磁盤上的組織順序排序。而當(dāng)你按自動生成的_id字段排序時(shí)，相當(dāng)于是按插入時(shí)間排序。當(dāng)不指定排序順序的時(shí)候，MongoDB是按$natural排序的。這兩個有什么差別嗎?插入順序與數(shù)據(jù)組織順序不應(yīng)該一樣嗎?答案是：有可能。

當(dāng)MongoDB中的數(shù)據(jù)有變更時(shí)，可能會導(dǎo)致數(shù)據(jù)的移動，比如你先用下面的方式寫入1000條數(shù)據(jù)：

for(var i=0;i<1000;i++)db.test.insert({_id:i,a:'1'}) 　　然后你分別使用下面命令按_id和$natural排序取出前一條結(jié)果： 　　db.test.find().sort({_id:1}).limit(1) 　　db.test.find().sort({$natural:1}).limit(1) 　　你得到的結(jié)果會是一樣的。 　　這時(shí)候你進(jìn)行一次update操作，將第一條記錄的長度變長： 　　db.test.update({},{a:'12'}) 　　再通過上面兩種不同的排序方式取第一條，你會發(fā)現(xiàn)取到的結(jié)果還是一樣的。 　　然后你再將第一條記錄變長： 　　db.test.update({},{a:'123'}) 　　再通過上面兩種不同的排序方式取第一條，這時(shí)候你會看到，通過_id排序查到的還是原來那一條，而通過$natural查到的已經(jīng)變成了第二條。這是什么原因呢? 　　當(dāng)我們執(zhí)行insert操作的時(shí)候，每條記錄的長度為31，你可以通過下面命令查看到。 　　Object.bsonsize(db.test.findOne()); 　　而當(dāng)我們通過一次update，將a值變?yōu)椤?2′時(shí)，其長度變長了1字節(jié)，變成了32。當(dāng)我們又一次將a值變?yōu)椤?23′時(shí)，其長度變成了33。那為什么記錄長度從31到32的時(shí)候，按$natural查到的第一條還是原來的，但是長度從32變到33的時(shí)候，通過$natural查到的就變了呢? 　　先說為什么變了，因?yàn)镸ongoDB在記錄長度變化后，發(fā)現(xiàn)當(dāng)前記錄所在空間后面沒有空余的空間可供其變長。那么這條記錄就會被刪除然后移動到數(shù)據(jù)集的最后。這是為什么第二次我們通過$natural查到的第一條不是原來那條的原因。因?yàn)樵瓉砟菞l已經(jīng)跑到最尾巴上去了。 　　但是為什么第一次增長長度時(shí)記錄沒有移動呢?可能你從數(shù)字31，32，33上已經(jīng)看出點(diǎn)端倪來了。對，就是內(nèi)存對齊，MongoDB每一條記錄都會做4字節(jié)的內(nèi)存對齊。所以在你剛插入的時(shí)候，記錄長度雖然只有31字節(jié)，但是MongoDB會為它分配32字節(jié)(8*4)的空間。這時(shí)候在其末尾就有一字節(jié)的空閑，當(dāng)你增長一字節(jié)的時(shí)候，這一字節(jié)的空閑正好可以用上。所以就不需要移動位置了。而第二次從32字節(jié)變成33字節(jié)，原有的空間已經(jīng)不能裝下了，所以會造成數(shù)據(jù)的移動。實(shí)際上4字節(jié)對齊，也同時(shí)造成一些空間的浪費(fèi)。同時(shí)引起數(shù)據(jù)變長后移動上的不確定性。

看完上述內(nèi)容，你們掌握MongoDB BSON格式問題有哪些的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

本文名稱：MongoDBBSON格式問題有哪些
本文URL：http://muchs.cn/article10/pidedo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、小程序開發(fā)、外貿(mào)建站、全網(wǎng)營銷推廣、用戶體驗(yàn)、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)