为什么索引等相同下,数据量到达一定量级时候, 会听说 mongodb 比 mysql 快.

2019-02-27 16:10:50 +08:00
 cs8814336

一直没理解为什么当数据量达到一定程度时,mysql 会很慢,mongodb 会更快.以至于我到现在还没理解什么时候用 mongodb,什么时候用 mysql,不清楚两者的优势(底层原理优势).

从开发速度来讲,mysql 现在支持 json 字段,在一定角度来看一个表有了 json 字段就跟 mongodb 文档结构开发起来差不多方便了.

从底层原理看: mysql innodb 使用 b+tree, mongdb 默认使用 wiredtiger 使用 b-tree. b-tree 和 b+tree 有各自的优点,例如 b-tree 查询不一定需要找到叶子节点才能结束所以速度会快,但是 b+tree 能通过不存储数据的节点更快区分数据.

所以我想问大家 mongdb wiredtiger 能有什么 mysql innodb 没有的功能或者优势,底层原理原因又是什么. 就是某种因为底层设计的原因,根本导致了某些功能是别的数据库是不能有的,例如说便捷的文档结构之前 mysql 没有,但是这个可能不是底层设计导致的,只是 mysql 懒了,只要等到某天有人加上了这个功能就可以了.

提前感谢大家的回答.

11226 次点击
所在节点    MySQL
73 条回复
cs8814336
2019-02-27 17:55:06 +08:00
@hhhzccc 面试这样回答的话可能就炸了
Phariel
2019-02-27 17:55:43 +08:00
用空间换时间 你要看看 mongodb 占内存占了多大
cs8814336
2019-02-27 17:59:55 +08:00
@Phariel 你说的是数据库缓存在内存是吗,这样 innodb 也有 innodb buffer pool ,这样你可能应该从 innodb buffer pool 和 mongdb 的 xx pool 做底层技术实现原理的对比?
Hstar
2019-02-27 18:01:04 +08:00
我的理解是 mysql 的事务拖累了它的速度,和底层数据结构没关系,反而和 innoDB 有很大关系
何时用 mongo 呢,按我理解就是用代码实现事务,不需要数据库层面的事务时,就用 mongo 来加速 IO
MeteorCat
2019-02-27 18:27:55 +08:00
@cs8814336 都有,而且要求延时越低越好
MeteorCat
2019-02-27 18:35:55 +08:00
@cs8814336 对了,还有 mongo 有个坑,mongo 的聚合[group,count,sum]功能性能极其差[mongo 的数据分片],如果是统计功能最好是跑定时脚本写入 MySQL 来进行统计
presoul
2019-02-27 18:53:18 +08:00
@NaVient 牛逼
bumz
2019-02-27 20:14:44 +08:00
trade-offs

对不同需求场景各自优化
底层的细节随时在变,但是 trade-offs 是不变的,不然就流失客户了
MonoLogueChi
2019-02-27 20:18:24 +08:00
MongoDB 算是 NoSQL 吧,只看查询速度的话,NoSQL 按理说应该是更快的
yuikns
2019-02-27 23:37:15 +08:00
这和底层 io 关系不大,主要是上层事务锁的问题。
单机没特别配置的话,数据量到百来 g,并行百来个 mysql 就可以歇着去了。
但是读写是问题么?其实问题主要是上层各种事务锁关联折腾的。mongodb 的优势是假设没有各种乱七八糟关系,专心做 kv store。
多机做 sharding 更不用说了。

所以楼主在问别人问题的时候,自己其实有没有用过它们…
q397064399
2019-02-28 07:16:26 +08:00
硬要选的话,还是看社区,技术实现上都是半斤八两,能出名的框架一般技术不会差到哪里去,这个时候就要看社区活跃度,以及大部分社区成员偏向使用特定的工具做什么事情,在软件框架工具选择上随大流是不会错的
leis1015
2019-02-28 07:38:16 +08:00
关键还是数据将来会怎么读
如果绝大多数都是简单查询,kv 结构的,即使复杂查询也不是需要即立刻得到结果的,用 nosql
其他情况 sql 类数据库
petelin
2019-02-28 08:22:09 +08:00
@yuikns 支持 一个 sharding 就把 MySQL 单机干哭了分库分表又不是原生支持的
题主扯的很多 把我都绕蒙了 其实就是一个是 kv 一个是支持 acid 的关系型数据库 innodb
petelin
2019-02-28 08:23:15 +08:00
另外楼上好多人 暴露智商啊 技术实现半斤八两 我可去 xxx
EKkoGG
2019-02-28 08:46:36 +08:00
MySQL 是关系型数据库
MongoDB 是非关系型数据库
种类都不一样,使用的场景也不一样。。。。
楼主谷歌 “ MySQL 和 MongoDB 的区别”
五分钟都不用就能解惑了,没必要纠结
lcj2class
2019-02-28 09:00:17 +08:00
https://www.cnblogs.com/kaleidoscope/p/9481991.html

不知道楼主那里听说的,没有银弹,都是有场景的
cs8814336
2019-02-28 09:14:10 +08:00
@leis1015 假如只有 mongodb nosql 特性原因,那么 mysql 现在有了 json 列,是不是就相当于有了 mongdb nosql 的特性呢?这样 mysql 还有容易聚合等好功能是不是就在任何场景能取代 mongodb 呢
murmur
2019-02-28 09:14:32 +08:00
mysql 该分表就分表啊
cs8814336
2019-02-28 09:19:10 +08:00
@lcj2class 感谢回答. 这个文章其实发主题之前看过了.大家都说是有场景其实我也听说了,但是到底是什么场景. 回复大多无非是事务场景,文档结构场景? 现在 mongodb 支持事务,mysql 支持 json 文档,这样乍看起来两个在互相场景又都能使用,但是性能是否有根本的差异呢? 这个根本的差异是哪种技术原因导致的呢? 好像大家都没有仔细想到底层.
cs8814336
2019-02-28 09:23:35 +08:00
@yuikns 感谢回答. 其实这个我也想过,mysql 和 mongodb 其实是类似的,只是 mysql 支持了更多一些其他的功能导致不得不维护很多东西来支持这些功能,导致设计复杂之类的. 但是这样的话,如今 mongodb 和 mysql 都支持了一些以往对方特有的东西,从外面看起来似乎相互可以换着用,假如在底层差异很大的话为什么要强行实现呢? 那假如按照这个趋势,是不是到后面就可以相互替换了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/539297

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX