1.MongoDB同样需要运维。首先，MongoDB是个数据库，因此与其他数据库一样，它需要容量规划、性能调优、监视及维护。请不要因为MongoDB易于安装、开始及比传统关系型数据库更友好就认为MongoDB不需要关心及投入精力，同样不要因为小数据集运行飞快就认为MongoDB不需要优秀的模式、索引策略以及支撑应用程序所需的资源。然而一旦你做了充分的准备并且吃透了那些最佳实践，那么管理一个大型MongoDB集群将只是麻烦而不是伤透脑筋！

2.成功的MongoDB使用者会监控一切并随时准备好它的增长。跟踪当下的资源使用情况并做合适的容量规划是使用任何数据库系统必备的基础，MongoDB也不能免俗。你必须了解当下集群可以支撑的负载量，也必须清楚在负载峰值时的硬件需求。如果你不清楚负载的增长情况，你必将因为资源耗尽而烦恼。为了监视你的MongoDB部署，你可以使用MongoDBManagementService（MMS）来可视化你的操作。

3.扩展过程中的困难可能并不符合你的预期。在了解数百用户的部署后，发现性能瓶颈通常会因为以下几个问题产生（影响程度从大到小）：

模式设计不适合应用程序需求是影响性能的首罪，其次就是索引——很差、缺少或者是太多；然而即使这两个方面都没有问题，性能还可能受到磁盘IO的吞吐量限制，特别是写入吞吐量。内存不足会导致许多pagefaulting并且给磁盘IO带来压力，随着应用规模的增加，系统所需的内存越来越多。

4.许多MongoDB用户得益于单一的副本集。过早分片容易产生不成熟的优化，不是每个MongoDB部署都需要分片。分片只适合特定的情况，而不是应对“数据库缓慢”的灵丹妙药。如果你有1个错误的模式或者是不恰当的索引，分片不能解决任何问题。只有某个资源在单机或者单副本集情况下产生瓶颈时，并且继续扩展这个资源不符合投资回报比，分片才是最佳优化方案。系统可能会需求更多的IO吞吐量、RAM，亦或是更多的存储或并发性，这些情况下，分片往往比较好的选择。

5.即使不是将整个数据库放入RAM中，你也可以获得优异的性能。在MongoDB世界里存在一个普遍的误区——将整个数据库放入RAM才可以获得较高的性能。然而取决于负载的类型，这可能是世界上最大的笑话。下面是一个显示和度量，体现了负载不同数据库所需的RAM。如你所见，随着数据库体积的增加，放入RAM中的部分受限于有效的实体存储器。如果RAM的大小不适合性能的需求，你将会看到pagefaulting，同时随着错误数量的增加，系统的性能不升反降。

6.数据持久化到磁盘。如果磁盘使用率已经达到100%，那么将无法执行更快地写入。你可以在MMSBackgroundflushaverage图表中查看脏页面从数据文件写入磁盘耗费的时间，从这个趋势来看，随着写入增多，这个过程将花费更多的时间。在这种情况下，你可以通过让磁盘更快、使用更多的分片以及优化应用程序来解决问题。需要注意的是，每个写入都会持久化到磁盘两次——日志及数据文件，将这两个操作划分到不同的物理磁盘上可以切实地降低IO带宽争用。

7.副本不等于备份。所有人都清楚备份的重要性，但是备份为何如此重要？一般情况下该归结于可以从影响到所有副本节点数据的灾难事件中恢复，副本不等于备份的原因非常简单，备份可以阻止数据被一些人为因素破坏——比如，某个人突然的删掉所有生产数据，或者是部署了错误版本的应用程序代码，这都可能让你的部分或者全部数据陷入危险之中。类似的情况下，你必须拥有一个备份来防止灾难的发生。因此，请进行适当的备份，即使你已经使用了文件系统快照、Mongodump或者是MMS备份。请不要让你首次备份发生在数据已经被受到威胁之时！

8.副本集的健康程度不只看Replicationlag。Replicationlag体现了副本落后于主节点的程度，它只是副本集健康状态的指标之一。与之同等重要的还有replicationoplogwindow，它会基于当下的写入负载计算出oplog完全恢复所需的时间。换句话说，它表示了一个预计时间——节点发生故障并有能力从中恢复，而无需去执行完全的数据同步。随着时间的推移，系统的写入负载可能会出现波动，replicationoplogwindow同样会随之改变。在峰值负载下，replicationoplogwindow将会缩短，这点在容量规划中是非常重要的。下面是一个MMS的对比视图，显示了跨副本集的replicationoplogwindow：

9.MongoDB不会知道数据需要什么级别的安全。任何数据库的管理都需要建立在“按需访问”之上，原则上最小化的控制权限，因此你必须自己去配置数据库的安全级别。对MongoDB本身的安全限制也是非常重要的，你需要关闭所需访问之外所有的权限。

10.请勿擅自修改MongoDB的高级选项。虽然MongoDB具备这个功能，但是除非万不得已请勿使用。在问题产生时，对比修改底层参数，更应该做的是定期分析查询及其他力所能及的事。