MongoDB BSON格式问题有哪些,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
本文我们从几个问题入手,分析和了解MongoDB的BSON格式的一些特性及使用时的注意事项。
MongoDB BSON格式有哪些问题
问题1:字符串与数字
{a:12}
{a:'12'}
哪个更占空间?
{a:1234}
{a:'1256'}
又是哪个更占空间?
对于第一个例子,应该是前一个更占空间,而对于第二个例子,是后一个更占空间。具体原因是:MongoDB对数字的存储分两个级别,一个32位的,一是64位的,如我们上面的例子,都是在32位能表达的范围内,所以数字型的占用4个字节,而字符串型的占用空间为其长度加上最后一位结束符。所以第一个例子中字符串占用3个字节,第二个例子中字符串占用5个字节。
同样的,在索引里也是一样,不过值得注意的是,字符串与数字在排序方式上不一样,所以在索引时,数字是按数字的方式比对大小,字符串是按字符串的方式比对大小,比如在字符串中,’12′是小于’2′的。
问题2:对象与数组
{a:1,b:2,c:3}
{d:[1,2,3]}
哪个更占空间?
可能你会觉得是第一个,因为它看起来长度更长,或者你还会觉得是因为它包含了每个字段的key值。而实际上呢?
答案是第二个会占用更多空间,因为BSON数据结构在存储数组类型时,是与对象类似的方法,比如第二条的存储实际上相当于这样:
{d:{0:1,1:2,2:3}}
MongoDB BSON格式有哪些问题
问题3:_id与$natural的排序
MongoDB中有一个特殊的排序方法,叫$natural,当你指定按$natural排序的时候,相当于是按数据在磁盘上的组织顺序排序。而当你按自动生成的_id字段排序时,相当于是按插入时间排序。当不指定排序顺序的时候,MongoDB是按$natural排序的。这两个有什么差别吗?插入顺序与数据组织顺序不应该一样吗?答案是:有可能。
当MongoDB中的数据有变更时,可能会导致数据的移动,比如你先用下面的方式写入1000条数据:
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'}) 再通过上面两种不同的排序方式取第一条,你会发现取到的结果还是一样的。 然后你再将第一条记录变长: db.test.update({},{a:'123'}) 再通过上面两种不同的排序方式取第一条,这时候你会看到,通过_id排序查到的还是原来那一条,而通过$natural查到的已经变成了第二条。这是什么原因呢? 当我们执行insert操作的时候,每条记录的长度为31,你可以通过下面命令查看到。 Object.bsonsize(db.test.findOne()); 而当我们通过一次update,将a值变为’12′时,其长度变长了1字节,变成了32。当我们又一次将a值变为’123′时,其长度变成了33。那为什么记录长度从31到32的时候,按$natural查到的第一条还是原来的,但是长度从32变到33的时候,通过$natural查到的就变了呢? 先说为什么变了,因为MongoDB在记录长度变化后,发现当前记录所在空间后面没有空余的空间可供其变长。那么这条记录就会被删除然后移动到数据集的最后。这是为什么第二次我们通过$natural查到的第一条不是原来那条的原因。因为原来那条已经跑到最尾巴上去了。 但是为什么第一次增长长度时记录没有移动呢?可能你从数字31,32,33上已经看出点端倪来了。对,就是内存对齐,MongoDB每一条记录都会做4字节的内存对齐。所以在你刚插入的时候,记录长度虽然只有31字节,但是MongoDB会为它分配32字节(8*4)的空间。这时候在其末尾就有一字节的空闲,当你增长一字节的时候,这一字节的空闲正好可以用上。所以就不需要移动位置了。而第二次从32字节变成33字节,原有的空间已经不能装下了,所以会造成数据的移动。实际上4字节对齐,也同时造成一些空间的浪费。同时引起数据变长后移动上的不确定性。
看完上述内容,你们掌握MongoDB BSON格式问题有哪些的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!