为什么MongoDB在国内没Redis火？六个程序员说了大实话

周三晚上，运维群里又有人甩出一张MongoDB分片集群的监控截图，配文只有两个字：救命。开发那边刚上线的新功能，数据全往一个分片上怼，其他分片在旁边围观。想改片键？官方文档写得很清楚，片键选定，终身不改。

知乎上有个老问题又被翻了出来：为什么MongoDB在国内发展得没Redis好？几位高赞答主给出的答案，指向的其实是同一件事——这东西的定位，太别扭了。

正方：它本来就不该跟Redis比

答主kimmking把MongoDB的履历捋了一遍。最早期的版本几乎没有持久化，直接对标的是Redis、Memcached这类缓存。后来慢慢加功能，GridFS、事务、分布式多副本，做到现在基本能当高容量分布式数据库用。

但缓存这块，Redis还是绝对王者。小规模一千节点以内用Redis Cluster，再大规模就上多级缓存分片的中间件。这位答主提到，自己有个项目用了2300个Redis节点，每个64G。

缓存这条路上还有两个方向：一个是KV存储，以TiKV、Apache Kvrocks、Apache Pegasus为代表，走自动冷热数据分离；一个是内存网格，以Hazelcast和Apache Ignite为代表。在缓存领域，MongoDB不够打的。

数据库领域同样尴尬。走文档数据库的路子，JSON操作支持如今是基操，MySQL一般，PostgreSQL好不少，Redis的ReJson用得也很广泛，这个优势并不明显。走分布式数据库，到底是OLTP还是OLAP？官方设计奔着OLTP去，可schema free在强事务和约束场景里天然是缺点，打不过TiDB、OB、Polar这些；OLAP那边，Hadoop、Spark体系不搭，湖仓体系里Clickhouse、Doris、StarRocks一堆选手，MongoDB显得太简单。

答主王絮飞补了一刀：国内普遍不是把MongoDB当NoSQL用，而是当MySQL的替代品用。没了关系型数据库的约束，集合结构惨不忍睹，查询也没人优化得下去。MongoDB用空间换时间，可国内空间敏感、时间不敏感，优点反而成了缺点。

反方：它给了程序员一条活路

答主水军代号9527的观点很直接：MongoDB的优秀之处，在于国内需求一天三改还得当天上线的情况下，给了众多没有话语权的程序员一条活路。

这话不算夸张。schema free意味着今天加个字段、明天改个类型，不用走改表流程。开发确实用得爽。

但爽的是开发，扛的是运维。答主Lion莱恩呀把两边处境摆得很清楚：Redis在国内大部分场景是缓存，允许失败。挂了顶多缓存雪崩，数据源还在MySQL里，重启预热，被业务方骂两句。

MongoDB是核心存储，存的是订单、用户画像、物联网设备实时数据。挂了或者数据丢了，就是P0级事故。

片键设计是运维最大的坑。开发随便选个字段当片键，数据量上来就是热点倾斜。想解决只能新建集群、重新设计片键，再把几TB数据导过去。

答主花宝宝的公司有个组用MongoDB存日志，后来运维受不了，强推换成了Elasticsearch。原因列了四条：副本集配置和选举机制要搞明白；分片集群的Config Server、Mongos一堆组件；索引设计和关系型数据库很不一样，DBA要重新学；出了问题，网上能搜到的解决方案比MySQL少太多。

国内DBA主力还是MySQL系。用MongoDB，招人难、交接难、出问题没人兜底。这笔隐性成本，很多技术决策者看得很重。绝大多数公司的现状是，让懂MySQL的DBA兼职管MongoDB，而关系型思维和文档型数据库完全是两码事。

我的判断

这场讨论里，两边其实没在吵同一件事。反方说的是开发体验，正方说的是系统定位和运维成本。MongoDB在国内的处境，更像是被放在了错误的位置上——当缓存打不过Redis，当关系库替代品又缺约束，当核心存储则运维门槛劝退。

答主Rust怎么你了还有一句：Redis是风口上的猪，Memcache要是不摆烂，Redis就不会有机会。而Redis不适合做的事它也能做了，消息队列、分布式锁，用一个内存数据库来搞，也就没有危机感的技术团队会取用。

至于MongoDB，最大的问题被归结为对JOIN的支持太弱，应对不了复杂业务，只能用在比较单一的日志类场景。这话未必全面，但它点出了那个核心矛盾：一个工具的定位如果两头不靠，再多的功能叠加也补不回来。