没有什么替换不替换的，都是看具体业务需要。

就如同C语言之于编程语言一般，C语言都诞生这么多年了，一直有新的语言出来说要替换掉C，但是谁做到了，C现在还是最受欢迎的编程语言。

以mongodb、redis等为代表的nosql数据库并不是新型数据库对传统关系型数据库发起的第一次挑战了，早在上个世纪就有什么面向对象数据库等非关系型数据库扬言要替代关系型数据库，但是到现在，那些数据库都默默无闻，关系型数据库却依旧是应用最广泛的数据库，为什么？强大的数学理论基础！关系型数据库是上世纪几个计算机领域的大神共同创造出来的，有着严谨的数学理论基础，这也保证了关系型数据库各方面的优越性和稳定性；mysql是关系型数据库中的佼佼者，mongodb又是nosql中最流行的一个，对比两者，如果你有以下的需求，那用mongodb会更好：

你期望一个更高的写负载

默认情况下，对比事务安全，MongoDB更关注高的插入速度。如果你需要加载大量低价值的业务数据，那么MongoDB将很适合你的用例。但是必须避免在要求高事务安全的情景下使用MongoDB，比如一个1000万美元的交易。

不可靠环境保证高可用性

设置副本集(主-从服务器设置)不仅方便而且很快，此外，使用MongoDB还可以快速、安全及自动化的实现节点(或数据中心)故障转移。

未来会有一个很大的规模

数据库扩展是非常有挑战性的，当单表格大小达到5-10GB时，MySQL表格性能会毫无疑问的降低。如果你需要分片并且分割你的数据库，MongoDB将很容易实现这一点。

使用基于位置的数据查询

MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。

非结构化数据的爆发增长

给RDBMS增加列在有些情况下可能锁定整个数据库，或者增加负载从而导致性能下降，这个问题通常发生在表格大于1GB(更是下文提到BillRun系统中的痛点——单表格动辄几GB)的情况下。鉴于MongoDB的弱数据结构模式，添加1个新字段不会对旧表格有任何影响，整个过程会非常快速；因此，在应用程序发生改变时，你不需要专门的1个DBA去修改数据库模式。

缺少专业的数据库管理员

如果你没有专业的DBA，同时你也不需要结构化你的数据及做join查询，MongoDB将会是你的首选。MongoDB非常适合类的持久化，类可以被序列化成JSON并储存在MongoDB。需要注意的是，如果期望获得一个更大的规模，你必须要了解一些最佳实践来避免走入误区。

但是mongodb比起mysql也有它的短板：

①mongodb不支持事务操作。

所以事务要求严格的系统(如果银行系统)肯定不能用它。

②mongodb占用空间过大。

关于其原因，在官方的FAQ中，提到有如下几个方面：

1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。

2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长 了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。

3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢

③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。

所以没必要整个后台数据库只用一种数据库，更加理智的解决方案是：关系型数据库和NoSQL配合使用，具体业务分发到不同类型的数据库才是最理想的方案。