MongoDB 的正确使用姿势

前言

MongoDB 是一个非常有前途的数据库，MongoDB 官方对自己的定位是通用数据库，其实这个定位跟 MySQL有些像。虽其流行度还远未达到 MySQL 的水平，但有个可能不恰当的比较，MongoDB 就像N年前的 MySQL，随着时间的推移，会变得越来越强大，也会越来越流行。

适用场景

下面结合 MongoDB 的几大特色来谈谈 MongoDB 的适用场景。

文档型数据库

首先，MongoDB 是文档型（Document store）的NoSQL数据库，数据以文档（对应关系型数据库的记录，本文有时候会混用）的形式在MongoDB中保存，文档实际上就是一个个JSON字符串，想必大家对JSON都比较熟悉，不赘述。使用JSON的好处是非常直观，通过一系列的Key-Value键值对来表示数据，符合我们的阅读习惯，下图所示是以JSON表示的用户信息文档。

在主流的计算机语言如 Java、Python 中对 JSON 都有很好的支持，数据从 MongoDB 中读取出来后，可无需转换直接使用；MongoDB 文档另一个特点是 Key-Value 键值对支持丰富的数据结构，Value 可以是普通的整型、字符串，可以是数组，也可以是嵌套的子文档，使用嵌套的好处是在MongoDB 中仅需一次简单的查询就能够获取到你所需的数据。举电商领域为例，网易严选上卖的上衣和裤子两种商品，除了有共同属性，如产地、价格、材质、颜色等外，还有各自有不同的属性集，如上衣的独有属性是肩宽、胸围、袖长等，裤子的独有属性是臀围、脚口和裤长等。

这些独有属性可以直接以JSON子文档的方式嵌套在商品这个文档中，一次查询直接获取全部内容，不需要进行多表join；MongoDB文档的另一大特点是模式灵活：不同文档相同key的value类型可以是整型也可以是字符串等其他类型，不同文档可以有不同的key，比如有些商品有折扣字段，可以定义不同会员等级的不同折扣。在电商配套的物流领域，可以将一个快递的物流信息直接嵌套在以商品id为唯一索引的文档中，一次查询就可以获取完整的快递流向信息。MongoDB查询还提供了非常丰富的操作符，在查询中组合使用效率倍增。

基于文档的灵活的数据模式，是MongoDB的一大优势，对于数据模型多样或多变的业务场景，相比MySQL等数据库，无需使用DDL语句进行表结构的修改；相比其他Key-Value数据库，由于MongoDB的Value字段对于MongoDB是非透明的，可以对其建立索引，还可以进行全文检索，在查询效率上更具优势。该模式在游戏、电商、社交、视频直播、物流等领域非常适用，通过在用户或商品中嵌套不同用途的子文档来实现快速查询。对于监控、日志数据存储，第三方信息抓取等场景也同样适用，因为不同监控数据、日志记录、抓取的数据所包含的字段往往是不一样的，某种程度上说也是不可控的。同时，灵活的模式对于类似游戏市场活动、移动App等要求快速开发上线但需求变动（导致数据模型变大）比较大的产品或场景也比较适用。

强大的索引能力

其次，MongoDB 还具有强大的索引能力，支持创建唯一索引、二级索引、TTL索引和地理位置索引等，这在NoSQL数据库中是数一数二的，在此基础上，MongoDB 还提供了执行计划功能，通过 explain() 和hint()命令可以查看执行计划、强制查询走某个索引，这些特性相比关系型数据库也不遑多让。MongoDB 集合在创建时默认就基于_id字段创建了唯一索引，数据插入时会检查_id字段的唯一性，MongoDB 可以在包括数组中字段或嵌套文档中的字段几乎任意字段上创建索引（一般为二级索引），大大提高了查询效率，在没有跨记录或跨表事务但对性能要求又非常高的某些场景下能够替代关系型数据库。在内存足够的情况下，索引会被加载到 Cache 中，如果执行的查询是 索引覆盖 的，其性能甚至可以媲美Redis等内存数据库等。TTL索引在保存日志或监控数据等场景下大有用武之地，通过创建TTL索引，实现自动删除过期记录的功能，（在使用MongoDB TTL索引需要注意，数据的过期时间无法精确控制，无法做到过期即删除，在大数据量的情况下会有一定的性能开销和删除延迟）。

