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

[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 懒了，只要等到某天有人加上了这个功能就可以了.

提前感谢大家的回答．

[514146235]

mongo 和 mysql 不能类比吧。场景不一样。mongo 是不支持事务的。虽然新版也支持了。但就好像 mysql 也是新版才支持的 json。干什么事情选什么工具。

如果你是个人业务，那么你可以闭着眼睛选。

[cs8814336]

@514146235 任何事情都有优缺点的，你在说不能类比的时候，暗中其实也说了，mongdb 是用在不支持事务的场景的，而 mysql 可以用在. 目的在于讨论是不是某一方可以完全替代另外一方，假如不是说下底层技术理由．

[cs8814336]

@514146235 其实我也是看到新版的发展，才越来越发现我对这 2 个数据库应用的地点越来越模糊，所以特来此请教一下

[jorneyr]

MongoDB 来个多表联合查询 =_=!!!

[baojiweicn2]

在我的实践中 mongo 多半是要比 mysql 慢的

[baojiweicn2]

mysql 做好索引还是很快的

[NaVient]

PostgreSQL 牛比一统江湖

[jason19659]

mongodb 这类的好像占得空间也大得多吧。。

[janxin]

@baojiweicn2 我们实践是 mongo 是比 mysql 快的，主要还是看场景啦

[hilbertz]

mongodb 连 acid 都实现不了，根本不是一个层次的东西，要快的话，可以用内存数据库

[xkeyideal]

@jorneyr 写起来很麻烦，不代表不能写

[ke1e]

mongodb 会将热点数据存储在内存中，这也是它需要大量内存的原因。所以你的同一条查询语句第二次会比第一次快很多

[nosay]

如果不知道是是用 mongodb 还是 mysql 的话，一般无脑上 mysql 就对了。

[cs8814336]

@ke1e 这个 innodb 也会有 innodb pool buffer

[cs8814336]

@hilbertz 你的回答让我认为 mysql 是完美取代 mongdb 的

[cs8814336]

@baojiweicn2 两个数据库都是有索引的

[cs8814336]

@janxin 什么场景 mongdb 会比 mysql 快

[MeteorCat]

游戏的频繁写入用 MongoDB 好点

[cs8814336]

@MeteorCat 频繁写入是大量插入的还是大量修改？　这样从底层分析是什么导致了这个点呢

[hhhzccc]

无脑 mysql。

[cs8814336]

@hhhzccc 面试这样回答的话可能就炸了

[Phariel]

用空间换时间 你要看看 mongodb 占内存占了多大

[cs8814336]

@Phariel 你说的是数据库缓存在内存是吗，这样 innodb 也有 innodb buffer pool ,这样你可能应该从 innodb buffer pool 和 mongdb 的 xx pool 做底层技术实现原理的对比？

[Hstar]

我的理解是 mysql 的事务拖累了它的速度，和底层数据结构没关系，反而和 innoDB 有很大关系
何时用 mongo 呢，按我理解就是用代码实现事务，不需要数据库层面的事务时，就用 mongo 来加速 IO

[MeteorCat]

@cs8814336 都有，而且要求延时越低越好

[MeteorCat]

@cs8814336 对了，还有 mongo 有个坑，mongo 的聚合[group，count，sum]功能性能极其差[mongo 的数据分片]，如果是统计功能最好是跑定时脚本写入 MySQL 来进行统计

[presoul]

@NaVient 牛逼

[bumz]

trade-offs

对不同需求场景各自优化
底层的细节随时在变，但是 trade-offs 是不变的，不然就流失客户了

[MonoLogueChi]

MongoDB 算是 NoSQL 吧，只看查询速度的话，NoSQL 按理说应该是更快的

[yuikns]

这和底层 io 关系不大，主要是上层事务锁的问题。
单机没特别配置的话，数据量到百来 g，并行百来个 mysql 就可以歇着去了。
但是读写是问题么？其实问题主要是上层各种事务锁关联折腾的。mongodb 的优势是假设没有各种乱七八糟关系，专心做 kv store。
多机做 sharding 更不用说了。

所以楼主在问别人问题的时候，自己其实有没有用过它们…

[q397064399]

硬要选的话，还是看社区，技术实现上都是半斤八两，能出名的框架一般技术不会差到哪里去，这个时候就要看社区活跃度，以及大部分社区成员偏向使用特定的工具做什么事情，在软件框架工具选择上随大流是不会错的

[leis1015]

关键还是数据将来会怎么读
如果绝大多数都是简单查询，kv 结构的，即使复杂查询也不是需要即立刻得到结果的，用 nosql
其他情况 sql 类数据库

[petelin]

@yuikns 支持 一个 sharding 就把 MySQL 单机干哭了分库分表又不是原生支持的
题主扯的很多 把我都绕蒙了 其实就是一个是 kv 一个是支持 acid 的关系型数据库 innodb

[petelin]

另外楼上好多人 暴露智商啊 技术实现半斤八两 我可去 xxx

[EKkoGG]

MySQL 是关系型数据库
MongoDB 是非关系型数据库
种类都不一样，使用的场景也不一样。。。。
楼主谷歌 “ MySQL 和 MongoDB 的区别”
五分钟都不用就能解惑了，没必要纠结

[lcj2class]

https://www.cnblogs.com/kaleidoscope/p/9481991.html

不知道楼主那里听说的，没有银弹，都是有场景的

[cs8814336]

@leis1015 假如只有 mongodb nosql 特性原因，那么 mysql 现在有了 json 列，是不是就相当于有了 mongdb nosql 的特性呢？这样 mysql 还有容易聚合等好功能是不是就在任何场景能取代 mongodb 呢

[murmur]

mysql 该分表就分表啊

[cs8814336]

@lcj2class 感谢回答. 这个文章其实发主题之前看过了．大家都说是有场景其实我也听说了，但是到底是什么场景. 回复大多无非是事务场景，文档结构场景? 现在 mongodb 支持事务，mysql 支持 json 文档，这样乍看起来两个在互相场景又都能使用，但是性能是否有根本的差异呢？ 这个根本的差异是哪种技术原因导致的呢? 好像大家都没有仔细想到底层.

[cs8814336]

@yuikns 感谢回答. 其实这个我也想过,mysql 和 mongodb 其实是类似的，只是 mysql 支持了更多一些其他的功能导致不得不维护很多东西来支持这些功能，导致设计复杂之类的. 但是这样的话，如今 mongodb 和 mysql 都支持了一些以往对方特有的东西，从外面看起来似乎相互可以换着用,假如在底层差异很大的话为什么要强行实现呢? 那假如按照这个趋势，是不是到后面就可以相互替换了

[cs8814336]

@petelin mongodb 现在也支持事务，mysql 也支持 json 结构了

[cs8814336]

@bumz 感谢回答．这个我是赞成的，自从我陷入这个主题的追索之中我就尝试通过往这个方向想，来跳出这条路

[itskingname]

@jorneyr 在 MongoDB 里面使用 aggregate 配合$lookup 关键字就可以实现联集合查询。

[passerbytiny]

mysql 是关系型数据库，mongodb 是 NoSql 数据库。虽然 NoSql 在早期推广的时候总是提对象数据库要替代关系数据库，但是现在架构师一般同时使用二者。楼主可以结案了。

[cs8814336]

@itskingname 感谢回答，其实现在 mysql 和 mongodb 互相很多功能都有相互实现了，但是楼上很多的回答都只是停留在很久以前的思维．有人会说实现也只是一部分或者速度没那么好，但是是因为该数据库开发者懒而已吗？还是说是因为底层的某些原因导致了他不可能实现得有别人好呢？　更细的没指出

[gnozix]

MongoDB 的需要多表联查的地方直接爆炸，我们涉及多表的地方都使用 pg 了，以查询为主的地方还是 MongoDB 用起来舒服。

[cs8814336]

@passerbytiny 感谢回答．是啊，我以前的公司也是 2 个都使用，而且在同一个场景的 2 套数据一个使用了 mysql 一个使用 mongodb. 具体是没事务的，只是用来存放游戏设备激活数据．　那假如不需要事务，为什么 mongodb 会比 mysql 快呢，我现在暂定看到一个文章只是说了 b-tree 不需要每次遍历到叶子节点，b+tree 则需要．但是这也是有可能，不是平均情况，是很模糊的. 所以到底是什么场景用什么,而为什么不能用另外一个,还是一头雾水

[EPr2hh6LADQWqRVH]

很多人鹦鹉学舌， “ MySQL 是关系型，MongoDB 是非关系型”， 根本没有思考， 手里有个锤子，一切看起来就都像钉子

首先必须明确，这个世界上是没有魔法的，想要实现一定的功能，路径很大程度上是相似的。在数据库这个领域，无非就是各类索引树，缓存这种平淡无奇的东西。

以我的观点，SQL 世界和 MongoDB 的分歧主要是理解数据的方式不一样，SQL 以表的形式理解，而 Mongo 以文档(树)的形式理解。 换句话说 “ MongoDB 是文档型数据库(Document)， 而 MySQL 是表格型数据库(Tabular)”。

SQL 世界对 JSON 的支持普遍来讲都是隔靴搔痒，很多都是直接把 JSON 数据简单存起来，等用到的时候再现场 parse，根本鸡肋，更不用说还要把对 JSON 这种层次树状数据的精细操作按一种蹩脚的方言写成一种扁平的 SQL 形式，简直就是吃屎。就像让你写篇文章，只能用 Excel 表，或者用文字语言描述一个大型表格一样。

MongoDB 在底层数据是一种叫 BSON 的东西，和字面意思差不多，是 JSON 数据的二进制化，让这种树状数据能够更好地被底层处理，提升效率。在查询语言的角度，也对精细操作 JSON 数据下了很多功夫，这一点其实才是 SQL 数据库难以匹敌和超越的。

对于 JSON 的支持，有一个试金石，看对 JSON 数据的支持是不是走心了，就是看对于 JSON 内部的字段，能不能建索引。

一点理解，希望有用。

[troywinter]

#47 是正解，很多人喷 MongoDB 的联表查询，对不起，喷到这个点说明你在用关系型的方式用 MongoDB，那你可以随意喷。文档型的 Data Modeling 和关系型的 Data Modeling 当然是完全不同的，甚至可以说是两种完全不同的范式，用 MongoDB 处理关系型的 Model 当然效率好不到哪去。

[EKkoGG]

@avastms
想必我就是层主说的鹦鹉学舌的一派了，但我的初衷只是提供一个引子，如果楼主能在搜索引擎查询下关系型与非关系型数据库的区别，应该是能得到与你回复一样的答案的。所以没必要偷偷 DISS 别人，大家都是想给点帮助楼主而已。

[troywinter]

很多人说 PG 和 MySQL 也可以存 json，又要说一声对不起了，这玩意就像 MongoDB 也可以做关系型的 Modeling 和联表查询以及最近加入的事务，有这个东西不是说我有你就应该这么用，有和做的有多好是完全不一样的，MongoDB 的计算引擎在处理 json 方面确实是我见过最完善的，很多人喷都喷不到点子上。

另外，回答下楼主的问题，MySQL 适合结构化数据，MongoDB 适合非结构化数据，就是这么简单，关系型数据库是万能的，非常的灵活，但性能？？？ 对不起，往左 NewSQL，往右各类 NoSQL。

[liprais]

@troywinter 用过 pg 么...........
"GIN indexes can be used to efficiently search for keys or key/value pairs occurring within a large number of jsonb documents (datums). Two GIN "operator classes" are provided, offering different performance and flexibility trade-offs."

https://www.postgresql.org/docs/9.4/datatype-json.html

[karllynn]

@troywinter 你用过 pg 么，就一顿瞎扯

mongo 自带了集群支持，4.0 以后也支持了多文档事务，可以用$lookup 来 join 查询；而关系型这边，pg 的 json 支持已经很成熟了，json 字段可以建立索引。NoSQL 和传统 DBMS 早就开始融合，你们还活在 5 年前么？？？ TIDB 的出现更是直接简化了这些乱七八糟的东西，未来应该选型一个分布式关系型数据库就能解决大部分瓶颈了，只是由于分布式固有的 CPA 问题，仍然不会有银弹。

[troywinter]

@liprais #51 用过，我大学的导师也是当年在贝尔实验室搞数据库的，大学也接触过不少数据库相关的知识，记得没错的话 pg 在 9.2 版本中加入的 json，9.4 加入的 jsonb，有相对完善的 json operator，但我的建议是如果你没有深入的数据库调优经验和文件系统调优经验，pg has poor performance out of box，这种情况下还是 MongoDB 和 MySQL 结合比较适合。

[cs8814336]

@avastms 感谢回答.这是对我很有用的回答,接下来我可能需要看下 bson 是否就是那个关键原因了

[abcbuzhiming]

@cs8814336 别吹 Mongdb 的事务。那和 ACID 这个级别差的远了

[mysunshinedreams]

MongoDB 太吃内存了，优点就是可用性好，适合文档之间不用联合查询，不需要事务的。
如果需要联合查询，那酸爽。。。

[liprais]

@troywinter 功能跟性能是两个不同的概念

[reus]

@avastms PostgreSQL 有个 jsonb，就是和 bson 一样的二进制 json 类型，而且支持建立索引，例如对某个 jsonb 字段 foo，可以建立 foo #> '{key1, key2, key3}' 这样的索引。至少对 json 这种结构的数据的读写、索引都毫无问题，可以完美替代 mongodb。amazon 不提供 mongodb 之后，提供的文档数据库就是用 PostgreSQL 做后端。

[mysunshinedreams]

而且 MongoDB 地理索引做的比较好，文字索引跟 ES 差的很远，分片现在貌似还是不能回滚，不过就是方便，不论是主从还是分片，都是现成的，单表性能也还行。

[reus]

@troywinter 现在都 pg 11 了，最近几个版本进步很快，不要刻舟求剑。

[reus]

想结合关系数据库和文档数据库的优点，请使用 PostgreSQL。

[huiyifyj]

MySQL 这种关系数据库，适合面向对象语言，有“类”概念的语言，c++，Java 这种。MongoDB 是非关系型数据库，文档式的存储，所以适合存储 JSON，适合 js，go 这类。

[mortonnex]

no offence
楼主的"听说"让人觉得不妥,任何事只是听别人说而没有自己的实践和思考那么将毫无意义
如果是我,可能会去做 benchmark,也会去研究 mongodb 使用的索引类型,而不是上论坛发这样的水帖

[xhinliang]

@mortonnex 楼主是有自己的思考的，所以我觉得这个套路还挺有意义的。
如果每个人都自己去做 benchmark 而没有任何讨论的话，大家的进步就太慢了。

[itskingname]

@cs8814336 是因为没有必要，尺有所长，完全一样就是重复造轮子了。

[cs8814336]

@xhinliang 感谢. 说实话那个阶段我还没有达到，所以只能发出这样的水帖..发帖前有思考过，当然能力有限不是很深入,尝试 google 过最深的就只谈到 b-tree b+tree，感觉都不是什么根本原因... 其实假如大家提到一些我没见过的方面我都会仔细去 google 的，例如上面提到什么 bson，我会去想为什么 mysql 不能用到这种技术呢，假如只有好处没坏处的功能就是可以应用到别的地方了．　我也看过一些介绍说能结合关系型和非关系型数据库优势的数据库，假如真的存在这样完美结合的能力，就是说 mysql 和 mongodb 应该也会往这个方面发展，那为什么没有这样发展的原因我相信肯定是因为某种技术底层原因决定了这个东西．

[Wisho]

@cs8814336 LZ 你发的贴全都是数据库底层实现的，你是想转做数据库内核？

[cs8814336]

@Wisho 当然我是想往技术深方向发展的，不管是数据库内核还是啥，有机会当然想. 上面问题只是看书或者文章衍生的思考而已. ps:我只是一个 2016 届毕业的后端小开发而已

[Wisho]

@cs8814336 歪个楼，有思考当然很好，但是从性价比的角度来说，有的知识比大众平均水平深一点即可，要把技能点点在最适当的地方。（不针对此贴这个知识点或某个别的什么知识点）

[luozic]

trade off 的问题，很多历史悠久的软件产品是不可能更换已有技术积累的，这样更换意味着之前几十年的技术投资完全放弃之后重来。 最简单的为什么 windows 和 osx 系统都这么大个？ 实际以构建系统的水平而言，不需要继承老旧遗产的 osx 和 windows 可以做得非常小，并且性能良好。osx 上的 excel 一直是 ahit 的原因就是要兼容几十年前各种各样积累下来的垃圾 shit 的格式的 excel。 现在唯一一个几乎采用割了重新来的编译器并获得好评的都只有一个，.net core。 并且微软几乎是养了两拨人搞一个语言的生态。

[petelin]

@huiyifyj 什么时候 json 和 Go 绑在一起了

[cs8814336]

@Wisho 装逼的话不多说，只要面试能过较大公司就行了