mongodb mysql性能比较

　　mongodbmysql性能比较

为什么要研讨MongoDB？
下图是2017年8月DB-Engines数据库的排名计算。您能够看到MongoDB在整体排名中排名第5，在Nosql数据库中排名第1。
优点:
1）社区是活跃的，有许多用户和广泛的运用程序。
2）当MongoDB有足够的内存时，一切数据都被放入内存并具有完好的索引支撑，而且查询功率很高。
3）MongoDB的分片机制支撑海量数据的存储和扩展。
缺陷:
1）不支撑买卖
2）不支撑联接，杂乱查询
经过初步研讨，MongoDB具有咱们需求的功用，可是缺陷并不影响咱们的运用程序场景，因此咱们将开端进行实践的功能压力测验。
二，压力测验功能比较
1.准备条件
1）Mysql和MongoDB数据库地点的服务器硬件环境
2）最新的数据库版别
MongoDB服务器版别:3.4.5
MongoDB客户端版别:mongo-java-driver-2.14.3
Mysql服务器版别:5.6.34
Mysql衔接器版别:mysql-connector-java-6.0.6
MongoDB运用的存储引擎wiredTiger
InnoDB，Mysql运用的存储引擎
3）数据库表的结构和索引
MongoDB索引是dateTime，而且是仅有索引。图中显现了咱们实践测验中运用的MongoDB数据结构和字段。
Mysql索引是DATETIME，PARTNER_ID，GOODS_ID，SCOPE，而且是仅有索引。图中显现了咱们实践测验中运用的Mysql数据结构和字段。
SQL句子依据datetime字段查询时刻规划
4）衔接池中的最大衔接数设置为200。sql句子被调整为最佳
200万和1000万个级别的不同查询量和不同并发量测验成果
表中显现了压力测量数据和数据库表中的成果，其总数为数百万和数千万。
3.十亿级以下具有不同查询量和不同并发量的紧缩测验成果
表中显现了压力测验数据和数据库表中记录总数为1亿个的成果。
压力测验成果剖析:
1）当每个查询中的数据量为500时，无论表中的数据总量是1000万仍是1亿，Mysql和MongoDB都能够在100个线程下同时具有等效的查询功能，而且功能杰出。均匀呼应时刻为500毫秒之内，TPS约为230。
2）当每个查询中的数据量为5000，而且表中的数据总量为数千万时，在50个线程并发的状况下，MongoDB的查询功能不到Mysql的一半，而且100个线程并发时的查询功能当均匀呼应时刻在4500毫秒左右而且表中的数据总量为1亿个时，MongoDB和Mysql在50个或更多并发状况下的功能较差。
在这种状况下，在这种状况下的简单数据模型下的时刻规划内进行等效查询的运用状况下，MongoDB在高并发条件下对很多数据的查询功能并不优于Mysql。要注意的另一点是在这种状况下，数据总量从百万级到一千万级到十亿级的改变对查询功能没有显着影响，可是它的多重增长十分敏感，因此在考虑数据库查询功能时，咱们还必须重视运用程序的单个查询量的需求。
虽然MongoDB在咱们的运用程序场景中未到达预期的功能，但咱们还简要研讨了Mysql和MongoDB的内存运用机制以及一些可能影响查询功率的内部装备。
三，Mysql和MongoDB的内存结构
1，InnoDb内存运用机制
Innodb体系结构如图所示。
用于压力测验的MySQL运用Innodb存储引擎。Innodb的两个影响查询功率的重要参数是innodb_buffer_pool_size和innodb_read_ahead_threshold。
innodb_buffer_pool_size表明Innodb缓冲池的巨细。在此示例中，Innodb缓冲池的巨细为20G。该参数的巨细能够经过命令innodb_buffer_pool_size20G指定。运用改善的LRU算法办理缓冲池。它保护一个LRU列表和一个FREE列表。FREE列表存储免费页面。数据库启动时，LRU列表为空。当需求从缓冲池进行分页时，请首先从”免费”列表中找到可用页面。假如存在，则将其放入LRU列表，不然LRU履行消除，而且消除结尾的页面以将其分配给新页面。
Innodb_read_ahead_threshold对应于数据预加载机制。Innodb_read_ahead_threshold30表明，假如按顺序读取的扩展区中的页面超越或等于此参数变量，则Innodb将异步将下一个扩展区读取到缓冲池中，例如，此参数的值为30，则当30扩展区中的页面被顺序读取，innodb线性预读将被触发，下一个扩展区将被读入内存；在变量不可用之前，当拜访扩展区的最后一页时，Innodb将决定是否将下一个扩展区放入缓冲池中。您能够在Mysql服务器上的showinnodb状态下调查经过预读和逐出而无法拜访的页面的两个值的预读取状况:
Innodb_buffer_pool_read_ahead:指示经过预读恳求进入缓冲池的页面；
Innodb_buffer_pool_read_ahead_evicted:指示由于未在缓冲池中拜访恳求而从内存中驱赶的页面数。
能够看出Mysql的缓冲池机制能够充分利用内存并具有预加载机制。在某些条件下，方针数据完全在内存中，而且还具有很好的查询功能。
2.MongoDB的存储结构和数据模型
1）在此示例中，MongoDB运用的存储引擎是WiredTiger，而且WiredTiger的结构如图所示。
WiredTigerCache完结示意图如图所示。
Wiredtiger的缓存以Btree的方式组织，每个Btree节点是一个页面，根页面是btree的根节点，内部页面是btree的中心索引节点，叶页面是真实存储的叶节点数据；btree数据按页面单位在磁盘中加载或写入磁盘。
您能够经过在装备文件中指定storage.wiredTiger.engineConfig.cacheSizeGB参数来设置引擎运用的内存量。该内存用于缓存作业集数据（索引，称号空间，未提交的写入，查询缓冲区等）。

