基数：数据分区默认是由64M的块来管理的。片键基数底（比如用户的家乡）会把文档分散在较小范围的几个分片上，这样可能就需要频繁的对块进行重新平衡。所以，片键的基数需要大些。
写入分片：数据写入应该最终分散到所有分片服务器上。如果片键是单调增长的，那么即使片键的基数大，数据也会写入到单个服务器上，这样会产生写入高峰点。所以片键应该最终都分布开来。
查询隔离：查询应该被指定到具体的分片上以最大化系统的扩展性。如果查询不能分离到具体的分片上，那么所有的片键会在一种分散/集中的模式下进行查询，这样查询的效率很低。
在需要之前就提前进行容量扩展：在系统过载前对系统进行容量扩充，那么集群更易于维护及管理。
至少运行三台配置服务器以便保证系统的冗余性：生产环境至少运行三台配置服务器，并且服务器放在可以应对各种故障的网络拓扑里。
使用复制集：复制集和分片是完全可以兼容的。所有的部署都应该使用复制集，有需要的情况下再使用分片。分片允许数据库使用多个服务器以便满系统的冗余性。复制集则可以在服务器间、服务集群间甚至数据中心之间维护多份数据样本。
使用多个mongos实例。
使用***实践实现批量导入：提前把数据分散到多个数据块中，在写入过程中不需要进行数据平衡。或者，在批量数据导入的过程中禁用数据平衡器。同样，使用多个mongos实例平行导入，也能减少压力。
动态数据平衡数据导入MongoDB系统后，系统会通过集群中的平衡器这一进程对数据进行动态平衡。平衡器同一时间只会移动文档中的一个数据块并且只会在数据块的容量超过允许值后才进行操作，这样可以最小化平衡操作对系统造成的影响。当然，也可以禁用平衡器或者对其进行配置使其更小化的影响系统性能。
地理分布MongoDB中可以把具体的片键范围分配到具体的物理分片中。Zones分片可以让管理员控制集群中文档的地理位置。
系统管理员可以结合复制集、Zones分片、读偏好以及写关注这些特性来部署地理分布式集群，这样用户可以直接在本地数据中心进行数据读取。管理员可以把分片集合限制到具体的分片服务器中，有效的为不同的用户提供分片服务。比如，我们可以把所有关于USA的数据分配到位于美国的分片服务器上。
MongoDB管理：规划、监控、灾备恢复Ops Manager是由开发MongoDB数据库系统的工程师开发的一款管理工具，也是运行MongoDB的最简单的一种方式，运营团队使用Ops Manager可以方便的部署、监控、备份以及扩展MongoDB系统。Ops Manager中的很多功能在MongoDB Cloud Manager服务中也是可用的。Cloud Manager支持数以千计级别的部署。使用MongoDB Enterprise Advanced的组织可以选择使用Ops Manager或者Cloud Manager。
Ops Manager和Cloud Manager提供了***实践以保证数据库系统的健康及优化。通过可靠的自动的鼠标操作或者API来代替繁复的手动操作任务。
l 部署：任何结构任何规模的都可以
l 升级：不宕机，几分钟即可完成
l 扩容：应用不下线的前提下完成系统扩容
l 例行性备份：灾难是不可预测的，但是在Ops Manager和Cloud Manager中只需要点几下鼠标即可实现集群在运行的情况下恢复到任何备份的时间点。
l 性能警告：可支持监控100台以上的节点，为系统提供预警信息。
l Roll Out Indexes：从备节点开始到主节点逐个增加索引，避免增加索引的时候影响应用的性能
l Manage Zones:配置Zones以决定数据存储在什么位置
部署、升级Ops Manager通过安装在每个服务器上的代理与服务器进行数据交互，因此它可以协调MongoDB系统中服务器的关键操作任务。服务器可以部署在公有云上也可以部署在私有数据中心。Ops Manager能高效可靠的完成传统上需要管理员手动完成的操作，比如部署新的集群、系统升级、创建新的备份时间点、迁移索引等等。
Ops Manager能持续的评估系统并做出调整来应对系统中出现的问题。
l 在各个服务器中安装Ops Manager代理，也可以通过Chef或者Puppet这样的配置工具进行安装。
l 管理员为系统创建一个调整目标或者修改目标（比如系统升级、oplog的大小调整、增加新的分片等）
l 代理周期性检查Ops Manager服务中心是否有更新，如果有就接受调整指示。