为什么MongoDB在国内发展，没有Redis好？
dbaplus社群 2026-10-18 08:00 广东
主要是MongoDB的定位太尴尬了……
最近，小编在知乎上看到这样一个问题：
为什么MongoDB在国内发展得没Redis好？
秉持着和平交流的学习态度，小编精选了几位高赞知乎网友的精彩回答，分享给大家学习交流（勿上升、勿引战）：
1号知乎网友：kimmking
主要是MongoDB的定位太尴尬了。
最早期的版本相当于Redis，几乎没有持久化(貌似0.x)，最早期是直接对标于Redis、Memcached、TT/TC这些缓存。
慢慢地加功能，GridFS/事务，分布式多副本等等，，做到现在基本上可以当做一个高容量的分布式数据库。
但是，一方面在缓存领域，现在基本Redis还是绝对王者，容量的话，小规模(1000以内)可以用Redis Cluster，再大规模可以多级缓存分片的中间件，比如用Camellia之类的。我们有个项目用了2300个Redis节点（每个64G）。
并且缓存这条路上，现在还有两个更好的大容量分布式技术方向：一个是KV存储，以TIKV，Apache Kvrocks，Apache Pegasus为代表，走自动冷热数据分离，加上无限制的存储容量模式。
一个是内存网格，可以看做是基于分布式协议的大规模分布式内存缓存，以Hazelcast和Apache Ignite为代表，这是真正的Redis之类的缓存的分布式代替者，并且玩出花了。
在缓存这个领域，MongoDB不够打的。
再说数据库领域，MongoDB走的不是关系库的路子，而是文档数据库的路子。
很多人都在说拿MongoDB的B/JSON说事儿，这年头，JSON操作支持都是基操了。
MySQL还比较一般，PostgreSQL要好不少，Redis的ReJson用得非常广泛了。
这个优势并不那么明显。
走分布式数据库的路子，定位也尴尬极了，到底是OLTP，还是OLAP？
虽然看起来官方设计是奔着 OLTP去的。（但是所谓的schema free在强事务和约束领域（比如金融或者交易核心服务，天然是个缺点呀！）
但是OLTP没戏，怎么看也打不过TIDB，OB，Polar，TDSQL，Golden，Gauss这些，而且最最重要的是要想在这个领域有个生态位，必须要兼容 MySQL/PG/Oracle中的一个或几个。MongoDB有JDBC驱动，但是SQL稀碎，这一块没戏。并且事务操作也不是其强项。
OLAP的话，现在主流的Hadoop/HDFS/Hive、Spark/Flink体系，好像都不搭。如果走现代化分析的湖仓体系，在Clickhouse、Hudi、Iceberg、Paimon、Doris、StarRocks这一堆面前，MongoDB就显得太简单，也还是小弟弟。
总之，不管是在传统领域、还是分布式系统领域，在缓存和数据库、OLTP和OLAP，MongoDB的定位，目前来看，都很别扭。
2号知乎网友：水军代号9527
MongoDB的优秀之处在于(甚至是伟大之处)，在国内遍布垃圾产品经理，需求一天三改还得当前上线的情况下，给了众多没有话语权的程序员一条活路。
3号知乎网友：花宝宝
我们公司之前有个组用 MongoDB存日志，后来运维受不了了，强推换成Elasticsearch。
为什么？MongoDB 的运维复杂度比 MySQL高不少：
1）副本集配置、选举机制要搞明白；
2）分片集群的Config Server、Mongos 一堆组件；
3）索引设计和关系型数据库很不一样，DBA要重新学；
4）出了问题，网上能搜到的解决方案比MySQL少太多。
国内DBA群体主力还是MySQL系。你用MongoDB，招人难、交接难、出问题没人兜底。这个隐性成本很多技术决策者是很看重的。
4号知乎网友：王絮飞
因为国内普遍不是把MongoDB当作NoSQL用的，普遍是当作MySQL之类的关系型数据库的替代品用的。
在没了关系型数据库的约束之后，创建的集合结构普遍惨不忍睹，导致毫无可维护性，而且没了约束之后写出来的查询同样惨不忍睹没谁优化的下去。
另外MongoDB作为NoSQL，会用空间换时间，国内普遍空间敏感，毕竟是钱，时间不敏感，只要忽悠用户在那等着就好了，MongoDB的优点反而成了缺点。
对了，本来MongoDB跟Redis确实没有可比性，俩完全不一样的东西。
5号知乎网友：Rust怎么你了
Redis是风口上的猪。
在缓存方面，Mecache+要是不摆烂，Redis就不会有机会。
而Redis不适合做的事它也能做了，比如消息队列、分布式锁+，这些功能用一个内存数据库来搞，也就没有危机感的技术团队会取用。
MongoDB最大的问题是对JOIN+的支持太弱，以至于无法应对复杂的业务，只能用于比较单一的日志类场景。
6号知乎网友：Lion莱恩呀
主要是MongoDB对运维来说，谁体验过了谁知道！是一点活路不给......
开发是用得爽了，维护怎么办？出了事谁都兜不住！
咳咳，我是开发，但可不少听到运维抱怨的哪个苦。
Redis在国内大部分场景下是干嘛的？缓存。
所以，允许失败。Redis挂了，虽然会发生缓存雪崩，数据库压力会大一点，但数据源还在MySQL里。
挂了？重启一下，预热一下，顶多被业务方骂两句。
MongoDB呢？是核心存储。
存的是订单、是用户画像、是物联网设备的实时数据。要是挂了，或者数据丢了，那就是P0级事故，是要扣绩效、甚至开除走人的。
还有，MongoDB的片键设计是MongoDB运维最大的坑。
如果开发随便选了个字段当片键，就埋下一颗雷。数据量上来，数据全往一个分片上怼（热点倾斜），其他分片在围观。
这时候想改?对不起，改不了。官方文档已经说明：片键选定，终身不改。
想解决？只能新建一个集群，重新设计片键，然后把几TB的数据导过去。
Redis的运维门槛相对来说很低。稍微看两天文档，就能把Redis玩得有模有样。市面上懂Redis的人一抓一大把，招人成本低，不需要专门设岗。
MongoDB 呢?
国内精通MongoDB的DBA，那是稀缺物种。
绝大多数公司的现状是：让懂MySQL的DBA兼职管MongoDB。
这就会出大问题。
因为关系型数据库的思维和文档型数据库完全是两码事。
MySQL DBA习惯范式设计，看到MongoDB的嵌套结构就头大。
开发人员觉得MongoDB是Schema-less，爽啊，随便写！今天加个字段，明天改个类型，没有任何约束。
时间久了，里面存了什么、格式是什么、哪些是有用的，不清楚。
等到这个时候想治理？晚了。
整理丨dbaplus社群
来源丨网址：https://www.zhihu.com/question/478485839?share_code=KkcI7va8OcDA&utm_psn=2030409274996822556
*仅为提供参考和学习交流，不代表dbaplus社群立场！dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
本文转载自微信公众号「dbaplus社群」，查看原文。版权归原作者所有，如有侵权请联系删除。