Mongodb与MySQL对⽐
在数据库存放的数据中,有⼀种特殊的键值叫做主键,它⽤于惟⼀地标识表中的某⼀条记录。也就是说,⼀个表不能有多个主键,并且主键不能为空值。
⽆论是MongoDB还是MySQL,都存在着主键的定义。
对于MongoDB来说,其主键名叫”_id”,在⽣成数据的时候,如果⽤户不主动为其分配⼀个主键的话,MongoDB会⾃动为其⽣成⼀个随机分配的值。
在MySQL中,主键的指定是在MySQL插⼊数据时指明PRIMARY KEY来定义的。当没有指定主键的时候,另⼀种⼯具 —— 索引,相当于替代了主键的功能。索引可以为空,也可以有重复,另外有⼀种不允许重复的索引叫惟⼀索引。如果既没有指定主键也没有指定索引的
话,MySQL会⾃动为数据创建⼀个。
1. 数据库的平均插⼊速率:MongoDB不指定_id插⼊ > MySQL不指定主键插⼊ > MySQL指定主键插⼊ > MongoDB指定_id插⼊。
2. MongoDB在指定_id与不指定_id插⼊时速度相差很⼤,⽽MySQL的差别却⼩很多。
分析:
1. 在指定_id或主键时,两种数据库在插⼊时要对索引值进⾏处理,并查数据库中是否存在相同的键值,这会减慢插⼊的速率。
2. 在MongoDB中,指定索引插⼊⽐不指定慢很多,这是因为,MongoDB⾥每⼀条数据的_id值都是唯⼀的。当在不指定_id插⼊数据的时候,其_id是系统⾃动计算⽣成的。MongoDB通过计算机特征值、时间、进程ID与随机数来确保⽣成的_id是唯⼀的。⽽在指定_id插⼊时,MongoDB每插⼀条数据,都需要检查此_id可不可⽤,当数据库中数据条数太多的时候,这⼀步的查询开销会拖慢整个数据库的插⼊速度。
3. MongoDB会充分使⽤系统内存作为缓存,这是⼀种⾮常优秀的特性。我们的测试机的内存有64G,在插⼊时,MongoDB会尽可能地在内存快写不进去数据之后,再将数据持久化保存到硬盘上。这也是在不指定_id插⼊的时候,MongoDB的效率遥遥领先的原因。但在指定_id插⼊时,当数据量⼀⼤内存装不下时,MongoDB就需要将磁盘中的信息读取到内存中来查重,这样⼀来其插⼊效率反⽽慢了。
4. MySQL不愧是⼀种⾮常稳定的数据库,⽆论在指定主键还是在不指定主键插⼊的情况下,其效率都差不了太多。
插⼊稳定性分析
插⼊稳定性是指,随着数据量的增⼤,每插⼊⼀定量数据时的插⼊速率情况。
在本次测试中,我们把这个指标的规模定在10w,即显⽰的数据是在每插⼊10w条数据时,在这段时间内每秒钟能插⼊多少条数据。
先呈现四张图上来:
1. MongoDB指定_id插⼊:
2. MongoDB不指定_id插⼊:
3. MySQL指定PRIMARY KEY插⼊:
4. MySQL不指定PRIMARY KEY插⼊:mongodb和mysql结合
总结:
1. 整体上的插⼊速度还是和上⼀回的统计数据类似:MongoDB不指定_id插⼊ > MySQL不指定主键插⼊ > MySQL指定主键插⼊ > MongoDB指定_id插⼊。
2. 从图中可以看出,在指定主键插⼊数据的时候,MySQL与MongoDB在不同数据数量级时,每秒插⼊的数据每隔⼀段时间就会有⼀个波动,在图表中显⽰成为规律的⽑刺现象。⽽在不指定插⼊数据时,在⼤多数情况下插⼊速率都⽐较平均,但随着数据库中数据的增多,插⼊的效率在某⼀时段有瞬间下降,随即⼜会变稳定。
3. 整体上来看,MongoDB的速率波动⽐MySQL的严重,⽅差变化较⼤。
4. MongoDB在指定_id插⼊时,当插⼊的数据变多之后,插⼊效率有明显地下降。在其他三种的插⼊测试中,从开始到结束,其插⼊的速率在⼤多数的时候都固定在⼀个标准上。
分析:
1. ⽑刺现象是因为,当插⼊的数据太多的时候,MongoDB需要将内存中的数据写进硬盘,MySQL需要重新分表。这些操作每当数据库中的数据达到⼀定量级后就会⾃动进⾏,因此每隔⼀段时间就会有⼀个明显的⽑刺。
2. MongoDB毕竟还是新⽣事物,其稳定性没有已应⽤多年的MySQL优秀。
3. MongoDB在指定_id插⼊的时候,其性能的下降还是很厉害的。
1. 在读取的数据规模不⼤时,MongoDB的查询速度真是⼀骑绝尘,甩开MySQL好远好远。
2. 在查询的数据量逐渐增多的时候,MySQL的查询速度是稳步下降的,⽽MongoDB的查询速度却有些起伏。
分析:
1. 如果MySQL没有经过查询优化的话,其查询速度就不要跟MongoDB⽐了。MongoDB可以充分利⽤系统的内存资源,我们的测试机器内存是64GB的,内存越⼤MongoDB的查询速度就越快,毕竟磁盘与内存的I/O效率不是⼀个量级的。
2. 本次实验的查询的数据也是随机⽣成的,因此所有待查询的数据都存在MongoDB的内存缓存中的概率是很⼩的。在查询
时,MongoDB需要多次将内存中的数据与磁盘进⾏交互以便查,因此其查询速率取决于其交互的次数。这样就存在这样⼀种可能性,尽管待查询的数据数⽬较多,但这段随机⽣成的数据被MongoDB以较少的次数从磁盘中取出。因此,其查询的平均速度反⽽更快⼀些。这样看来,MongoDB的查询速度波动也处在⼀个合理的范围内。
3. MySQL的稳定性还是⽏庸置疑的。
结论
1. 相⽐较MySQL,MongoDB数据库更适合那些读作业较重的任务模型。MongoDB能充分利⽤机器的内存资源。如果机器的内存资源丰富的话,MongoDB的查询效率会快很多。
2. 在带”_id”插⼊数据的时候,MongoDB的插⼊效率其实并不⾼。如果想充分利⽤MongoDB性能的话,推荐采取不带”_id”的插⼊⽅式,然后对相关字段作索引来查询。
1. MongoDB适合那些对数据库具体数据格式不明确或者数据库数据格式经常变化的需求模型,⽽且对开发者⼗分友好。
2. MongoDB官⽅就⾃带⼀个分布式⽂件系统,可以很⽅便地部署到服务器机上。MongoDB⾥有⼀个Shard的概念,就是⽅便为了服务器分⽚使⽤的。每增加⼀台Shard,MongoDB的插⼊性能也会以接近倍数的⽅式增长,磁盘容量也很可以很⽅便地扩充。
3. MongoDB还⾃带了对map-reduce运算框架的⽀持,这也很⽅便进⾏数据的统计。
MongoDB的缺陷
1. 事务关系⽀持薄弱。这也是所有NoSQL数据库共同的缺陷,不过NoSQL并不是为了事务关系⽽设计的,具体应⽤还是很需求。
2. 稳定性有些⽋缺,这点从上⾯的测试便可以看出。
3. MongoDB⼀⽅⾯在⽅便开发者的同时,另⼀⽅⾯对运维⼈员却提出了相当多的要求。业界并没有成熟的MongoDB运维经验,MongoDB 中数据的存放格式也很随意,等等问题都对运维⼈员的考验。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论