作为一个在web时代开发的数据库，MongoDB在开发时就已经具备了这个时代开发人员的观念，因此不需要像传统关系型数据库管理系统那样多的操作开销。话虽如此，但它扔需要遵循一些最佳实践才能先行一步并实现高可用性的目标。
以下顺序按重要性排序
默认情况下启用Journaling日志功能
Journaling日志 功能使用 预写日志 ，以便在MongoDB服务器突然关闭的情况下进行恢复。
使用MMAPv1存储引擎时，应始终启用Journaling日志功能。
使用WiredTiger存储引擎，Journaling日志和检查点功能应在一起使用以确保数据持久性。
结论：无论如何，使用Journaling日志和微调日志的大小和检查点的频率是一种很好的做法，这样可以避免数据丢失的风险。
在MMAPv1中，默认情况下，Journaling日志每100毫秒冲刷（Flush）一次磁盘。如果MongoDB在确认写入操作之前正在等待Journaling日志，则Journaling日志将每隔30毫秒冲刷一次磁盘。
工作集应该容纳在内存中
特别是在使用MMAPv1存储引擎时， 工作集(Working Set) 最好 小于 底层机器或虚拟机的内存。MMAPv1使用来自 底层操作系统的内存映射文件 ，如果在RAM和磁盘之间没有太多交换，这可以大大受益。另一方面，WiredTiger在使用内存方面效率更高，因此它也可以从同样的原则中受益匪浅。工作集最大为db.stats()报告的数据大小加索引大小。
记住数据文件位置
可以使用 --dbpath 命令行选项将数据文件安装在任何位置。确保数据文件存储在具备足够磁盘空间的分区中非常重要。最好是 XFS 或至少是 Ext4 格式。文件格式笔记
随时更新版本
偶数主编号版本是稳定版本 。例如：4.2是稳定的而4.3是不稳定的。始终更新到最新的安全更新版本并考虑在下一稳定版本发布后立即更新是一个很好的做法。
使用Mongo MMS以图形化方式监控服务
MongoDB Inc. 的免费监控服务是一个很好的工具，使用它可以了解MongoDB集群、通知和警报的简况，并积极主动地解决潜在问题。
如果开发人员的指标显示有严重使用的状况，可以考虑进行扩展。
实际上，MongoDB并不会出现真正大量使用的情况。 如果 CPU、RAM等关键指标的使用率>65% ，或者 发现出现磁盘交换的情况 ，就是应该开始考虑扩展的警报了。开发人员可以通过使用更大的计算机进行垂直扩展，也可以通过分片进行水平扩展。
分片时要小心
分片就像是对分片建（Shard Key）的强烈承诺 。如果开发人员做出了错误的决定，那么 返回可能会非常困难。 在设计分片时，架构师需要长时间深入考 虑读取和写入中 的当期工作负载，以及 预期的数据访问模式 。
使用MongoDB团队维护的应用程序驱动程序
支持这些驱动程序，并且通常比同等程序更快地更新。如果MongoDB不支持开发人员当前正在使用的语言，则需要使用MongoDB的 JIRA跟踪系统 。
安排定期备份
无论使用的是独立服务器、副本集还是分片，都应将常规备份策略用作防止数据丢失的二级防护。 XFS 是一个很好的文件系统选择，因为它可以执行 快照(Snapshot)备份 。
应避免手动备份
应尽可能的使用定期自动备份。如果需要使用手动备份，则 可以使用副本集中的隐藏成员来进行备份。开发人员必须确保在此成员中使用 db.fsyncwithlock 以在此节点上获取最大一致性，同时启用Journaling日志功能。
启用数据库访问控制
永远不要将数据库放在没有访问控制的生产系统中。访问控制应该在节点级别由适当的防火墙实现，该防火墙仅允许通过使用内置角色或自定义的角色来访问特定的应用程序服务器到数据库以及数据库级别。必须在启动时使用 --auth 命令行参数初始化并使用 admin 集合进行配置。
使用真实数据测试部署
MongoDB是一个 无模式的面向文档的 数据库，这意味着可能拥有包含不同字段的文档。在这种情况下，应使用尽可能接近生产数据的数据进行测试，这比使用关系数据库管理系统更为重要。对于包含意外值的额外字段的文档来说，它可以产生使应用程序平稳运行或在运行时崩溃的差别。因此，开发人员应尝试使用生产级别数据部署 阶段测试(Staging)服务器 ，或者至少使用适当的库（例如Faker）伪装生产数据。
