柯----
我现在带的项目用到了MongoDB，本人对MongoDB也有一定的了解，下面我谈谈自己的看法。
先一句话概括：MongoDB和MySQL（关系型数据库）各有特点，它们适合的场景不同；而企业级应用的大部分场景，MongoDB是无法完全取代MySQL的。
MongoDB是什么
在分析这个问题之前，我们还是看看MongoDB的定义：MongoDB是一个数据库；再稍微详细一点儿，它是一个开源的、基于分布式文件存储的、非关系型数据库。
说到非关系型数据库，最有名的可能就是Redis了，它是一种Key-Value类型的数据库；而MongoDB，它是文档型数据库的一种，它的存储方式类似于JSON。
MongoDB的特性
MongoDB更多适用于大数据量、高并发、弱事务、不确定数据类型的应用；特别是这里的“不确定数据类型”，也是MongoDB最大的特点之一。
大家在用关系型数据库的时候，如果表中的数据量很大，想要给表添加一个字段，是一件很痛苦的事情；而MongoDB是无需事先创建表结构或修改表结构，所有的改变都是动态的。
MongoDB能否取代MySQL（关系型数据库）？
MongoDB不适用于高度事务性的系统，如果系统对数据的事务性要求很高，还是用关系型数据库比较合适。（MongoDB3.6对单集合的事务支持不错，据说4.0之后，对多集合的事务支持也可以，不过我没有深入研究过）
MongoDB的多集合关联也没有关系型数据库强大，不过MongoDB更擅长把几个表的信息，放在一个集合里面。
所以总结来说，关系型数据库和MongoDB是不存在谁替代谁的问题，他们应该是各有优势，相互补充的。就好像我们平时用的无线键盘和机械键盘一样，无线键盘灵活轻便、外观比较时尚，而机械键盘手感出色、跪着舒服，不伤膝盖，各有优势。
希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、职业发展等方面的见解，希望能得到你的关注；另外，关注我后私信【资料】两个字，可获取架构、大数据、面试等相关资料。
会点代码的大叔
这个问题其实就好像问关系型数据库可以取代非关系型数据库一样。
要说完全取代，肯定是不可能的。
但是某些小项目中，你可以选择使用mongodb而不用mysql。至少我经常这么干。
当然，在一些特殊的大型项目里面，你也可以完全抛弃关系型数据库，mongodb会是你一个很好的选择，什么样的项目？怎么使用呢？我最后来告诉大家。
Mongodb确实非常好用，它的特点是高性能、易部署、易使用，存储数据非常方便。
我们在使用的时候，不用再去考虑数据库的设计，字段等等。
我们可以轻松的建立好实体，然后CRUD。
当然，它还能够支持查询和索引，这样就让我们在使用中更加的方便，只要不是复杂的表关系逻辑，我们都可以使用mongodb来完成。
但是缺点就就是上面说的，如果非常复杂的逻辑关系，那用mongodb就有点力不从心了。
因为mongodb在复杂的关系逻辑处理和事务控制方面就比较弱了。
曾经，我研究过一段时间领域驱动设计，也就是DDD。
当DDD和CQRS（命令与查询职责分离）结合使用的时候（当然，很多时候说DDD都是结合了CQRS的），你就会发现，你是不是使用关系型数据库已经不太重要了。
先说说底层，如果你使用DDD+CQRS，你可以有两个数据库，一个Command库，一个Query库，也就是读库和写库。
当DDD+CQRS使用时，写库里面写入的只是一个个对象的操作命令，所以可以简单的说，一个命令就是一条记录，而且写库里面只有Insert。当然，最后的时候，写库里面会有海量的数据，当数据量过大时，就会用到快照，这个就不说了。
这个时候我们就会发现，一个只有insert的单表库，用关系型数据库貌似没啥意义。我用mongodb，redis都可以完成。
那我们再看看读库，读库其实是将所有的命令执行后的最终结果呈现出来，那读库应该是关系型的，因为我们的业务逻辑肯定是有关系的。
但是我们仔细体会后会发现，DDD的聚合，聚合根，实体对象，值对象这些概念，将本来复杂的关系整理得非常明晰（有兴趣的可以去看看DDD，这些概念有点抽象，这里就不介绍了）。
你会发现，我不使用关系型数据库，我就是用一个缓存，或者mongodb就可以进行存储了，因为我的查询都是通过聚合根来实现的，我的命令也都是通过聚合根来完成的，聚合根是什么？其实也就是一个实体类，整个聚合也就是一个复杂关系的实体类，聚合与聚合之间其实不会有联系，这个也就是DDD里面的关于边界的划分。
那在实现这一的项目时，我就可以写库用Redis，读库用Mongodb，MySQL？可以不用了。
会技术的葛大爷
先给出结论：不可以取代！
能提出这样的问题，肯定是对Mongodb不是很了解，来看看MongoDB是什么，能做什么，不能做什么吧。
MongoDB
mongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
特点：
- 面向集合存储，易存储对象类型的数据。
- 模式自由。
- 支持动态查询。
- 支持完全索引，包含内部对象。
- 支持查询。
- 支持复制和故障恢复。
- 使用高效的二进制数据存储，包括大型对象（如视频等）。
- 自动处理碎片，以支持云计算层次的扩展性。
- 支持RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言。
- 文件存储格式为BSON（一种JSON的扩展）。
- 可通过网络访问。
使用原理
不适用的场景如下：
1）要求高度事务性的系统。
3）复杂的跨文档（表）级联查询。
结论
从MongoDB不适用场景就可以看出其不可能替代MySQL.
用Java打酱油
MongoDB作为新一代的数据库平台，具备了智能操作数据平台的特点：
1、易于开发，上手快，开发效率快；
2、天生的高可用性（副本集），天生的可扩展性（分片技术）满足企业级的需求；
3、随处部署的能力，可以和云技术、容器技术深度集成，符合当前devops、微服务等技术发展趋势。
正是因为上述原因，很多应用都已经或者正在考虑使用MongoDB替代MySQL。特别是在MongoDB 4.0之后，应用使用MongoDB替代MySQL顺利成章，主要原因是：
1. MongoDB 4.0 提供了多文档事务，支持完整的ACID操作；
2. MongoDB 4.0 优化了副本集的从节点的读能力，从性能上更好的支撑分析型应用；
3. MongoDB 4.0 优化了聚合框架，从功能上更好的支撑分析型应用。
诚然，在使用MongoDB替代MySQL过程中也会有一些挑战，这些挑战从个人的经验来看主要集中在：
1. 对MongoDB的“反范式”建模理解不够；“反范式”建模作为一种创新的建模方式，以应用使用数据为导向，而不是过去以“实体”和“关系”为导向；
2. 对现有的基于MySQL的应用的数据迁移到MongoDB。这种数据迁移中挑战比较大的地方在于如何实现实时迁移，MongoDB 3.6的Change Stream可以帮助实现数据实时迁移。
上述是个人的一些理解，供参考指正！
四の海
自己也是程序员，分享一些观点给你，其实不管是MongoDB还是Mysql,它们都是用来存储数据用的，只不过存储数据的方式不同，MySQL主要用于存储关系类的数据，而MongoDB主要用于存储键值类的数据，也就是我们常说的NOSQL，曾经一段时间，NOSQL是很多中小互联网公司追求的东西。
那么既然都是存储数据用的，那么肯定也可以相互替换，但是一个重要的问题就是，怎么样将MongoDB里面的数据存储到MySQL里面或者相反方向有怎么存储？这才是整个业务代码非常复杂的实现部分，比如你要将MySQL的数据存储到MongoDB里面去，那么你需要做的事情就是理清MySQL数据表里面的各种关系，然后将这些关系转换为键值对存储到MongoDB里面去，想象一下这个工作量我们就应该知道，不是那么的简单，尤其是数据表非常多，并且数据表关系非常复杂的时候，这项迁移工程是需要后端程序员、数据库DBA、运维人员等等一起才能够完成的事情。
所以得出结论，虽然两种数据库可以相互替换，但是替换的成本非常高，很多企业是不会这样做的，除非现在项目性能已经严重影响到目标用户。
互联网知天下
Mongodb作为最靠近关系数据库的Nosql存储，取代MySQL可以吗？
从功能角度看，是可以取代的。
关系数据库应该有的核心功能它都有了：B树索引，事务（4.0）。
一些比较重要的小更新，比如Decimal128（3.4）的添加都让它的功能更加完善。
你在Mysql里面用的复杂查询基本上都可以用管道或者MapReduce实现。
我在好几个项目中完全使用的Mongodb，经验如下：
* 关联查询麻烦，所以Mongodb在设计模型的时候倾向于数据都内联，配合少量的In 查询。这样也会导致数据冗余后一致性更新的问题。
* 设计动态表格时，Mongodb的体验时非常好的。
* 4.0之前的没有事务，碰到金钱相关的服务，需要自己在服务中构造事务环境，否则一旦失败无法回滚。这也会造成这块代码膨胀。
* 编写复杂脚本查询数据库时，编写脚本或者服务时难度更大，更花时间。统计服务较多的时候，更加伤脑子。
* 由于协议设计的原因，命令太多，导致不常用命令的需要经常查询文档。
推荐使用Mongodb的场合：
* 在Demo期间使用Mongodb做数据存储。
* 处于前期的互联网产品，适应快速迭代。
* 配合MySql使用，完成一些动态数据处理的功能。不用设计冗余列，轻松构建查询的感觉就是好。
* 作为一些热数据或者中间数据（比如统计需要的中间表）的缓存使用。
Mongdob的官方文档很完善，你要使用，建议把文档浏览一遍。尤其是聚合管道查询，花点时间好好理解，这个是你写复杂查询的基础。
复杂的业务系统，尽量避免，它会影响你的开发效率。
再补充几点：
客户端工具可以使用navicate或者NoSql manager，推荐使用navicate，顺手。
如果服务端不是nodejs之类的动态语言服务，最好写一些命令的扩展，驱动在表达式转换方面做得还不够。
迁徙de麻雀
其实每个产品都有其特长的短板，可能会在一定程度上存在功能重复，但不可能完全取代。举个不太恰当的例子来说：猫和狗都可以当宠物，猫能取代狗吗？答案肯定是不能。但作为宠物，两者确实都能做到惹人喜爱，也都能在主人寂寞或无聊的时候陪伴主人，作为宠物，它们甚至有更多相同的作用，但两者永远无法取代对方。不得不说在这个技术类产品满天飞的时代，总有些对技术不深入了解的人或企业做着用猫来取代狗的白日梦，希望大家保持对技术的敬畏之心，可以大胆假设，但要谨慎求证，最终作出正确的选择。
闫锋同学
粘贴那么多介绍干嘛，一句话：不同业务场景，选用就不一样。mysql针对业务结构复杂的用，mongodb反之。两者结合，mongodb可以拿来做高级缓存或者提供查询性能来存储。mysql就出来业务结构复杂的数据存储，还有事务回滚。mongodb是没有事务回滚的
程序弈说
一种是关系数据库，一种是非关系数据库，他们的共同地方就是都是数据库，都是用来存储项目数据的，所以从理论上来说是可以相互替代的，但是，有一个实际问题，就是两种数据的保存方式不同，也就是应用程序写入数据的方式不同，所以相互替换时，需要熟悉两个程序的保存方式和业务逻辑。
