摘要：通过计算机特征值时间进程与随机数来确保生成的是唯一的。整体上来看，的速率波动比的严重，方差变化较大。的缺陷事务关系支持薄弱。一方面在方便开发者的同时，另一方面对运维人员却提出了相当多的要求。
在数据库存放的数据中，有一种特殊的键值叫做主键，它用于惟一地标识表中的某一条记录。也就是说，一个表不能有多个主键，并且主键不能为空值。无论是MongoDB还是MySQL，都存在着主键的定义。
对于MongoDB来说，其主键名叫”_id”，在生成数据的时候，如果用户不主动为其分配一个主键的话，MongoDB会自动为其生成一个随机分配的值。
在MySQL中，主键的指定是在MySQL插入数据时指明PRIMARY KEY来定义的。当没有指定主键的时候，另一种工具 —— 索引，相当于替代了主键的功能。索引可以为空，也可以有重复，另外有一种不允许重复的索引叫惟一索引。如果既没有指定主键也没有指定索引的话，MySQL会自动为数据创建一个。
存储速度对比 1. 数据库的平均插入速率：MongoDB不指定_id插入 > MySQL不指定主键插入 > MySQL指定主键插入 > MongoDB指定_id插入。 2. MongoDB在指定_id与不指定_id插入时速度相差很大，而MySQL的差别却小很多。插入稳定性是指，随着数据量的增大，每插入一定量数据时的插入速率情况。
在本次测试中，我们把这个指标的规模定在10w，即显示的数据是在每插入10w条数据时，在这段时间内每秒钟能插入多少条数据。
先呈现四张图上来：
1. MongoDB指定_id插入：
2. MongoDB不指定_id插入：
3. MySQL指定PRIMARY KEY插入：
4. MySQL不指定PRIMARY KEY插入：
整体上的插入速度还是和上一回的统计数据类似：MongoDB不指定_id插入 > MySQL不指定主键插入 > MySQL指定主键插入 > MongoDB指定_id插入。
从图中可以看出，在指定主键插入数据的时候，MySQL与MongoDB在不同数据数量级时，每秒插入的数据每隔一段时间就会有一个波动，在图表中显示成为规律的毛刺现象。而在不指定插入数据时，在大多数情况下插入速率都比较平均，但随着数据库中数据的增多，插入的效率在某一时段有瞬间下降，随即又会变稳定。
整体上来看，MongoDB的速率波动比MySQL的严重，方差变化较大。
MongoDB在指定_id插入时，当插入的数据变多之后，插入效率有明显地下降。在其他三种的插入测试中，从开始到结束，其插入的速率在大多数的时候都固定在一个标准上。
分析：毛刺现象是因为，当插入的数据太多的时候，MongoDB需要将内存中的数据写进硬盘，MySQL需要重新分表。这些操作每当数据库中的数据达到一定量级后就会自动进行，因此每隔一段时间就会有一个明显的毛刺。
MongoDB毕竟还是新生事物，其稳定性没有已应用多年的MySQL优秀。
MongoDB在指定_id插入的时候，其性能的下降还是很厉害的。
在读取的数据规模不大时，MongoDB的查询速度真是一骑绝尘，甩开MySQL好远好远。
在查询的数据量逐渐增多的时候，MySQL的查询速度是稳步下降的，而MongoDB的查询速度却有些起伏。
分析：如果MySQL没有经过查询优化的话，其查询速度就不要跟MongoDB比了。MongoDB可以充分利用系统的内存资源，我们的测试机器内存是64GB的，内存越大MongoDB的查询速度就越快，毕竟磁盘与内存的I/O效率不是一个量级的。
本次实验的查询的数据也是随机生成的，因此所有待查询的数据都存在MongoDB的内存缓存中的概率是很小的。在查询时，MongoDB需要多次将内存中的数据与磁盘进行交互以便查找，因此其查询速率取决于其交互的次数。这样就存在这样一种可能性，尽管待查询的数据数目较多，但这段随机生成的数据被MongoDB以较少的次数从磁盘中取出。因此，其查询的平均速度反而更快一些。这样看来，MongoDB的查询速度波动也处在一个合理的范围内。
MySQL的稳定性还是毋庸置疑的。
结论相比较MySQL，MongoDB数据库更适合那些读作业较重的任务模型。MongoDB能充分利用机器的内存资源。如果机器的内存资源丰富的话，MongoDB的查询效率会快很多。
在带”_id”插入数据的时候，MongoDB的插入效率其实并不高。如果想充分利用MongoDB性能的话，推荐采取不带”_id”的插入方式，然后对相关字段作索引来查询。
MongoDB适合那些对数据库具体数据格式不明确或者数据库数据格式经常变化的需求模型，而且对开发者十分友好。
MongoDB官方就自带一个分布式文件系统，可以很方便地部署到服务器机群上。MongoDB里有一个Shard的概念，就是方便为了服务器分片使用的。每增加一台Shard，MongoDB的插入性能也会以接近倍数的方式增长，磁盘容量也很可以很方便地扩充。
MongoDB还自带了对map-reduce运算框架的支持，这也很方便进行数据的统计。
MongoDB的缺陷事务关系支持薄弱。这也是所有NoSQL数据库共同的缺陷，不过NoSQL并不是为了事务关系而设计的，具体应用还是很需求。
稳定性有些欠缺，这点从上面的测试便可以看出。
MongoDB一方面在方便开发者的同时，另一方面对运维人员却提出了相当多的要求。业界并没有成熟的MongoDB运维经验，MongoDB中数据的存放格式也很随意，等等问题都对运维人员的考验。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/48337.html
摘要：通过计算机特征值时间进程与随机数来确保生成的是唯一的。整体上来看，的速率波动比的严重，方差变化较大。的缺陷事务关系支持薄弱。一方面在方便开发者的同时，另一方面对运维人员却提出了相当多的要求。 在数据库存放的数据中，有一种特殊的键值叫做主键，它用于惟一地标识表中的某一条记录。也就是说，一个表不能有多个主键，并且主键不能为空值。无论是MongoDB还是MySQL，都存在着主键的定义。对于M...
摘要：则在读取数据时将两个中文字段混淆成了一个字段，导致整个数据结构错乱。三条路子全军覆没，这让我情何以堪，好在使用的经验颇丰，通过中文的转换和切割就轻松解决了这个问题。 概述 showImg(https://segmentfault.com/img/bVylLL); 在现实场景中，由于数据来源的异构，数据源的格式往往是难以统一的，这就导致大量具有价值的数据通常是以非结构化的形式聚合在一起的...
摘要：当数据量在千万级别左右，系统运行良好，基本响应还在一分钟内。根据数据量的增长情况来看，分布式数据库会是很好的解决方案。 盖娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。 初期的 MySQL ...
摘要：当数据量在千万级别左右，系统运行良好，基本响应还在一分钟内。根据数据量的增长情况来看，分布式数据库会是很好的解决方案。 盖娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。 初期的 MySQL ...
摘要：出现的问题笔者前段时间开发一个新项目的某个功能模块要读取老游戏中某个数据库计作库连续读库中的个集合相当于的张表取数据在测试环境单次操作时是内但是并发测试情况下比如内个并发时读取库个集合的耗时能达到以上甚至且个并发请求几乎同时完成但是在我本地 出现的问题 笔者前段时间开发一个新项目的某个功能模块,要读取老游戏中某个Mongo数据库(计作A库),连续读A库中的6个集合(相当于MySQL的6...
阅读 795·2021-11-16 11:44
阅读 1896·2021-09-04 16:46
阅读 1269·2019-08-30 13:12
阅读 2264·2019-08-29 16:05
阅读 2940·2019-08-28 18:29
阅读 780·2019-08-26 13:41
阅读 3090·2019-08-26 13:34
阅读 2467·2019-08-26 10:35