地理位置索引是MongoDB早已被用户所熟知的特性，其球面（Spherical）和平面（Flat）两种模式，提供了丰富的地址位置的表示方式，如2d、2dsphere和GeoJSON等，对于移动App，如地图软件、打车软件、外卖软件，MongoDB强大的地理位置索引功能是其最佳选择；此外，对于物联网、智慧都市等领域，也需要大量的地理位置相关操作，这些都是MongoDB的竞技场。

高可用和读写负载均衡解决方案

再次，MongoDB的复制集是数据库领域领先的高可用和读写负载均衡解决方案，提供了数据自动（异步/同步）复制能力，一个新节点加入到复制集中会自动进行数据初始同步随后使用oplog进行增量复制，无需人工干预；如果复制集的Primary节点发生宕机，MongoDB会自动进行主从切换，在复制集大多数节点在线的情况下，能够基于Raft协议（MongoDB 3.2开始，之前版本未使用Raft）自动地快速选出新的Primary并恢复读写服务（在选主期间，无法进行写操作），无需人工干预；MongoDB运维人员所需做的仅仅是将宕机节点重新启动，若宕机的是Primary，则重新启动后，会自动进行数据回滚并最终成为复制集的Secondary节点（正常情况下）。

在复制集机制下，还可以通过对节点进行滚动处理的方式进行在线维护升级。所以，相比目前的大多数关系型数据库，MongoDB复制集实现了自动复制和故障切换，大大减低了运维复杂度，解放了DBA。如果你对数据的持久化和可用性有较高的要求，MongoDB复制集是上佳的选择。此外，复制集还提供了Write Concern、Read Preference、Read Concern和Tag sets等读写行为控制功能，不同的业务应用类型可以参考官方手册根据对数据持久化、数据一致性和可用性的不同要求进行灵活地设置。

大数据，Sharding 机制

最后，MongoDB是为大数据而生的，提供sharding机制用于实现业务的水平扩展。每个shard都保存业务的一部分数据，shard可以配置为复制集，确保shard上数据的高可用性，shard内部由一系列连续的chunk组成，chunk是某一片键区间内的数据记录集合；mongos用于业务请求的路由，将业务负载分摊到不同的shard上，此外mongos还会对shard上超过一定大小的chunk进行分裂（split）；根据不同shard中数据量的大小，在shard将进行chunk迁移（migrate），应该说sharding提供了完善的业务数据和负载水平扩展的机制，对于物联网、日志系统和监控系统这类包含TB级海量数据的应用场景，使用MongoDB sharding是个不错的选择。

在生产环境中，sharding并不是必须的，并不是新业务起来的时候就马上部署sharding集群，只有当业务的数据量达到单个复制集无法支撑、或者业务的负载超过了复制集的服务能力的时候，才考虑部署sharding，毕竟相比复制集，sharding在部署和管理上都复杂很多。MongoDB复制集可以平滑升级到shard，所以当你真正需要sharding时，可以参考Shard官方文档进行操作，文档中提供了详细的升级步骤。

不足之处

介绍了MongoDB的优势，也不得不提MongoDB的不足，MongoDB仅支持文档内的事务，所以对于需要跨文档或跨集合事务的应用，请谨慎使用MongoDB；另外，对于需要多表复杂Join的业务，还是使用关系型数据库为好，MongoDB还在改善的路上；最后，对于PB级大数据量，且需要进行大规模计算的场景，使用MongoDB时需要配套使用Spark、Hadoop等大数据套件，让MongoDB做正确的事情。

正确使用姿势

总结起来，如果你的业务满足一个或多个特点，那么选择MongoDB是个正确的决定：

• 无需要跨文档或跨表的事务及复杂的join查询支持
• 敏捷迭代的业务，需求变动频繁，数据模型无法确定
• 存储的数据格式灵活，不固定，或属于半结构化数据
• 业务并发访问量大，需数千的QPS
• TB级以上的海量数据存储，且数据量不断增加
• 要求存储的数据持久化、不丢失
• 需要99.999%的数据高可用性
• 需要大量的地理位置查询、文本查询