为什么MongoDB的用户评价不好

摘要：MongoDB 作为流行的 NoSQL 数据库，用户评价却存在两极分化现象。本文深入分析其受到批评的主要原因，包括早期版本的稳定性问题、内存占用争议、查询限制、商业策略变化等关键因素。

MongoDB 作为一款流行的 NoSQL 数据库，虽然在某些场景下表现优异，但用户评价存在两极分化。以下是其受到批评的主要原因：

1. 早期版本稳定性与数据一致性问题

默认弱一致性：早期版本默认使用「最终一致性」（w:1），可能导致数据丢失或读取到过期数据。例如，写入后立即查询可能看不到刚写入的数据（除非显式设置 w: "majority" 或启用 readConcern）。
分片集群问题：在 2.x/3.x 版本中，分片（Sharding）配置复杂，且存在平衡器（Balancer）导致性能抖动的问题。

2. 内存与性能争议

内存占用高：MongoDB 依赖内存映射文件（MMAP）的存储引擎（早期版本），未优化时可能吞掉大量内存，被误认为“内存数据库”。
锁粒度问题：在 4.0 版本前仅支持全局锁，高并发写入时性能骤降。尽管后来改进为文档级锁（WiredTiger 引擎），但用户对早期印象难以改变。

3. 查询与聚合的限制

JOIN 操作缺失：NoSQL 设计导致多表关联查询困难，$lookup（3.2+ 引入）性能远不如 SQL 的 JOIN。
事务支持晚：4.0 版本（2018 年）才支持多文档事务，且性能开销较大，与关系型数据库相比成熟度不足。

4. 存储与扩展的痛点

磁盘空间膨胀：预分配数据文件、碎片化删除导致存储效率低（尤其 MMAPv1 引擎）。
水平扩展成本高：分片集群需要至少 3 个配置服务器 + 多个分片 + 查询路由（mongos），运维复杂度远超单机 Redis 或 Elasticsearch。

5. 商业策略争议

License 变更：2018 年将开源协议从 GNU AGPL 切换到 SSPL（需商业授权才能将 MongoDB 作为服务提供），引发社区对“开源纯度”的质疑。
厂商锁定风险：部分用户担忧过度依赖 MongoDB 的独特语法（如聚合管道），迁移成本高。

6. 错误使用的代价

Schema 自由的双刃剑：灵活的无模式设计容易被滥用，导致后期数据混乱。例如，同一字段在不同文档中存储不同类型的数据，难以维护。
不适合强事务场景：尽管支持事务，但高频事务场景下性能显著低于 PostgreSQL 或 MySQL。

何时适合使用 MongoDB？

快速迭代开发：需求频繁变更，无需严格 Schema。
JSON 文档存储：嵌套数据结构多，且查询模式以读为主。
高吞吐写入：日志、IoT 设备数据等，但可容忍短暂不一致。

总结

MongoDB 的负面评价多源于早期版本的缺陷、误用场景或与关系型数据库的错位对比。随着 WiredTiger 引擎和事务功能的改进，其在特定领域（如灵活的数据模型、水平扩展）仍有不可替代的优势。关键在于明确使用场景，而非盲目跟随技术趋势。