在生产环境中使用 mongodb 始于 2012 年左右，从最初的 master-slave 模式到后来的 master-replication，到评估 mongodb-sharding 并放弃在生产环境中使用，使用 mongodb 作为基础数据库已经服务了上亿用户。在 4 年的 mongodb 生产环境使用当中，踩了很多坑也走了不少弯路，在此记录，与君共享。
No schema 并不代表没有一致性
mongodb 是 nosql 数据库，强调 schema 的灵活性和强大的集群功能，以及牺牲事务带来的巨大性能提升。如果只是用 mongodb 记录日志，一致性并不是很重要，相反如果是关键性业务，鉴于 schema 极强的灵活性，经常会造成 collection 数据结构被变更而且不易察觉，表现的结果是应用程序常会出现诡异而无法深入跟踪原因的 bug 和异常。业务越庞大，这样的改变越是灾难性的。
设计之初就对一致性做出非常严格的校验和控制，好消息是 mongodb 3.2 开始已经从数据库层面支持对 collection 结构的校验。每次表结构调整，都要对历史数据进行相应的变更。
对开发者使用门槛降低的同时，也是在对躲在暗处的人敞开了大门
mongodb 非常容易安装和使用，无需任何权限设置即可开箱即用，而且默认mongodb 的端口是可以从公网访问的，仅仅这样的设计就已经造成了无数的安全问题，详见mongodb 赎金门事件。虽然数据库没有强制要是有口令和用户来管理权限，但是开发者的安全意识不能松懈。
任何时候部署mongodb 都应该尽早设置用户、口令以及相关权限。
升级要趁早
mongodb 版本的迭代比较稳定，每年会有一到两次版本发布，每次新发布都会带来不少性能改进和优化，也有少量 api 的变动，变化相对较大的是 mongodb 的驱动。为了尽可能早地享受版本升级代来的好处，要制定一套对线上环境进行新版测试、安装、兼容过渡的方案。
升级版本不能跨度太大，mongodb 官方也推荐生产环境升级要渐进式的而不是跨越式的，每次升级一定要备份数据。
正确使用索引
和 mysql 等关系型数据库一样，mongodb 也支持索引查询，并且支持在多种数据类型上建立索引。为了能最大限度的利用索引提升查询性能，正确建立和使用非常关键。要确保索引能够正确建立和使用需要做到起码以下几点
- 非常熟悉 collection 上对应的每个查询和查询对应字段的数据类型
- 了解不同索引的区别以及它们的使用场景：single index，compound index，hash index 等
- 了解前缀索引的原理和使用原则
- 不仅仅要优化索引，如有必要修改字段类型，调整表结构都有助于建立正确的索引
nosql 不是万能的
软件开发领域没有银弹，nosql 也不是万能的，在有强一致性、事务性场景 mongodb 并不合适，面对这样的场景选择关系型数据库是更明智的选择，不管你有多么喜欢 mongodb 带来的便利。
慎用第三方 ORM
ORM 隐藏了对数据库操作的细节，这对真正想掌控全局的开发者来说并不是好事。ORM 工具不但使数据变更的过程难以追踪，而且在业务逻辑逐渐复杂之后， 开发者不得不深入ORM 来实现更灵活的拓展。此时，可以选择去 ORM，但是代价将会非常之大。
如果你实现的是个 blog，ORM 是个得力助手，如果是个复杂的社交应用，ORM 并不是一个好的选择。