2）数据模型
内联
MongoDB文档是无形式的，因此它们能够支撑各种数据结构。嵌入式模型也称为非规范化模型。在MongoDB中，一组相关数据能够是文档或文档的一部分。
嵌入式类型支撑存储在文档中的一组相关数据。这样做的优点是，运用程序能够经过较少的查询和更新操作来完结一些常规数据查询和更新作业。
遇到以下状况时，咱们应考虑运用嵌入式类型:
假如数据联系是1对1的包含联系，例如以下文档，则每个人都有一个联系人字段来描绘该人的联系信息。像这种1对1联系一样，运用嵌入式类型使查询和更新数据变得简单。
{
”_id”:,
“称号”:”Wilber”，
“联系人”:{
“电话”:”12345678″，
“电子邮件”:”wilber@shanghai.com”
}
}
假如数据联系是一对多的，那么您也能够考虑运用嵌入式模型。例如，在以下文档中，运用posts字段记录用户发布的一切博客。在这种状况下，假如运用程序常常经过用户名字段查询用户发布的博客信息。然后，将帖子用作嵌入式字段将是更好的挑选，这样您就能够削减许多查询操作。
{
”_id”:，
“称号”:”Wilber”，
“联系人”:{
“电话”:”12345678″，
“电子邮件”:”wilber@shanghai.com”
}，
“帖子”:[
{
“标题”:”MongoDB中的索引”，
“创立”:”2014年12月1日”，
“链接”:”www.linuxidc.com”
}，
{
“标题”:”在MongoDB中仿制”，
“创立”:”2014年12月2日”，
“链接”:”www.linuxidc.com”
}，
{
“标题”:”在MongoDB中共享”，
“创立”:”2014年12月3日”，
“链接”:”www.linuxidc.com”
}
？]
}
依据上面的描绘，能够看出，嵌入式模型能够为运用程序供给杰出的数据查询功能，由于依据嵌入式模型，一切相关数据都能够经过一个数据库操作取得。同时，嵌入式模型能够使数据更新操作变成原子写操作。可是，嵌入式模型也可能会带来一些问题。例如，文档将变得越来越大，这可能会影响数据库写操作的功能，也可能导致数据碎片。
引用
与嵌入式模型相比，参考模型也称为归一化数据模型（Normalizeddatamodels），它经过引用表明数据之间的联系。这儿也运用MongoDB文档中的图片，在此模型中，联系和拜访权限已从用户中删去，而且user_id用作指示两者之间衔接的索引。
遇到以下状况时，咱们能够考虑运用参考模型:
运用嵌入式模型一般会带来数据冗余，可是它能够进步数据查询的功率。可是，当运用程序基本上不经过嵌入式模型进行查询，或许查询功率的进步不足以补偿数据冗余引起的问题时，应考虑运用参考模型。
当需求完结杂乱的多对多联系时，能够考虑参考模型。例如，一个众所周知的例子，学生-课程-教师的联系，假如运用参考模型来完结三者之间的联系，它可能比嵌入式模型更清晰和直观，而且将削减许多冗余数据。
当需求完结杂乱的树联系时，能够考虑参考模型。
四，运用场景剖析
1.MongoDB的运用场景
1）表结构不清楚，数据不断增大
MongoDB是一个非结构化文档数据库，很简单扩展字段而不会影响原始数据。内容办理或博客渠道（例如圈子体系）存储用户谈论等。
2）更高的写入负载
MongoDB专心于高数据写入功能，而不是业务安全性，而且适用于业务体系中存在很多”低价值”数据的场景。它以json格局存储。例如，做一个日志体系。
3）数据量很大或将来会变得很大
当Mysql单表数据量到达5-10G时，其详细功能将下降。它需求履行数据的水平和笔直拆分，并完结数据库拆分的扩展。它很简单横向扩展，并更好地习惯大数据量增长的需求。
4）高可用性
它具有高可用性，自动主从切换（副本集）
不适用的场景
1）MongoDB不支撑业务操作。主张需求业务的运用程序不要运用MongoDB。
2）MongoDB当前不支撑联接操作，不主张需求杂乱查询的运用程序运用MongoDB。
2.联系数据库和非联系数据库的运用场景比较
联系数据库适用于存储结构化数据，例如用户帐户和地址:
1）这些数据一般需求进行结构化查询，例如join，此时，联系数据库将胜出。
2）这些数据的规划和增长率一般是能够预测的
3）业务性和一致性
NoSQL适用于存储非结构化数据，例如文章和注释:
1）这些数据一般用于含糊处理，例如全文搜索，机器学习
2）这些数据十分庞大，而且增长速度无法预测，
3）依据数据的特性，NoSQL数据库一般具有无限的（至少挨近）可伸缩性
4）经过键获取数据的功率很高，可是对联接或其他结构化查询的支撑相对较差。