MongoDBBSON格式問題有哪些-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)公司專注于德城企業(yè)網(wǎng)站建設,響應式網(wǎng)站設計,商城網(wǎng)站建設。德城網(wǎng)站建設公司,為德城等地區(qū)提供建站服務。全流程按需定制開發(fā)，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務

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

MongoDB BSON格式有哪些問題

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

{a:12}

{a:'12'}

哪個更占空間?

{a:1234}

{a:'1256'}

又是哪個更占空間?

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

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

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

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

{d:[1,2,3]}

哪個更占空間?

可能你會覺得是第一個，因為它看起來長度更長，或者你還會覺得是因為它包含了每個字段的key值。而實際上呢?

答案是第二個會占用更多空間，因為BSON數(shù)據(jù)結構在存儲數(shù)組類型時，是與對象類似的方法，比如第二條的存儲實際上相當于這樣：

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

MongoDB BSON格式有哪些問題

問題3：_id與$natural的排序

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

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

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

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

當前標題：MongoDBBSON格式問題有哪些-創(chuàng)新互聯(lián)
文章網(wǎng)址：http://muchs.cn/article20/dhejjo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、自適應網(wǎng)站、軟件開發(fā)、網(wǎng)站內(nèi)鏈、虛擬主機、網(wǎng)站制作

廣告

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