写这篇文档的原因是之前作者虽然有用过MongoDB，同时也在公司里面用过MongoDB，当时只是感叹，哇，又遇到我没用过的新型数据库，得用用，使用的过程当中体验也还可以，不用考虑字段如何，简单的索引构建，存储海量的数据还有包括从4.0版本 开始，加入了多文档 ACID 事务支持，随后的 4.2 版本中，事务支持被拓宽到整个分片集群等等，但做技术的，我学习到的是，凡事都要问一个为什么，于是便有了这篇文章，为什么要使用MongoDB，并且在什么时候使用它

MongoDB是什么

这是MongoDB官网对自己的评价 MongoDB 是一个文档数据库，旨在简化应用程序开发和扩展至于为什么叫文档数据库就要从它的诞生说起

MongoDB 的故事开始于 2007 年。1995 年，Dwight Merriman 和 Kevin O'Connor 创办了著名的在线广告公司 DoubleClick。DoubleClick 很快就大获成功，几年之内，它的广告流量达到了每秒 40 万条。当时的关系型数据库技术还没有预料到会有如此大规模的流量。配备如此规模的关系数据库需要大量的资金和硬件资源。因此，Dwight和他的团队开发了自定义数据库实现来扩展 DoubleClick，以应对流量的激增。Dwight谈到启动MongoDB开源项目的原因是在于“它们感觉有必要推出一种新的数据技术类型，而当时也正好是最合适的时间点。”

MongoDB 的核心引擎是用 C++ 开发的。之所以把这个数据库叫作 MongoDB，是因为开发团队想用它来为一些典型的应用场景 (如内容服务) 提供海量数据的存储服务。最初，这个团队只有 4 名工程师 (包括 Dwight 和 Eliot)，并只专注于 MongoDB 数据库。他们的商业理念是通过开源免费下载的方式来发布数据库，并在这个基础上提供商业支持和培训服务MongoDB 1.0 于 2009 年 2 月发布。最初的版本提供了一种具有文档模型、索引和基本复制功能的查询语言，还提供了实验版的分片功能，但生产版本的分片集群功能在一年后发布的 1.6 版本中才有。

2011 年的一次“NoSQL 以及为什么我们要开发 MongoDB”的 ZendCon 演讲中，Dwight 详细介绍了Mongo早期的设计原则：

• 快速和简单的数据模型，实现更快的编程——支持 CRUD 的文档模型。
• 使用熟悉的编程语言和格式——Java/JSON。
• 无模式文档——方便敏捷迭代开发。
• 为了快速开发和更易于伸缩，只提供必要的功能，没有连接和跨集合的事务。
• 支持简单的水平伸缩和持久性 / 可用性 (复制 / 分片)。

但是后来的故事大家都知道了，Mongo在4.2版本开始还是支持事务了

MongoDB发展到现在，优势很明显，它具有基于 JSON 的数据模型最接近开发者的面向对象的设计思维；灵活动态的模型意味着在需求多变的时候极大简化数据库设计流程；自动分片、多节点自动同步和跨中心能力支持各种现代化复杂部署需求。同时现在也在通过发展MongoDB Atlas加快自己的上云能力

MongoDB到底适合在哪里

说了这么多，基本都是作者翻阅各种资料看见关于MongoDB的介绍，从之前的种种不支持到现在支持了很多新的特性，可是作者还是不明白MongoDB的具体业务场景到底是在哪，比如以下你可以看到的。

• 案例1：用在应用服务器的日志记录，查找起来比文本灵活，导出也很方便。也是给应用练手，从外围系统开始使用MongoDB。用在一些第三方信息的获取或者抓取，因为MongoDB的schema-less，所有格式灵活，不用为了各种格式不一样的信息专门设计统一的格式，极大得减少开发的工作。
• 案例2：mongodb之前有用过，主要用来存储一些监控数据，No schema 对开发人员来说，真的很方便，增加字段不用改表结构，而且学习成本极低。
• 案例3：使用MongoDB做了O2O快递应用，将送快递骑手、快递商家的信息（包含位置信息）存储在 MongoDB，然后通过 MongoDB 的地理位置查询，这样很方便的实现了查找附近的商家、骑手等功能，使得快递骑手能就近接单。

可能你会听到类似“你这个场景 mysql 也能解决，没必要一定用 MongoDB”的声音，的确，在一篇参考的博客中我看见作者表达了对这个说法的看法： 并没有某个业务场景必须要使用 MongoDB才能解决，但使用 MongoDB 通常能让你以更低的成本解决问题（包括学习、开发、运维等成本）

我突然就想起了一个之前听到的话，企业解决问题的首要因素是成本问题，成本越低，并且消耗的资源量更少而且也能达到目标需求的方案往往更可能采纳，所以作者个人认为Mongo本身最大的优势就是他的 灵活，正因为此，在一个新项目的发展过程中往往充满了不确定性，诚然，优秀的程序员和产品经理也许可以预见未来产品的发展趋势，但是不可否认的是，考虑总会具有片面性，你总有你没有考虑到的地方，这些地方就是Mongo为你支持的容错性。

同时作者还看见一段自 MongoDB 公司 TJ 同学的某次公开技术分享：如果你还在为是否应该使用 MongoDB，不如来做几个选择题来辅助决策

• 应用不需要事务及复杂 join 支持新应用
• 需求会变，数据模型无法确定，想快速迭代开发
• 应用需要2000-3000以上的读写QPS(更高也可以)
• 应用需要TB甚至 PB 级别数据存储
• 应用发展迅速，需要能快速水平扩展
• 应用要求存储的数据不丢失
• 应用需要99.999%高可用
• 应用需要大量的地理位置查询、文本查询

如果上述有1个 Yes，可以考虑 MongoDB，2个及以上的 Yes，选择MongoDB绝不会后悔。

就作者本身自己的想法看来，Mongo确实很适合嵌套类型数据的存储，在普通的关系型数据库中，嵌套数据的存储往往是通过建立新的子数据表或者是在一张表中执行一些复杂的SQL语句，这个时候Mongo的优势就体现出来了，当然实际的产品还是要不同的数据库相辅相成吧，不过作者还是希望Mongo能在未来的发展中继续保持自己的优势能够越来越好。

（本文如有侵权请联系作者，如有不对恳请斧正，谢谢大家，希望大家能够维护和谐的社区环境）

参考资料（排名不分先后）

www.cnblogs.com/liuluobing/… - 五忌

www.mongodb.com/docs/manual - MongoDB官方文档

www.51cto.com/article/378… - 核子可乐

www.infoq.cn/article/XBM… - 唐建法

www.cnblogs.com/williamjie/… - 割肉机