谢谢邀请。
我现在带的项目用到了MongoDB，本人对MongoDB也有一定的了解，下面我谈谈自己的看法。
先一句话概括：MongoDB和MySQL（关系型数据库）各有特点，它们适合的场景不同；而企业级应用的大部分场景，MongoDB是无法完全取代MySQL的。
在分析这个问题之前，我们还是看看MongoDB的定义：MongoDB是一个数据库；再稍微详细一点儿，它是一个开源的、基于分布式文件存储的、非关系型数据库。
说到非关系型数据库，最有名的可能就是Redis了，它是一种Key-Value类型的数据库；而MongoDB，它是文档型数据库的一种，它的存储方式类似于JSON。
MongoDB更多适用于大数据量、高并发、弱事务、不确定数据类型的应用；特别是这里的“不确定数据类型”，也是MongoDB最大的特点之一。
大家在用关系型数据库的时候，如果表中的数据量很大，想要给表添加一个字段，是一件很痛苦的事情；而MongoDB是无需事先创建表结构或修改表结构，所有的改变都是动态的。
MongoDB不适用于高度事务性的系统，如果系统对数据的事务性要求很高，还是用关系型数据库比较合适。（MongoDB3.6对单集合的事务支持不错，据说4.0之后，对多集合的事务支持也可以，不过我没有深入研究过）
MongoDB的多集合关联也没有关系型数据库强大，不过MongoDB更擅长把几个表的信息，放在一个集合里面。
所以总结来说，关系型数据库和MongoDB是不存在谁替代谁的问题，他们应该是各有优势，相互补充的。就好像我们平时用的无线键盘和机械键盘一样，无线键盘灵活轻便、外观比较时尚，而机械键盘手感出色、跪着舒服，不伤膝盖，各有优势。
评论0
加载中...
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之类的动态语言服务，最好写一些命令的扩展，驱动在表达式转换方面做得还不够。
评论0
加载中...
脱离业务场景，空谈技术架构都是耍流氓。
我们公司同一个项目就同时在用Mysql和MongoDB，希望通过下面介绍可以帮助你真正了解到Mysql和MongoDB优劣对比及实际业务应用场景。
以下来自最新的db-engines的数据库人气排行榜
接下来我们看一下前十名的趋势变化图：
关系数据库前10名如下：
文档数据库前10名如下：
通过上面可以看出MongoDB虽说分数一直保持着稳定上升的趋势，但和 Mysql相比依然有一定的差距。不过，MongoDB 在2018年的表现是非常不错的，至少一直都在进步，这个表现也是 MongoDB 独一份。
MySQL：MySQL将数据存储在表中，并使用结构化查询语言（SQL）访问数据。MySQL使用模式来定义数据库结构，要求表中的所有行具有相同的结构，并且值由特定的数据类型表示。
MongoDB：在MongoDB中，数据存储在类似JSON的文档中，这些文档可以有不同的结构。为了提高查询速度，MongoDB可以将相关数据存储在一起，这些数据可以使用MongoDB查询语言访问。
在MongoDB中，文档能够拥有自己独特的结构。新字段可以随时添加并包含任何类型的值。
MySQL是关系型数据库。
优势：
在不同的引擎上有不同的存储方式。
查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。
开源数据库的份额在不断增加，mysql的份额页在持续增长。
缺点：
在海量数据处理的时候效率会显著变慢。
Mongodb是非关系型数据库(nosql )，属于文档型数据库。
存储方式：虚拟内存+持久化。
查询语句：是独特的Mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。
优点：
快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。高扩展性，存储的数据格式是json格式！
缺点：
事务关系支持薄弱。这也是所有NoSQL数据库共同的缺陷，不过NoSQL并不是为了事务关系而设计的，具体应用还是根据需求。而且开发文档不是很完全、完善。
关系型数据库适合存储结构化数据，如用户的帐号、地址
1）这些数据通常需要做结构化查询，比如join，这时候，关系型数据库就要胜出一筹
2）这些数据的规模、增长的速度通常是可以预期的
3）事务性、一致性
NoSQL适合存储非结构化数据，如文章、评论：
1）这些数据通常用于模糊处理，如全文搜索、机器学习
2）这些数据是海量的，而且增长的速度是难以预期的，
3）根据数据的特点，NoSQL数据库通常具有无限（至少接近）伸缩性
4）按key获取数据效率很高，但是对join或其他结构化查询的支持就比较差
更高的写入负载
默认情况下，MongoDB更侧重高数据写入性能，而非事务安全，MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB，除非能从架构设计上保证事务安全。
高可用性
MongoDB的复副集(Master-Slave)配置非常简洁方便，此外，MongoDB可以快速响应的处理单节点故障，自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定（如云主机）的环境中，保持高可用性。
数据量很大或者未来会变得很大
依赖数据库(MySQL)自身的特性，完成数据的扩展是较困难的事，在MySQL中，当一个单达表到5-10GB时会出现明显的性能降级，此时需要通过数据的水平和垂直拆分、库的拆分完成扩展，使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性，可以很好的适应大数据量的需求。
基于位置的数据查询
MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。
表结构不明确，且数据在不断变大
在一些传统RDBMS中，增加一个字段会锁住整个数据库/表，或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候（当大于1TB时更甚）。 因MongoDB是文档型数据库，为非结构货的文档增加一个新字段是很快速的操作，并且不会影响到已有数据。另外一个好处当业务数据发生变化时，是将不在需要由DBA修改表结构。
没有DBA支持
如果没有专职的DBA，并且准备不使用标准的关系型思想（结构化、连接等）来处理数据，那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便，类可以直接序列化成JSON存储到MongoDB中。 但是需要先了解一些最佳实践，避免当数据变大后，由于文档设计问题而造成的性能缺陷。
BillRun – 基于MongoDB的帐单系统 (来自oc666)
BillRun是由Ofer Cohen推出开源账单系统，采用MongoDB做为数据存储。这套账单系统被以色列一家增速最快的电信运营商采用，每月处理5亿条通信记录，Ofer在Slideshare上说明了具体利到了MongoDB的哪些特性：
弱数据结构的特点，使得BillRun能很快的支持新的CDR(通讯记录)类型。这个特性使文档型数据库很适用于快速发展、业务需求不确定的系统中。
BillRun仅使用了一个Collection，已经管理了数TB的文档数据，并且没有遇到由结构变更、数据爆发式增长的带来的限制和问题。
replicaSet副本集特性使建立更多的数据中心DRP变得更轻松。
内建的Sharding分片特性避免系统在数据增长的过程中遇到性能瓶颈。
每秒钟2000条通信记录的插入，MongoDB在架构设计上很好的支持了高负载的数据写入。并且可以使用findAndModify(相对缓慢)完成基础的事务特性，并且通过应用层面的支持，实现双段式提交。
查询方式相比SQL，更加易读、易懂，开发相对轻松。
基于位置允许更好的分析用户使用情况，从而更好地制定移动电话基础设施的投入点。
以上，如果对你有帮助帮忙点个赞吧
专注于Java领域优质技术号，欢迎关注
评论0
加载中...
粘贴那么多介绍干嘛，一句话：不同业务场景，选用就不一样。mysql针对业务结构复杂的用，mongodb反之。两者结合，mongodb可以拿来做高级缓存或者提供查询性能来存储。mysql就出来业务结构复杂的数据存储，还有事务回滚。mongodb是没有事务回滚的
评论0
加载中...
完全取代是必然的，只是一个时间问题，关系型数据库或者说所有基于二维数据表的数据库都应该被淘汰了。
浅而易见的道理，二维数据表能做的哈希数据集（姑且称之为三维数据集）都能做到，可以说后者包含前者，而如果要反过来那就不是那么简单了，需要多个二维数据表才能实现一个哈希树形数据集的目标。
二维表中为了多表关系导致大量字段数据重复，开发模块的逻辑层进行数据对象组织所需要的转换变得繁锁，设计毫无低技术含量又臃肿，高开销低效率，不参与检索的大量字段暴露在顶层数据中显得无趣又无意义。
而这些二维表罄竹难书的缺点，哈希树形数据结构的NoSQL数据集数据库具备先天性的优势。
MongoDB4.0以后，事物问题被彻底解决，实在找不出还要舍Mongodb而抱MySql的理由，其次MySql被甲骨文收购之后，前途未卜，毕竟它们还是要靠Oracle赚钱的。
评论0
加载中...
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可以帮助实现数据实时迁移。
上述是个人的一些理解，供参考指正！
评论0
加载中...
自己也是程序员，分享一些观点给你，其实不管是MongoDB还是Mysql,它们都是用来存储数据用的，只不过存储数据的方式不同，MySQL主要用于存储关系类的数据，而MongoDB主要用于存储键值类的数据，也就是我们常说的NOSQL，曾经一段时间，NOSQL是很多中小互联网公司追求的东西。
那么既然都是存储数据用的，那么肯定也可以相互替换，但是一个重要的问题就是，怎么样将MongoDB里面的数据存储到MySQL里面或者相反方向有怎么存储？这才是整个业务代码非常复杂的实现部分，比如你要将MySQL的数据存储到MongoDB里面去，那么你需要做的事情就是理清MySQL数据表里面的各种关系，然后将这些关系转换为键值对存储到MongoDB里面去，想象一下这个工作量我们就应该知道，不是那么的简单，尤其是数据表非常多，并且数据表关系非常复杂的时候，这项迁移工程是需要后端程序员、数据库DBA、运维人员等等一起才能够完成的事情。
所以得出结论，虽然两种数据库可以相互替换，但是替换的成本非常高，很多企业是不会这样做的，除非现在项目性能已经严重影响到目标用户。
评论0
加载中...
其实每个产品都有其特长的短板，可能会在一定程度上存在功能重复，但不可能完全取代。举个不太恰当的例子来说：猫和狗都可以当宠物，猫能取代狗吗？答案肯定是不能。但作为宠物，两者确实都能做到惹人喜爱，也都能在主人寂寞或无聊的时候陪伴主人，作为宠物，它们甚至有更多相同的作用，但两者永远无法取代对方。不得不说在这个技术类产品满天飞的时代，总有些对技术不深入了解的人或企业做着用猫来取代狗的白日梦，希望大家保持对技术的敬畏之心，可以大胆假设，但要谨慎求证，最终作出正确的选择。
评论0
加载中...
0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答10
回答
